![]() ![]() ![]() |
|||||||||||||||||||||||||||||||||||||||||
About NCD Thin ClientsTABLE OF CONTENTS1. 16 and 32 MB SIMMs for MCX and 88k2. Playing Mosaic Audio Files on NCD Thin Clients3. HMX memory configuration4. retain_x_settings problems5. NCDware Installation Guide
1. 16 and 32 MB SIMMs for MCX and 88kAs you may be aware, the MCX products support both 16 and 32 MB SIMM modules. A lesser known fact is that the 88k base products (NCD19c, NCD17cr, & NCD19g) also can use these large memory modules. Using the 32 MB SIMMs,the MCX can have up to 34 MB code side memory and 68 MB data side memory for a total of 102 MB. The 88k bases can have 64 MB code side memory and 96 MB data side memory for a whopping total of 160 MB! NCD does not offer these large memory modules, customers can acquire them through four potential sources, two memory chip manufacturers and two third party SIMM manufacturers. The two memory manufacturers are NEC and Hitachi. These modules can be found through normal electronic component distribution channels. The two third party SIMM manufacturers are Desktop Sales (800-775-9695) and Anacapa Micro Products (800-800-7056). Both of these companies buy memory chips and then manufacture their own SIMM modules. They also offer other sizes of SIMM modules that will work with NCD products. **The following paragraphs are a bit technical and boring, but important** When buying the 16 or 32 MB SIMM modules there are some technology issues to be aware of. The ASICs controlling the memory devices are designed to drive no more than 16 memory chips. This means that in order to have 16 or 32 MB (Mega Byte) on a single SIMM, 16 Mb (Mega Bit) memory chips must be used on the SIMM modules. An easy way to verify if a SIMM is using the correct technology memory device is that a 16 MB module will have 8 memory chips, and a 32 MB module will have 16 memory chips. Customers are likely to be attracted to 16MB memory modules that use the
older 4 Mb technology RAMs because they are less expensive. These devices may appear to
work, but are likely to cause intermittent memory related errors on the thin client. 16
and 32 MB memory modules using the 4 Mb technology are not supported (they will have 32 or
64 chips on a SIMM). |
|||||||||||||||||||||||||||||||||||||||||
| On Board | J10 | J11 | J12 | J13 | Total MB |
| 8 MB | empty | empty | empty | empty | 8 MB |
| 8 MB | 2 MB | 2 MB | empty | empty | 12 MB |
| 8 MB | 4 MB | 4 MB | empty | empty | 16 MB |
| 8 MB | 8 MB | 8 MB | empty | empty | 24 MB |
Customers can configure larger configurations by purchasing industry standard 16 and 32 MB SIMMs.
If you type "xset -q", you will see many parameters for controlling the screen appearance, screen saver, keyboard, bell, mouse, and font path. These are supposed to be reset to default values whenever the server resets, i.e. when a user logs out.
If you type "xprop -root", you will see "window properties" set on the root window. Many applications set root window properties to pass information between clients, set X resources, change the root window background, etc. Motif drag-and-drop is implemented by using a "drag window" to hold information. The id number of this window is saved as a property on the root window so that any client on the screen can find it.
According to X11 specifications, the X settings should be reset to default, and the root window properties should be deleted, when the server resets. retain-x-settings causes these settings and properties to be kept for the next session. These is no guarantee that they will be usable values in the next session environment, nor is there an easy way to check them all and keep only the good ones.
In the past, many customers requested the NCD RETAIN X SETTINGS feature so that their screen, keyboard, X resource, and mouse setting changes would not be lost when they logged out, but doing this goes against X11 specifications. It is not really a bug that Motif assumes the MOTIF_DRAG_WINDOW property points to an existing window, instead of a window from the previous server session which no longer exists. If the X server follows X11 specifications and erases root window properties at reset, this will not be a problem.
RETAIN X SETTINGS gives ease of use beyond what X11 allows, at the expense of potential problems in the next session. Some people who adamantly insisted on having the retain-x-settings feature now wrongly complain that there are "bugs in the NCD" when they use it.
We strongly urge that you do not use it. If there are settings for the screen, keyboard, mouse, etc, which you want to be able to change and keep for the next session, we can tell you how to do it in other ways which may require a small amount of work, but are compliant with the X11 standards.
One common request is to save the font path between sessions, and this can be done in NCDware version 3 software with the parameter xserver-retain-font-path without all the problems of the retain-x-settings parameter.
Many other user preferences for the keyboard, bell, mouse, etc. can be
loaded with the ncdloadprefs utility which is described in the version 3 NCDware
documentation.
This guide is intended for users who are unable to use the installation utility to install NCDware. It contains general information on what steps are involved in installing the software.
You must refer to the Advanced User's Guide for more information on advanced or non-basic installations. This covers UNIX systems only.
Specific instructions are available in the FTP Archive under... ftp://ftp.ncd.com/pub/ncd/Archive/NCD-Articles/NCDware/Installation/
NCDware_3.2.1_Installation
There are several decisions you must make when installing NCDware. This guide explains what those decisions are. The attached instruction sheets apply to specific cases based on what is chosen for these cases.
Files in NCDware are categorized into groups. Not all file groups are required for basic NCD functionality. These instructions assume that all file groups are installed.
You must determine which server images you need. Server images are very large and it is recommended that you install only those you need. Each NCD model uses a different server image. There are different servers for specific functionality. You must select the servers with the functionality you want for each NCD model you have. The NCD units require additional memory for some of the servers, so you must be sure that the NCDs have enough memory for the server you want to use.
Chapter 1 of the Installation Guide provides a complete list of the server images available, the disk space required on the host for them, and the memory required in the NCD to use them.
The instructions cover various types of file access.
You can choose to use non-secure TFTP, secure TFTP or NFS to access files. You must select the file access type for downloading the server to the NCD and for reading the configuration and font files. They do not have to use the same access method.
All NCD terminals can use either TFTP method for downloading or reading the files. All NCD terminals can use NFS for reading the configuration and font files. Only NCD terminals with boot prom version 2.6.0 or later can use NFS to download the server images.
TFTP is a general file transfer protocol, similar to ftp, but it does not require a user id for access. In non-secure mode, any file on the system is accessible via tftp. In secure mode, only files which exist in specified directories (called the TFTP home directories) are accessible. Most hosts have slight variations on how TFTP is enabled, what the home directory is, and how many home directories there can be. You must check the man pages on the host for specific details. The attached instructions include what is needed for those hosts.
NFS is the standard method for mounting specified directories on a host. The NCD will mount the directories from the host for NFS access. The directories on the host must be exported for NFS.
The instructions are for default locations only, however that varies according to the type of file access and on available disk space. The instructions specify the locations being used. Be sure you have enough disk space for the files.
You can store booting information in the NCD and boot from NVRAM, or the NCD can get the booting information from the network using BOOTP or RARP (Reverse ARP) protocols.
NVRAM is fine for sites with a few NCD terminals that are closely located or for first time installations. It requires going to each NCD unit to enter in the booting information.
Installations with many NCD units may find that using BOOTPD is better. Once it is set up, it is very easy to add new terminals and to change terminal configurations.
Instructions are given for booting from NVRAM only. See the Advanced User's Guide for information on setting up BOOTPD or RARP.
There are basically two methods for accessing hosts: xdm or telnet.
XDM provides a login banner from a host to the NCD terminal. The user enters her id and password in this window and is logged onto the host. A startup file called 'Xsession' initializes the users environment and starts applications. Applications can be run from any host on the network. The NCD can be configured to automatically have a login banner from a specific host, or to allow the user to choose which host to get the banner from.
Telnet is easily accomplished by starting an NCD local telnet client, specifying the hostname or ip address, then logging in. The NCD can be configured to automatically start with a telnet client and window manager. Users can use more than one telnet client to log onto multiple hosts at one time. Applications can be run from any host on the network while the telnet sessions are active.
Instructions are given only for using XDM access.
The following steps are covered in the instructions. If instructions are not provided for the host you are using, then find a host which has the closest match for the type of UNIX you are using and adapt those instructions for your host. Use the man pages on your host for help.
1. Log onto the host as root.
2. Mount the CDROM. The CD files can be read directly if your CD driver supports Rock Ridge extensions. If it does not, then you must make links to the CD files to have valid file names to reference. A shell script is provided on the CD to make the links. The instructions for hosts which require this explain what to do.
3. Copy the server files to the host and make links for the boot files.
4. Copy the binary files from the CD to the host.
5. Copy the ncd files from the CD to the host.
6. Copy the NCD man pages from the CD to the host.
7. Enable the file access method on the host (non-secure TFTP, secure TFTP, NFS)
8. Add the NCD terminals to the /etc/hosts file.
9. Create the terminal's configuration file.
10. Configure XDM.
11. Boot the NCD terminal.