About NCD Thin Clients
TABLE OF CONTENTS
1. 16 and 32 MB SIMMs for MCX and 88k
As 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).
2. Playing Mosaic Audio Files on NCD Thin Clients
The rapid growth of the Internet has generated a lot of interest in services available on the Internet. One of the most popular is Mosaic. Most users of Mosaic use the X Windows client "xmosaic" to access Mosaic servers. xmosaic uses the X Window system to provide the visual elements, such as text, graphics, and images. Audio information is available from some servers. The NCD Network Audio utilies can be used to play back Mosaic audio data.
To play back audio, xmosaic attempts to execute an external utility named "showaudio". This can be a binary executable, or a shell script. To play Mosaic audio on an NCD terminal, create a "showaudio" shell script which invokes the NCD "auplay" utility. For example:
-------- start of showaudio --------
# showaudio: utility to play network audio
----------- end of showaudio -------------
The above script assumes the audio data is sent in one of the audio file formats understood by "auplay". However, some Mosaic servers send raw audio data, not in a formatted audio file. In this case, the Network Audio "auconvert" utility is needed to convert the data into an audio file before it is sent to auplay. A shell script to handle this cause would be:
----------- start of showaudio -------------
# showaudio: utility to play network audio
auconvert -raw ulaw8 1 -file snd -rate 8000 $1 - | auplay -v 100
# the auconvert call and parameter list above # should all be on one line.
----------- end of showaudio -------------
A shell script that could handle both cases would need to determine the format of the data, and then decide whether to send the data directly to auplay, or first to auconvert. It is possible to modify the C source code of the auplay utility to handle both cases. However, the task can be accomplished in the shell script by taking advantage of the fact that auplay will output information about the format of a recognized sound file if the -i option is included on its command line. The shell script can check for this output, and use this information to determine if auconvert is needed.
----------- start of showaudio ------------- #!/bin/sh
# showaudio: utility to play Mosaic audio data # using NCD Network Audio # First try playing data as a recognized sound file # Include the -i flag so auplay will # output some info about file format auplay -i $1 | grep -s "File format:" # If grep did not find the string "File format" in auplay's # output, then auplay did not recognize the file format. # Filter data through auconvert to generate .snd file, and # send to auplay. if [ $? -ne 0 ] then auconvert -raw ulaw8 1 -file snd -rate 8000 $1 - | auplay - fi ----------- end of showaudio -------------
3. HMX memory configuration
The HMX base contain 8 MB of built-in memory and 2 MB of video built-in RAM. You can add additional memory (in matched pairs) to the unit at any time. You can purchase SIMMs from NCD or other vendors. Contact NCD Technical Support for information about approved vendors. Only SIMMs supplied by NCD are covered under NCD's warranty.
Fast-page mode, 70 nanosecodes (ns) or faster, 72-pin.
Low profile (maximum 1.1 inches tall). SIMMs taller than 1.1 inches can impede air flow and cause damage to the base logic board when the top of the base is replaced.
Board thickness of 0.047 to 0.054 (0.050 inch nominal). Installing SIMMs that are out of specification may damage the SIMM socket or cause the terminal to behave erratically.
32 bits wide.
1M (256Kx32 SIMM)
2M (512Kx32 SIMM)
4M (1Mx32 SIMM)
8M (2Mx32 SIMM)
16M (4Mx32 SIMM)
32M (8Mx32 SIMM)
There are four SIMM sockets, and all can be left empty. However, if you add SIMMs, they must be added in matched pairs, using a pair of sockets, J10,and J11 or J12 and J13.
It is important that SIMMs pairs be matched by size. For example, if you put a single sided 4MB SIMM in J10, then you should also put a single sided 4MB SIMM in J11. Do not mix SIMM sizes. If you do, the system does not recognize all the memory.
Adding more memory does not improve terminal operation. Adding more memory may be required by the application you use.
Standard Memory Configuration:
8.0 MB (standard), 12.0 MB, 16.0 MB, or 24.0 MB (optional),
expandable to 136.0 MB.
Customers can configure larger configurations by purchasing industry standard 16 and 32 MB SIMMs.
4. retain_x_settings problems
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
5. NCDware Installation Guide
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/
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.
A. Determine what files you want to install.
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.
B. Determine what file access method to use.
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.
C. File locations
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.
D. Determine the method you want to use for booting the NCD terminals.
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.
E. Select the method for users to log onto their hosts.
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.