CHAPTER 8.

 

CAT 1600 IMAGING SYSTEM

 

 

 

 

1.   INTRODUCTION

 

 

It seemed to be a long time ago that I joint this project which had required a imaging and displaying system to show wave front images from a optical system.  The image was rather simple, consisting of 1024 bytes arranged in an array of 32 by 32 pixels. The data were color coded and displayed on a color CRT monitor in a checkerboard form.  At that time, MassComp in Massachusetts had rolled out their MC500 series workstations, and one of them was designated to be the displaying device for this experiment. This MassComp computer was run by three 68000 CPU's, and a few other proprietary processors and was considered the most sophisticated laboratory computer money could buy.  Its operating system was an undiluted Unix, supporting both C and FORTRAN.  It also had a STD based front end to interface to real world through A/D, D/A, parallel and serial cards. A quite extensive package of software was also developed to perform data acquisition, displaying and analysis tasks.

 

With such horse power packed in a nice looking box, topped by a high resolution color monitor, mouse, and keyboard, it was thought that displaying such a simple image was a easy piece of cake.  However, after months of work, enlisting the best C programmers we could find, the best results obtained was that the display could be refreshed at the rate of about 1.3 Hz and no more.  The reason was that this computer was designed principally for graphics, not for imaging.  After the 1024 byte data block was received, one of the 68000 had to be dedicated to color fill the checkerboard, and their were a lots of pixels to fill.

 

About that time, a colleague showed me a fattened microcomputer he used for some optics experiments.  It was again a 68000 based computer, built by Ergonomic Research Group in Oregon. It was again a Unix machine.  However, the interesting thing about this computer was that when it was cold booted, it displayed the strange message "ok".  There ought to be something fishy there.  Some more probing convinced me that there was a genuine Forth underneath, whose sole function was to bring the Unix in from the hard disk.  A few pages of scattered documentation showed that the Forth was derived from figForth model with significant extensions, like 32 bit stacks and 32 bit addressing capability.  The CPU and 1 Megabytes of memory were housed in a S100 card cage, with an extra card set, CAT 1600 from Digital Graphic Systems, Inc. in Palo Alto, CA.  The CAT 1600 was a full color, real time imaging system which could digitize and display images from a video camera.

 

Promising that I could improve the speed of data displaying, I was given ownership of this computer to prove it.  Prove it I did.  I threw away the Unix and studied the strange Forth came in a pair of PROM's without much documentation.  In about a month, we had enough code developed to hook it to the main experiment.  With CAT 1600, the data refreshing rate was raised to 40 Hz, which was too fast for the host minicomputer to keep up with it.  When people tried to increase the transfer rate at the host side, the host computer crashed at about 20 Hz. So we ran at about 15 Hz and everybody was very happy.  The CAT 1600 could be pushed to about 100 Hz, but nobody cared and even if I did, nobody would notice any difference.  So I stopped.

 

I never bothered to tell people why CAT 1600 outperformed the much more sophisticated, and more expensive, MassComp workstation. It was kind of cheating.  As a system designed specifically for imaging purposes, CAT 1600 was capable of zooming at a wide range of zoom ratios.  I expanded each pixel by a factor of about 8, making the checkerboard large enough to be seen at a distance.  At this zoom ratio, I only had to write each square once, unlike MassComp which had to fill every pixel in the checkerboard.

 

Unfortunately, I learnt lately that this system became sick. Apparently the 68000 CPU quit.  The worst thing was that ERG was no longer in business, and nobody knew how to fix it. It was eventually junked.  People in that project were trying use the MassComp again.  Losing a computer is like losing a child, after you put so much of yourself into it.  It is very sad.  I feel like writing an obituary now.

 

Here I will show you some of the Forth code used to control the CAT 1600 imaging system.  I cannot find the original listing. The copy, though still legible, is not very clear.  My apologies. I cannot even write shadow screens with the source screens to make them more understandable, but I will try to explain what is not obvious.

 

 

2.   CAT 1600 IMAGING SYSTEM

 

 

Digital Graphic Systems pioneered low cost imaging systems as early as 1977.  CAT 1600 was developed as board sets to plug into the motherboard of a standard S100 host computer. It contains a large image memory and all the circuitry necessary to digitize B/W or color video signals in real time, to store and process the digital image data, to make the data accessible to the host processor, and to display the digital image on a video screen in gray levels or in full resolution RGB color. A dedicated 8086 image processor is supported on board with up to 48K of fast static RAM and 64K or PROM.

 

The dual port image memory provides for up to three 512x512x8 bit images or one 512x512x24 bit real color image.  The image memory can be accessed at any time, either by the display processor or by the host processor, for software image generation or analysis of the digitized images.

 

Other important features include: NSTC standard video input and output, genlock on external video or sync, flexible color look up tables, pixel by pixel scroll and pan, smooth zoom from 1:1 to 1:31.68, etc., etc.

 

The most interesting feature is the image processing firmware coming in on-board PROM's.  About one hundred firmware routines in this library can be called by the host processor using simple commands.  This library relieves the host processor from lower level imaging tasks, which significantly speeds development work and increases the overall system performance.

 

