Fullscreen HTML5Med Res (??MB)HTML4

THE MATROX ALT-512 testing the world's second(?) graphics card Last month, Dr Hugo Holden described how the groundbreaking ALT256 worked. Now it’s time for him to look at Matrox’s next product, with twice as much memory and some new capabilities. S ince the ALT-256 was one of the world’s first computer graphics cards, the ALT-512 might have been the second. However, around that time in the 1970s, other companies such as Vector Graphics were producing S-100 graphics cards too. The ALT-512 was unique at the time in that it had enough video RAM on the one board to have two planes, both 256 x 240 pixels, and the two planes can be viewed simultaneously, with the A plane having twice the intensity of the B plane. This allowed for an image with four shades of grey. Repairing and testing the ALT-512 The card I bought on eBay appeared to be unused, but it was dead. The video sync circuitry was not operating. Investigation showed that the video sync generator circuits were being reset before the second counter in the chain, IC A2, had reached its terminal count. A 74LS00 quad dual-input NAND gate in the gating circuits around the counter had failed in a very unusual 86 Silicon Chip manner (I have not seen a 74 series IC with this fault before). Even though one of the gate’s inputs was low, the output of the gate (with a normal output swing) was responding to the other input. In other words, it was as though the input pin which was held low externally, leading to the logic circuitry inside the gate, had gone open-circuit inside the IC and assumed a logic high state. Once this IC was replaced, the card sprang to life. I then set about creating a display. I found that a checkerboard pattern was straightforward to plot in BASIC, but very slow to load, taking 15 minutes or more. The ALT-512 has two video planes and a total of eight display modes. These modes select which plane is plotted or viewed and how the two planes are displayed, singly or mixed together. With different weighting on planes A & B, four shades of grey are possible (see Fig.5). I wrote an 8080 assembly language program (GRPH3.COM) to plot any size of checkerboard to either video plane. As assembly language code runs much faster than BASIC, this takes just a few seconds to plot the checkerboard. I was then able to select, via the keyboard, the various output modes to combine the images. I found that this made all sorts of interesting patterns possible, depending on the relative size of the checkerboards on each plane. Screens 5 & 6 show two of the checkerboard pat- Fig.5: by mixing the signals from the two video planes with differing intensities, it is possible to generate a display with four shades of grey, as shown here. Australia’s electronics magazine siliconchip.com.au Screens 5 & 6: two of the generated checkerboard patterns. All of these screens are displayed on an amber monitor. Screen 7: here is an example pattern formed when combining the two video layers. Screens 8-10: like Screen 7 above, these are some of the different patterns that can be generated by combining both video layers. You can output the four shades of ‘grey’ above as shown in Fig.5. terns I generated, photographed on an Amber VDU (video display unit, ie, monitor). Screens 7-10 show some of the patterns it’s possible to generate by combining two such patterns in various display modes. Four shades of grey are available in two of the modes, because plane A has twice the weighting (video amplitude) of plane B and they are logically ORed and each pixel displayed on top of the other. The four possible video amplitude levels for each visible pixel in the 256 x 240 pixel array are off (black), dark grey, light grey and white, assuming a white (P4) phosphor monochrome VDU. Displaying an image This initial result with the checkerboards got me wondering what sort of “photographic image” the ALT-512 could produce. It would require the two planes be plotted separately and displayed simultaneously. I would have to be frugal with memory, as I have just 48KB of RAM in my SOL-20 (three PT 16KRA RAM cards) and that has to run CP/M as well as my test program. For each pixel plane, one byte can hold eight consecutive pixel values, so 32 bytes per video line (256 ÷ 8) and siliconchip.com.au 240 lines tall. So in theory, 7680 bytes could hold the data to plot one plane. Therefore, the image file would use up 15,360 bytes or 15kB of memory when loaded into the SOL. That would consume the storage capacity of one of the three 16KRA memory cards in my SOL pretty much entirely. I looked around to see what a fourlevel greyscale image might look like and found one in an old video game, reproduced in Screen 11. This made me realise that a four-grey level image in a 256 x 240 pixel array could look ‘respectable’. The next question became how to create the 15kB file from a video image, in the correct format, and get it into the SOL’s memory for loading into the two planes of the ALT-512 graphics card. Screen 11: a four-level greyscale image from a video game. Australia’s electronics magazine It could come across in the usual way as a .ENT file on the serial link, or perhaps transferred to the SOL with the Xmodem protocol using PCGET. Once it was in the SOL’s RAM, I could write an 8080 assembly program to use that data array to program the ALT-512 card. I won’t detail the process here, but what I was able to do was scale down a graphics image to the required 256 x 240 pixel resolution, convert it to a four-level greyscale image, then split out the two components into two separate 7680-byte files, named APLANE and BPLANE. Once I had loaded the APLANE & BPLANE files in SOL-20 RAM at known addresses, I could then read them and load them into the ALT-512 video planes with an 8080 program. This decoded the bytes and displayed the picture. I loaded the BPLANE.BIN file to address 4000H and the APLANE.BIN file to address 5E00H. Then I wrote the final 8080 program (PLOT.COM) to write the values into the ALT-512’s RAM. The result is shown in Screens 12 & 13, using two of the possible eight video display modes (again, on an Amber VDU). The ALT-512 allows each plane to be displayed independently, or November 2020  87 Screens 12 & 13: an example image shown in two different video configurations. The lefthand image is mode three (of eight), and the righthand image is interleaved (mode seven) – the interleaved mode appears more pixelated. The mode is set via sending 0-7 (decimal) to a control port. together, with pixels directly on top of each other or interleaved. This is described in the manual. The interleaved configuration makes the individual pixels readily visible, as can be seen in Screen 13. Summary I think Matrox’s first two video cards are impressive, especially given that they were implemented with nothing more than 74-series TTL ICs and some low-capacity memory. It is easy to take modern high-resolution colour graphics for granted, as they are now everywhere: in phones, tablets, computers and on TV sets (and that’s just for starters). However, it is always worth looking back and seeing how a technology started and appreciating where it came from. Also, it is fun and a technical challenge to repair and restore vintage computers and the cards for them. It’s also challenging to write the software to make them work. Designing a light pen For a bit of fun, I designed a light pen project using the ALT-512. This gives you an idea of one of the possible uses of the ALT-512 at the time it was released. It took me quite a while to become familiar with the ALT-512, specifically the card’s registers. Unlike Matrox’s first card, the ALT-256, the 512 could extract the data from the card’s graphics RAM. That, and the fact that the ALT-512 has two video planes, come in very handy in designing a high-speed light pen system. The first step was to come up with a way to extract the image from the ALT-512’s graphics RAM and then write it to a named disk file. I had to master 8080 assembly language to do that, before I started on the light pen project, or I would not be able to store and re-display any light pen artwork that I created. There are several ways a light pen can be implemented, either mostly in software or in hardware. I decided to go down the about 80% hardware 20% software route in the interests of speed and performance. Design concept The light pen is basically a phototransistor which picks up the light of the scanning CRT beam and, based on the time that it picks up this light, it can figure out which part of the screen it is over, allowing you to ‘draw’ on the screen. But the light pen can’t pick up the CRT beam unless the pixels it’s over are illuminated. Various tricks have Screens 14 & 15: a screenshot with one separate layer dedicated to illumination (left), and that layer then turned off (right) showing just the image. 88 Silicon Chip Australia’s electronics magazine siliconchip.com.au been used to get this to work, such as strobing raster locations with bright rectangles or just increasing the CRT’s brightness. The pen itself is not complex. Several pens were made for Commodore computers which plug into their games port and use the support electronics and software there. I elected to use a dual-button pen which focuses on a pixel without the pen needing to touch the face of the CRT screen, the Inkwell 184C. I decided that since the ALT-512 can produce two simultaneously displayed graphics planes (256 x 240 pixels), I could have one plane as the “illumination plane” and the other as the plane to write to (Screen 14). Then, after the image was plotted, I could simply turn off the illumination plane (Screen 15). This way, I would not have to scan the CRT’s face with progressive illuminated pixels, slowing the proceedings, or have to alter the video monitor’s brightness or contrast controls to get the pen working. I could not find any schematics of light pen processing circuits at all, except a basic block diagram. This showed a horizontal counter, to keep track of the pixel count along one scanning line (the X-counter) and a line counter, to keep track of the scanning lines (Y-counter). The idea is that those counters are reset during the vertical refresh interval, and when the light pen detects light, those counters are stopped. Then, the X and Y counts provide address coordinates to the computer indicating the pixel under the pen, to be illuminated. Technical challenges While the principles of operation seemed simple enough, there were some interesting challenges in implementing it. Firstly, the actual video data which reaches the video monitor is not precisely synchronised with the counters in the graphics card. This is because the video card’s RAM data is clocked out of the graphics card via a shift register, so there is a 12-clock delay before it exits the card via the composite video signal. Rather than pre-loading the X coordinate counters on my circuit card with initial values to get around this (which would be possible), I decided to create a digital delay with a sepasiliconchip.com.au I decided to use a pre-built light pen with two buttons, the Inkwell 184C. The buttons are used to enable draw and erase modes, and it plugs into the interface card using its standard DB-9 plug. rate counter (74LS93 and some logic gates) instead. As well as stopping the counters when light is detected, their resets must also be inhibited. The counter outputs themselves act as the data latches to save more ICs being needed on the card. Also, with the type of synchronous counters I used (74LS161), the clock input must be high when the count is disabled. This required the signal from the light pen to be synchronised with the high phase of the clock. Once the light pen data was acquired, the data search, or re-acquisition of new light pen data, should be inhibited until the software has finished acquiring the X and Y coordinates and has loaded these to the ALT-512 and activated the specified pixel. This allowed for the fact that my software (not written yet) would have some unknown amount of delay introduced by its execution time and delays in the ALT-512. Also, after light pen activation, the process was synchronised with the vertical reset, so that any data acquisition could only occur after this time, regardless of the initially unknown software or processing delays. This was to ensure a ‘fresh start’ for the next light pen detection process. Implementing these functions required some additional gates and flip-flops. On top of this; as the light pen has two buttons, pressing one would need Australia’s electronics magazine to signal the software to switch pixels on (ie, drawing) and the other would enable the pixels to be switched off again (erasing). Interfacing the light pen circuitry to the SOL-20’s S-100 bus required port decoders for the input and output ports and circuitry to support that. In the interests of expediency, I decided to use John Monahan’s buffered S-100 prototype card upon which to build the light pen circuitry. Finally, once the hardware was decided on, there was the software driver to design. Port decoders In the circuit diagram, Fig.6, the port decoder section is based around the four large ICs at left. IC101 and IC104IC110 were designed into the prototype card. The additional 74LS04, 74LS27 and 74LS10 gates (IC100, IC102, IC103 & IC109) allowed me to create three input ports at addresses 08H (8), 09H (9) and 0AH (10) and one output port at address 08H, shown in green. Input port 0AH (10) can be used to read two flags assigned to bit 0 and bit 1 of the data bus. FLAG1 indicates the state of the light pen flip-flop which is latched when the light pen “sees” a pixel. FLAG2 is used to monitor which of the two light pen buttons is being pressed. Input port 08H reads the value of the X-position dot or pixel counter, indicating the position of the pixel on the scanning line. Similarly, input port November 2020  89 Fig.6: the light pen interface circuit. IC101-IC110 are the chips which interface with the S-100 bus (six bus drivers plus an 8-bit digital comparator), and these were already designed into Monahan’s buffered S-100 Prototype card PCB. Some of the added ICs connect to the ALT-512 via a ribbon cable and keep track of the current CRT beam X and Y pixel coordinates. When the light pen senses the light from the display, those coordinates are frozen until the computer reads the data out and resets the flag. siliconchip.com.au Australia’s electronics magazine November 2020  91 09H reads the value of the Y-counter (line counter). To allow the 74LS682 (IC110) to detect more than one port address, I disabled the detection of address lines A0 and A1 by connecting the P0-Q0 and P1-Q1 inputs together. I’m not sure if this is a standard approach or not, but it works because the input pairs ultimately are inputs to XOR gates, so it disables any response from the gate. Address bits A1 and A0 are instead decoded by the additional gates, along with the output data at pin 19 of the 74LS682, which goes low when A3 is high and A4-A7 are low. This creates possible address ports of 08H, 09H, 0AH and 0BH. On this prototype board, the address lines A0 to A7 are reversed from the P0-P7 pin labels on the 74LS682 IC. I’m not sure why it was wired this way on the PCB, but it reverses the order of the jumpers connected on Q0 to Q7 for an address comparison, so it’s a possible trap to watch out for when setting the jumpers. The 74LS10 chip (IC109) is set up so that a write to the 08H port brings its output pin 6 high. As we shall see later, when asserted during the vertical retrace interface, this resets FLAG1 so that a new light pen pixel location can be sensed during the next screen refresh. The PWR-bar signal from the S100 bus is used to ensure that FLAG1 is also reset at power-up. FLAG1 is continuously checked by a software loop to see if a light pen signal has been detected. Light pen circuitry The remainder of the circuitry is for interfacing with the ALT-512 and light pen, and this is shown on the righthand side of Fig.6. The ALT-512 has some useful signals available on a 16-pin DIL connector. I made a ribbon cable with a plug at each end to interface with the prototype light pen card. The DCLK or dot clock from the Matrox card is the master clock rate for 512-pixel mode, so this is presented to the clock input (pin 3) of 74LS74 flipflop IC118a. This generates a signal at pin 5, which gives one pulse for each of the 256 pixels per line on the monitor. Because pixels appear on the monitor 12 counts late compared to the timing of the sync pulse counters within the Matrox card, 74LS93 counter IC116 (and the gating around it) delays the start of counting by 12 pulses. So the CLK pulse to the X-coordinate counters (IC114 & IC115) starts counting 12 pulses late at the start of each scanning line. After counting to 12, IC116 stops. CLK pulses then emerge from pin 11 of IC122d. IC116 is reset before the start of each line by the horizontal reset pulse, so the process repeats for each row of pixels. IC112 and IC113 are the line counter ICs, which generate the Y-coordinate data. They are clocked by the H-sync pulse (SH) from the Matrox card and reset via the vertical reset pulse (RV). When the control software activates the light pen, it sends a low pulse to pin 4 of IC109b and if either light pen button is active, pin 3 of IC121a goes low. This is the LPEN ACTIVE signal, and it releases the set input on IC118b, thereby allowing it to accept data from the light pen on its pin 12. When the light pen ‘sees’ a pixel, its output falls low. This becomes the data signal for this flip-flop. Most of the time there is no signal, so a high level is clocked to the Q output (pin 9). But just after the rising edge of the CLK pulse, if there is a pixel detected, a low level is clocked to pin 9. This is important because, as mentioned earlier, the 74LS161 counters require that the clock pulse is high when the enable TE input changes state. A master control flip-flop was created with two 74LS00 gates, IC120c/d. When the pixel is detected, several things happen. Pin 11 of IC120d goes low and the red ACQUIRE LED lights up. The 74LS161 counters are disabled via their TE inputs and stop on their current count value, corresponding to the detected pixel. Their reset inputs (CLR) are also inhibited by the outputs of 74LS00 gates IC122a/b, so the 74LS161 counters ef- The top of the completed interface board in the top slot of my SOL-20 computer. The stickers which label the ICs and the test points were made on a Brother label machine. 92 Silicon Chip Australia’s electronics magazine siliconchip.com.au When making a prototype, it is essential to avoid an out of control “Bird’s Nest” of wires. I used lengths of solid, uninsulated wire down the middle of the ICs for power and Kynar (wire wrap wire) soldered point-to-point style for signal connections. These wires were routed to avoid covering any IC pins and bundled up to keep everything neat. fectively latch the pixel coordinates when a pixel is detected. At the same time, output pin 8 of IC120c (FLAG1) goes high. This is the signal which alerts the software that the 74LS161 counters are latched in a stable state and holding the X and Y pixel coordinate data. This signal also enables the reset signal for the latch during subsequent vertical retrace events, allowing the computer to reset FLAG1 once it has read the X and Y coordinate registers. The FLAG2 signal is defined by IC119c/d, wired as a flip-flop, at output pin 11. This flag indicates which button is being pressed on the pen, alerting the software to either illuminate or rub out a pixel. The state of this flipflop indicates the last button pressed on the light pen. This is implemented in hardware in the interests of speed. Building the interface As I mentioned earlier, I built the light pen interface on an S-100 bus prototyping card that already had provision for the bus interface ICs. You can see the resulting layout in my photos. I arranged the logic ICs on a grid in the prototyping area. I then wired it up using PTFE wire wrap wire (Kynar), except I didn’t actually wrap the wires. Each wire is individually soldered. I arranged the route of each wire so that for the most part, the wires do not cross the soldered IC pins (except locally when one IC pin connects to another on the same IC). This is important because as the number of wires increases, it becomes siliconchip.com.au difficult to get at the IC pins for soldering. I found it best to wire the power supply pins up first along with the monolithic ceramic bypass capacitors for each IC. I then checked that was all good before proceeding to the signal wiring. The power rails run down the middle of the ICs using uninsulated goldplated solid wire which I bought in Akihabara, Japan. This makes it easy to wire the usual pin 14 (or 16) and pin 7 (or 8) to the supply rail and common. Watch out for the non-standard power supply pins on the 74LS93! I used small loops of insulated wire to hold down the bundles of wire to the PCB’s surface, keeping it all tidy. For the signal runs, I used multi-coloured PTFE wire with 0.32mm diameter conductors, as this makes it easier to trace the wires. Since it was a prototype, I fitted and labelled many test points. I made these by soldering gold-plated loops to spare ‘doughnuts’, suitable for attaching a scope probe, and coloured glass stand-offs. The DB9 connector for the light pen was screwed to two 2mm metric hex posts mounted to the board with two extra 4-40 UNC threads cut through their walls. Testing and software First, I checked the port decoders and made sure everything there was working perfectly before proceeding. Although the final software was written in Intel 8080, BASIC was an invaluable tool to quickly test ports with INP and OUT instructions. I Australia’s electronics magazine also wrote a software driver in BASIC (MBASIC on my SOL), but it’s just a little too slow for my liking. Still, it is much quicker for debugging and testing than the assembly language program, at least with my programming skills. The software is simple and interactive to a degree, with some on-screen messages that appear on the SOL-20’s text video monitor. The graphics monitor/VDU is a separate video monitor for the graphics display, driven by the ALT-512 card’s video output. Upon starting the program, the A plane is illuminated (all pixels on) and a one-pixel border is created in the B plane. Both planes are initially visible. The light pen becomes active if one of its buttons is continually pushed, say the pixel-on button. If the pixel off button is pushed instead, you can rub out previously illuminated pixels. So an image can be drawn while the program is running. It’s terminated by pressing E on the keyboard. After the image is drawn, if you press M, the program escapes to “Mode Control”. This is the graphics mode that controls the display register of the ALT-512 graphics card. For example, in this mode, the “Illumination Plane” plane A can be turned off, just leaving the B plane alone, with the image that has been drawn with the light pen. Also, in the Mode condition, if the R key is pressed, it returns to the light pen loop to keep adding to the image if you wish. For those who are interested, the 8080 code can be downloaded from the Silicon Chip website. SC November 2020  93