This article originally appeared in My little (home) shop thread on Practical Machinist.
That’s the contents of the character generator ROM on the Fadal video card. I used a Parallax Propeller development board to make a breadboard EPROM reader.
I’m interested in making a video card that will plug in place of the Fadal card and output a video format of my choosing.
Specifically I’m talking about using a Parallax Propeller microcontroller to generate a VGA signal. The picture is actually the Propeller outputting the ROM data to a VGA monitor.
With the Propeller I can add pseudo color when the coordinates are displayed in the upper left corner of the screen. I could also add a clock to the upper right to display the current time.
With access to the video RAM data I can add more visual capabilities to the machine without the machine even knowing what’s going on.
This would enable me to upgrade the screen to an LCD without spending the ridiculous sums that people charge for Fadal LCD upgrades.
The Fadal chargen ROM only implements 64 of the 128 glyphs in the character set, the other 64 are filled with blocks. I suspect the other blocks may be pseudo graphics that are part of some easter egg in the control.
The characters are 16 lines tall, and the screen is 40×25. I suspect the blank 8 lines below the characters are for the second field, the video card only outputs 1 field worth of data, because NTSC is interlaced you have 2 fields and I bet they just do a blank line on the second field. The graphic characters don’t have blanks in the second 8 lines, so they would implement a double high character in the even and odd fields.
Looking at the data again, I think I’m overthinking it. They put a 4KB ROM on the board, but only used the upper 2KB, and only half of that was used for actual glyphs. I see that the unimplemented glyphs actually repeat every 16 characters, so I suspect it’s just random stuff that was left over from whatever program they used to generate the character glyphs.
I’ve figured out the basics of how the video card works, based on this card and later cards. Later cards used a dual port 1KB RAM so the CPU could talk to the video card while the video data was rendering to the CRT. The older cards required the CPU to share time with the video rendering circuitry, I believe this may cause a waitstate in the main CPU, reducing the block execution rate. By going to dual ported RAM they can eliminate that waitstate and execute faster.
The video card works by generating an asynchronous clock on the board, which drives a set of counters. The RAM data lines are directly connected to the A4 through A10 address lines of the chargen ROM, using the ASCII code for the character to lookup the block of 16 bytes for each character. An external counter iterates through the 16 lines to generate the scan lines on the CRT. The signal is turned into a Black and White composite video signal which is sent to the video monitor. The video data is generated by a shift register that takes the bit pattern output of the chargen ROM and shifts it out as black or white dots to the video monitor.
I’m working up a schematic right now to help understand exactly how the memory arbitration scheme works, I assume the video card asserts asserts a wait signal while it’s addressing and reading the memory, then during the vertical sync interval the CPU has access to the RAM. This means the CPU can only update the display about 30 times per second. It’s curious that the maximum block rate on the old controls was 27 blocks per second, pretty close to that waitstate interval.