Communication between the host and CAT 1600 is done via two channels: the host I/O port address space and the host memory address space.  In the I/O space three consecutive word addresses are used.  They are the Command Register, the Data Register, and the Status/Reset Register.  The command register is used by the host to select one of the firmware functions.  If the firmware function needs parameters, they are passed through the data register.  If a function returns results, they are read also by the host through the data register.  The host monitors the activity in CAT 1600 by reading the status register. When the status register is written by the host, CAT 1600 will reset.

 

In the host memory space, an addressing segment, called a data 'window' is assigned by CAT 1600 for direct data exchange. Although it is possible to move all image data through the I/O registers, throughput and speed are greatly improved if the data is moved through the data window.

 

 

3.   FORTH SOURCE CODE

 

 

Controlling CAT 1600 with Forth is rather straightforward, like controlling any other electronic equipment.  One has to first establish communication with CAT in monitoring its status register, sending commands to the command register, and passing data to and from the data register.  Since the image memory is mapped in the addressing space of the 68000 system, one should also establish the proper protocol to access the image memory directly.

 

Listing 10 has the CAT 1600 source code.  Screen 101 has the elementary code which allows the 68000 to control the CAT 1600.

 

The three I/O registers are mapped to the memory locations hex FFFFC0. , FFFFC2. , and FFFFC4. The registers are named appropriately DATA for data register, CMD for command register, and STAT for status register.  They are all defined as 32 bit constants to return addresses in the 68000 addressing space.

 

READY is used to wait until CAT finishes its last task and resets the busy bit in the status register.  It will abort if made waiting too long.  INITCAT resets CAT 1600 by writing to the status register.  INWRD reads a word from the data register. OUTWRD writes a data word to the data register, and OUTCMD writes a command to the command register.  STATUS returns the contents in the status register.  All other Forth commands to CAT 1600 are constructed from these simple interface words.

 

COLOR was my first attempt to converse with CAT 1600.  Command 10 is to fill the entire screen with a byte to produce a flat colored screen.  0A CMD sends the command followed by OUTWRD to specify the color.  DEMO2 puts COLOR in a loop to test all the colors available.

 

Screen 102 shows code to write directly into the image memory. The image memory is mapped to the 68000 address space starting at hex 600000., which is defined as IMAGE.  To access image memory directly, one has to first enable DIA (Direct Image memory Access) by giving command 74.  After the memory accessing is completed, it is necessary to disable DIA (command 0) before issuing other image processing command; otherwise, CAT would abort.

 

ENBDIA enables DIA and DISDIA disables it.  The rest of the screen shows some test routines to demonstrate the effects of direct memory accessing.

 

The commands in Screen 103 set the serial port dedicated to the printer to communicate at 4800 Baud, so that we can print the listing on a slow DEC printer.  FDA00C is the control register of that serial port.

 

Screen 104 to 107 are the commands to call firmware functions. They are defined by the defining word CAT, which expects two parameters: the command number and the number or parameters the command requires.  If more than one parameter is required, they have to be given on the data stack in the reversed order as specified by the document from Digital Graphic Systems, because CAT would simple remove numbers off the stack and send them to the data register in CAT 1600.  The names of commands are exactly those define by DGS for compatibility and ease of my documentation effort, which is 'Please refer to original DGS manual.'

 

Two test routines are shown in Screen 109 with some examples. They call the CAT functions MOVABS and DRAWABS to draw rectangles and triangles.  MOVABS moves the drawing point to the x,y coordinate on the CRT display, and DRAWABS draws a line from the current drawing point to the point you specified on the stack, which is then taken as the current drawing point for subsequent drawing.

 

Screen 113 shows the code to build color look up tables.  The word LUTCMD commands CAT to take the next 768 data words to fill the red, green, and blue color look up tables for the page 0 of the color image memory.  By the words /RAMP, FLAT, and RAMP\, we can construct quite complicated pseudo color schemes for coloring image data.  One of such scheme is implemented in COMPOSITE, which displays data in the rainbow style. Small data values are in red and high data values are in blue. Data around 128 are show in green.

 

DIGITIZE in Screen 116 turns on the video A/D converter, and digitized signal from a video camera is shown on the CRT in real time, 30 frames per second.  To freeze a frame, one has to type in the command STOP.

 

To Display data stored on disk, it is faster if we grab the data in a disk buffer and stuff it directly into the image memory.  The code is shown in Block 126.  DIA and XDIA turns the direct image access mechanism on and off.  1ROW copies 32 16 bit words from the disk buffer to the displayed image.  1BLOCK moves 1025 bytes from the disk buffer to the image memory, displayed as a 32 by 32 pixel block. READ-BLOCKS display a number of blocks, nicely arranged on the CRT display by calling 1WRITE to decide where to put the blocks.

 

Lastly, Screen 130 shows the commands to put text on the CRT display.  CAT 1600 does not have text overlay memory like other more expensive image processors.  The characters are actually drawn in the image memory and become part of the image. Therefore, one has to be careful and avoid putting text at where he has important image data.

 

The code shown here is a small part of the application displaying system.  However, it is enough to give you a flavor on how CAT 1600 works, and to start programming it if you happen to have one.  Otherwise, it's just a piece of handy reference to yet another image processor.

 

 

 

Listing 10.   CAT-1600 source code

 

[1]