This is only a preview of the November 2020 issue of Silicon Chip. You can view 44 of the 112 pages in the full issue, including the advertisments. For full access, purchase the issue for $10.00 or subscribe for access to the latest issues. Items relevant to "Eight Small LED Christmas Ornaments":
Items relevant to "Two Large LED Christmas Stars":
Items relevant to "Balanced Input Attenuator for the USB SuperCodec":
Articles in this series:
Items relevant to "Flexible Digital Lighting Controller, part 2":
Purchase a printed copy of this issue for $10.00. |
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
|