Reverse engineering Emco CNC video controller

During renovation of Emco Compact 5 cnc-lathe, I got my hands on scrapped electronics of original control cabinet. I saved some of the more interesting boards, like one that acts as rudimentary GPU. Whole video board was separate add-on, that contained video processor, video RAM, character-ROM and RS232 transceiver, and connected to main CPU board with large 32pin bus connector.
I took my multimeter, scope and logic analyzer, and stared to reverse engineer the mystics of this video controller.

Board in question has infamous Motorola 6845 CRTC, which was very common video IC of that era. MC6845 could be also found from many other computer systems, from Apple II to IBM PC CGA video adapter. Not only in computers, MC6845 was used also in many video terminals and other systems, that needed ability to show text and graphics on CRT monitor. Later functionality of MC6845 was transferred to more modern video adapters like EGA and VGA.

Maybe popularity of MC6845 came from its simple but versatile design. On the bottom, it was just programmable timing generator, that provided horizontal and vertical sync pulses, and scanning for video memory address bus. It could not draw pixels on screen by itself, and needed bunch of other logic and memory circuitry to make usable video output.
Emco video controller has 2k SRAM, 32k ROM and discrete logic for creating needed signals and graphics. Due simplicity of circuitry, it is limited only to alphanumeric mode, where ram stores character code at specific display position, and characters are shown from ROM. Board was used only to show simple table of CNC G-code instructions during programming of Emco lathe, and simple video interface was enough to do that.

Hardware

Nothing beats old fashioned notebook and pen

I began to reverse engineer board with flying probe technique, where one lead of continuity tester is held on desired point, and other one is dragged trough all of the IC pins, until connection is found. I had pinouts of every IC on board, and quickly managed to map out connections of CPU bus connector. This was not enough to understand workings of video controller, but gave some clues how system was transferring binary data to human readable display format. Board has motorola style bus, that has 8-bit data line, and 11-bit address lines with some additional control signals.

I continued painstakingly map out every connection between IC’s and passives on board, and trough measuring and noting down I had pretty good idea, how everything connected together. I managed to draw full schematic, that shows how system is put together. I also divided components in logical blocks, that describe functions of component groups.  Roughly, it contains CRT controller, RAM address bus switching, RAM&logic, Character generation and video output, output buffering, and finally clock generation.

As you can see from schematics, video RAM is connected trough 3 digital address switches and 2 data buffers. When CPU wants to write data on video memory, RAM is disconnected from CRT controller, and connected straight to CPU. Then CPU can read and write memory as it wants. During this time video output is still active, but shows artifacts due missing ram scanning. When CPU is done, it returns control of RAM to CRTC, that keeps scanning trough RAM address bus, timing scans to horizontal and vertical sync cycle.
Output of video RAM data lines are connected straight to lower ROM address inputs. Also, row address line from CRTC is connected to upper address input of ROM. CRTC selects pixel row of character burned in ROM, and data from RAM selects character to be displayed. Data output of ROM is connected to shift register, that converts parallel output of ROM to serial stream of bits. Clock circuitry and CRTC keeps serial stream in sync with character and H&V -sync. Then outputted serial stream is added to sync signals and buffered to video output.

If you know how CRT television works, it is possible to follow working of Emco videoboard.
First, vertical sync tells that we are in upper left corner of display. CRTC selects line 1 from character ROM and first character from RAM. First row of 8 pixel wide character is loaded onto shift register, and pixel clock fires out black and white dots into the video signal(1). When this is done, CRTC selects next character from RAM, and this is repeated until first line is full.Then CRTC selects line 2 from ROM and again first character from RAM(2).

Second line of characters is outputted into video signal. This continues until whole 16 rows high character row is drawn on screen, and CRTC moves one row of characters downwards in RAM. Now whole thing continues as previously, until whole screen is filled, and returns at the top of display(3).

It may seem complicated at first, but knowing how television and raster scanning works, it is similat to that. There is just multiple repeating scannings done, one inside the ram and character rom, and another on display output image.

Software

After I had schematics, I could focus on software side of controlling the Emco video board. CRTC IC itself has dataline for writing bytes into control registers. These registers tells the CRTC how to time different sync signals, how to scan RAM and ROM and other important configurations that drive video signal. In this case, I had to get original register values from Emco CPU, so I could determine timing and memory layout correctly. First i read content of CPU ROMs, but I could not disassemble them correctly to get those register variables. Then I just connected logic analyzer to CRTC chip, and recorded initialization sequence. I got values of all the 15 register bytes. MC6845 CRTC datasheet had table for calculating these values from given timing and geometry.  I just reversed formulas, and was able to determine that display was configured in 27×14 characters mode, and every character was 7 dots wide and 16 lines tall. Timing were otherwise normal for PAL tv, 50Hz frame rate and 15.625Hz horizontal sync. That gave just 224 active PAL lines, as CRTC was initialized in non-interlaced mode. I made handy excel workbook, that can be used to calculate values for MC6845 based systems.

I connected video board to arduino, and made simple sketch that emulates CPU bus, and writes bytes into the CRTC registers and video RAM. Bus structure is quite simple; different ICs just have their own memory address range, where data can be written or read. Arduino then fills ram from text array and shows predetermined text on screen. I were able to push resolution up on modern LCD screen that shows overscan area and doesn’t need trace return times. Original character ROM is very limited, and only contains characters that are needed for CNC operation. Notice how bottom of character set just repeats inverted characters. Unlike CGA and other systems, Emco video controller is so simple that there isn’t any text effects. It would need addition hardware to  underline and invert characters, so Emco opted to do inverting on character ROM. 256 character space is enough to do that, if charset is reduced just to minimal alphanumerical display.

I removed character ROM IC from board, and plugged it into old Data I/O 21A prommer. I was able to transfer data it contained to computer over serial link, and got binary rom dump. ROM layout is 2048×16 1-bit bitmap, that contains all 256 characters that are 8-bit wide. It was trivial to convert binary data to image file. Rightmost pixels of characters are ignored, as character clock is divided by 7 from pixel clock. Memory is still organized as 8×16 characters, so when converting to image there is black stripe at the end of every character. In display this is not shown, and is skipped.

For my purposes, original character set is too limited to display anything fun. It lacks even lowercase letters and most punctuation marks. Luckily, I have EPROM programmer on hand, and making and designing bitmap fonts is not that difficult. 7×16 font size is bit difficult to design, but doable. I made character set based on Apple II. First 31 characters are usually used as control characters and cannot be printed, but in many systems they contained some glyphs and symbols. I think these symbols became quite standard.I converted new character bitmap back to binary file, borrowed UV lamp so that I could erase original ROM, and then burned new content with prommer.

Now I had bit more usable character set, that had all 256 unique ASCII characters. Also interesting note that characters are rendered closer to 1:2 ratio than 1:1. It would be possible to reduce characters to 8×8, and get double of vertical rows, and even more in interlaced mode, but text would be unreadable due low resolution of composite video signal. Maybe using MDA monitor and separate Hsync, Vsync and video line one could get much higher resolution out from this video board.

Here is iteration of arduino sketch I used to get text on display.

I have no definitive plans where to use this board. Initially I was thinking of text based video game console, but I have no time or great desire to make one. Or maybe I could borrow this design for video controller if I some day build retro computer. Anyway reverse engineering old video system was good challenge and exercise, and was good way to learn more about old CPU buses, video signaling and graphics generation.

Here is archive of all romdumps, schematics and fonts I used and made during reverse-engineering: Emco Compact

PS. I lied when I said it could not do graphics, it is possible using 7×16 pixels ;)

You should put your comment here!