Fadal 1400-1 CPU Card Reverse Engineering and Schematic

This article originally appeared in My little (home) shop thread on Practical Machinist.

I only worked on the CPU board schematic a few minutes today, but I finished all the address decoding logic.

The 8088 only has 20 address lines, of that, 16 of them are used for addressing segments of 64KB each. The address lines A16 through A19 are used as card selects to talk to the peripheral cards. There is a 4 to 16 line decoder that takes the upper nibble of the CPU address, then converts that to a selector that is 1 of 16 lines on the bus. Fadal repurposed a bunch of address and logic lines to make these card selects.

A 20bit address is represented as 5 hex nibbles, like 0xFBC00, that’s segment 15, address BC00. That happens to correspond to the video memory on the video card. The first F selects card 15, which is the video card (we are talking base 0 numbers here, so 0-15), the BC00 selects the base address within the F segment. The F segment also contains the system ROM, which is located at FE000-FFFFF, an 8KB chunk. The video ram is only 1KB, so it occupies addresses FBC00-FBFFF.

It would seem that the memory expansion cards occupy a card select range, though I’m not certain exactly where the memory and NC executive ROMs are mapped yet. Once I have the schematic completed and the system ROM reverse engineered, I could design my own memory expansion card.

…some time shortly thereafter

I’ve finished the reverse engineering of the CPU board schematic, all except the little bit that does the battery backup of the memory (trivial).

Here’s what I learned:

The system ROM, which boots up the CNC control and tests things, is located at 0xFE000, the lookup table ROM is located at 0xFA000, but only the last 2K is used, so the table starts at 0xFB800.

The U3 user ROM, which contains 1/3rd of the NC executive, is at 0x00000, U4 is at 0x08000, and U5 is at 0x6000, with the onboard 32K of RAM at 0x68000.

A little peeve/note about Fadal CPU boards: They DO NOT HAVE 38K, this is just a confusing doublespeak by sales/support people.

The CPU has 32K of RAM, the video card has 1K of RAM, and each of the axis cards have 1K of RAM, that adds up to…you guessed it, 38K!

I have to look at the code to figure out where the rest of the memory expansion address space is, but this is what I know:

Segments 0x10000 through 0x5FFFF are open, that’s 5 segments of 64K, or 320KB. I’ve read that the early boards are limited to 422K of RAM, so if we break that down from marketing speak:

32K on board
320K expansion
6KB on the peripheral boards

That leaves 1 more 64K chunk somewhere in the address space that isn’t contiguous to the 64KB of ROM down low and the 32K ROM+32K RAM at 0x60000.

I’ll have to dig into the code to figure out when it senses the memory add-on cards and where they are located.

The 8088 processor can address 1MB of memory, given the way they laid out the memory now, they’ve got a couple of holes in the address space, however due to the goofy addressing scheme where each segment is tied to a board select on the bus, they probably allocate 5 segments to the axis drives and maybe some more.

Nothing really surprising or enlightening with the CPU card, all very straightforward, the most confusing part is the power on reset circuit, lots of annoying analog stuff to initiate the CPU reset.

Fadal 1400-1 Schematic
Fadal 1400-1 CPU Schematic

Fadal 1420-1 Video Card Reverse Engineering and Schematic

This article originally appeared in My little (home) shop thread on Practical Machinist.

I finished my reverse engineered schematic of the Fadal 1420-1 video board. I’d estimate I have 20-25 hours into the schematic at this point.

The schematic, and observation of the control display, lead to some interesting observations about the original design.

It’s widely told that Adrian de Caussin is the one who designed the control hardware, unfortunately he passed away some time ago (a reference from 1996 indicates he’d passed by then), so this public accounting may be the only hardware level details known outside of the de Caussin family.

I did reach out to David de Caussin the younger to try and learn details about the original control development, because at this point they are considered vintage computer systems. Unfortunately I didn’t receive a reply from him, so I had to go at it myself.

Up to this point I had dumped the character generator ROM, as seen in a previous post. This lead to some curious questions which I believe are answered by the schematic diagram, namely why each character is represented by 16 lines, but the latter 8 lines are blank?

Well, let’s start with some simple things we can observe about the video display:

First, the display is 64 columns by 16 rows. My research indicates this was a common format for S100 computers around the time the Fadal control was created. It makes sense then that the Fadal control would leverage some existing standards, but why roll their own video card instead of buying one or copying an existing design?

The second observation may give that answer. When the control goes into a mode where the axes are moving and the DRO display is active, it switches the top 6 lines of the screen into a doublewide mode. The top 6 lines become 32 columns wide and the characters become square. This is to aid in viewing the DRO output during operation. I presume the top 6 lines were chosen because the control is 5 axis capable, so 1 line per axis and then a blank line to separate the DRO from the scrolling portion of the display.

The third observation we can make is that the screen seems to flicker at times when the cursor is blinking, or the display is scrolling. This is answered too by the schematic.

So, let’s discuss some of the components of the video card and why it’s unique. I’ll just get the unique part out first: the video card is implemented entirely in discrete logic. This is like using a bunch of small PLCs or relay logic to implement something complex instead of an integrated control. Many video cards of the era were built around CRTC (CRT Controllers), such as the Motorola 6845, which was common in the IBM PC video cards.

Fadal generated the video with a bunch of 4 bit counters, a standalone 3.4992Mhz dot clock, and a shift register that is fed by the output of the character ROM.

The 64×16 display area is stored in a pair 2114 1Kx4 static RAMs, giving a total of 1KB of video RAM. This hints at why the screen has noise artifacts. The video generator circuitry is constantly running, generating a video display while the machine is turned on. The main CPU of the control needs to write characters to the video memory and copy the contents when the screen scrolls. The cursor is implemented by a routine that blinks the < on and off by updating video memory.

When you have a CPU that needs to read/write to memory and a video generator that needs to read the memory, there becomes a conflict. You could eliminate the conflict by signalling the CPU that the video display is during the vertical retrace (vertical sync) and only write to the RAM then, however this is not how Fadal did it. Video cards based on the 6845 can signal this vertical sync to the CPU, but the Fadal card simply allows the CPU to step on the video generator. That is, the CPU asserts control of the video memory, does its read/write, then deasserts control, allowing the video generator to read the video memory and render the screen. It’s this heavy handed control of the video memory that results in the visual artifacts when the cursor blinks or the screen is updated.

Looking at pictures of the later board revisions, they implemented a dual ported 1KB video RAM. This allowed the CPU to write to addresses arbitrarily and the video generator to read from the memory without any contention. The end result is that Fadal 1420-2 video card does not have the visual artifacts because the video generator can read the video memory while the CPU is writing and reading it. This point may seem rather minor to some, but for customers that paid the price of a small house in the 80’s, it was a subtle, but welcomed improvement. The video generator circuitry is really rather simple. The 3.4992Mhz clock is piped into a latch that selects between the original frequency, or half that frequency (more on that later). Then the clock goes to an 8 bit shift register, which is loaded with each line of the character bitmap from the char EPROM. The shift register shuffles bits via an invertor directly to the output driver chip, which then controls a 2N3904 transistor and some resistors make an NTSC compatible video output. There is other logic to generate the sync signals, but the basic pixel pipeline is short and simple. The main clock also drives several counters which control the address lines of the video ram, stepping through all of the character locations. This gets somewhat complicated because of the next feature.

The doublewide DRO feature of the video card is actually what is novel and uses up a significant portion of the logic on the board. If all you had to do was step through 1KB of ram and generate video lines, it could be probably half the chip count. The doublewide feature is enable by writing to the I/O port allocated to the video card. That I/O port is shared between the option bits (J2 where you specify baud rates and line voltage) and the double wide mode. In conjunction with a write to I/O port 32, the data line DO1 determines if doublewide mode is on or off. When a read from I/O port 32 is done, you get all the option bits. The Fadal control has the ability to set many of the critical hard power-on options in dip switches or jumpers. Specifically the backlash is settable in dip switches on the axis drive boards and the basic option bits are set on the video card. These settings are all adjustable via BL or SETP commands anyway, overriding the settings in the hardware.

The doublewide mode is generated by keeping each pixel on for twice the time, by using a video clock that runs at half speed. This results in overscanning the characters from the first 32 columns of the display, creating a more legible font.

So, to summarize, the Fadal 1420-1 video card was a clever piece of engineering, the primary complexity was driven by the need for a doublewide mode on the first 6 lines of the display and this is why Fadal didn’t use an off-the-shelf card or copy and existing card.

The 6845 CRTC doesn’t offer a double-wide mode either, but it offers other capabilities. I think that since the roots of the Fadal control were based on hardware they were already familiar with, the Altair 8080 S100 bus computer, they decided to stick to the late 70’s tech instead of embracing the early 80’s tech that existed at the time.

The IBM MDA Monochrome Display Adaptor used the 6845 CRTC, had 4KB of 2114 based static ram, and about 30% higher chip count, not to mention it was more expensive, by BOM standards. I think Fadal made the choices they did based on cost, owning the design, simplicity, and ease of manufacture. The board is a mix and match of 74 series TTL logic, with only a small number of costly components (RAM, EPROM, and Intel specific S100 bus interface chips).

Fadal 1420-1 Video board schematic

Fadal Chargen ROM Reverse Engineering

This article originally appeared in My little (home) shop thread on Practical Machinist.

Fadal Chargen ROM

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.

Fadal CNC Reverse Engineering

This article originally appeared in My little (home) shop thread on Practical Machinist.

Just to be clear, the control and electronics work fine on my Fadal at present, it was the iron that needed major help.

The process of reverse engineering the control started with researching the history of the Fadal control. On the VMC Electric website they give a few pieces of information about the process of creating the control.

They said they used an Imsai 8080 to develop the NC executive. If you read closely you’ll see they used the NC software to process G-code into NC tapes for their other machines. This specifically includes applying cutter radius compensation and other stuff that old NC systems couldn’t do.

Well, the Imsai 8080 was a clone computer of the MITS Altair 8800. The Altair used a bus comprised of 100 connections on a card edge, derived from a bunch of surplus mil-spec connectors they were able to obtain.

The S100 bus name came from the clone market being tired of referring to the Altair bus because Altair was a competitor. Later the S100 bus became standard IEEE-696, which was only retired a short while back.

Looking at the card cage in the Fadal control, it’s obvious they based their design on the S100 bus, which was popular back before the IBM PC came out. Prior to the PC many computers that hobbyists and enthusiasts used were based on the S100 bus design. This allowed you to separate the functionality of each subsystem into a separate card.

Fadal didn’t adhere to the S100 bus specification much, they mapped signals roughly into the same locations, but they went significantly off book. The power distribution is simplified and many of the S100 signals are not implemented.

The process of reverse engineering the cards done thus far (video and CPU) starts with Eagle CAD and the background investigation I did above. I used information from S100computers.com to make a custom part in Eagle which represents the S100 card edge and pinout. I also created several parts for the special Intel chips used for interfacing to the S100 bus and Intel CPU. All of the datasheets for the components are available online, you just have to search and follow the rabbit hole.

Once I had the components defined, I placed them in an empty schematic sheet roughly in the same location as they appear on the boards. Generally speaking, chips that are close to eachother on boards are functionally grouped, due to the routing requirements.

The Fadal boards are comprised of 2 layers, a top and bottom, this makes them easier to reverse engineer because I can follow the path through the boards. The top layer (component side) is generally devoted to traces (wires) that run horizontally between components. The bottom layer (solder side) is devoted to traces that run vertically.

The logic behind how the boards are layed out is based on standards for generating printed circuit boards. You find the east-west, north-south routing commonly on 80’s vintage stuff because they didn’t have sophisticated auto routers. It’s similar to the difference between a zig-zag toolpath and the tool paths generated by the new fancy HSM CAM tools.

The process of tracing each connection involves using a mechanical pencil as a pointer, a flashlight to see traces that go under chips, and a Fluke DMM in beep continuity mode. From that point it’s a matter of picking an interesting looking portion of the board and tracing the connections to the bigger chips. Then I work on bus interface chips and finally all the little logic chips spread around the board.

The boards are comprised of logic chips that implement one of the following types of operations: count, de-multiplex, boolean logic, and flip-flop. There are specialist chips that do very one dimensional tasks, like combine separate read/write lines into a single read and write bus.

Once you map out some of the signals, you can make inferences about what other signals are and avoid actually tracing those. For example, if you have a latch that has AD0 on one pin and A0 on the corresponding latched pin, then it’s safe to assume that AD1 is A1 and so forth. There are several chips like this, though you have to be careful because Fadal swapped some pin assignments to make board routing easier. This is a dead giveaway that a human spent considerable time looking over the layout and hand routing some, or many, of the signals.

Reading the datasheet and understanding what each pin does on a chip and how the chip functions, that allows you to perform a sanity check on the schematic and detect errors. There were several errors I made due to reading the wrong pin number (looking at the mirror image of a chip can cause these errors), etc. If you spend some time trying to understand what the designer was doing, you can use that understanding to validate the schematic and check it against the real board with a DMM.

Once I had the boards mapped out I could then go back to the software, which is straight machine code. Looking through the machine code I can search for addresses derived from the board logic, such as video display writes.

I discovered that Fadal put a secret diagnostic routine into the system ROM that causes the machine to self-test the keyboard, ROMs, and RAM. The diagnostic mode is triggered by inserting a jumper block into J2 of the video card, this is read at startup and if inserted it will go into diagnostic mode.

It displays this menu:


I’ve also learned that there is some peripheral in the 0x1000 segment that the control talks to a lot, and since I know RAM is at 0x6800, I know it’s not memory.

Looking at pictures on Ebay of memory cards, I see that the external memory cards can live at the following addresses:


But since 6XXXX is taken by the on-board memory, only segments 7-A can be used, limiting the control to 256KB of additional memory (two of the 128K cards). The 128K cards have 2 jumper wires on J5 that select the segments they belong in.

Now that I’ve learned this information, I can go back and search the code more. But based on my research yesterday, it may not be possible to run the original ROMs on a faster processor because there are delay loops that seem to depend on the speed of the processor. For example, fetching a key from the keyboard seems to involve some hard coded delays.

Anyway, this was all more for my understanding than any sort of commercial endeavor. The machine works as is, but I may use this information to increase the amount of memory in the system or make my own video card.

I can go to Digikey right now and pick up a 512KB ram chip for $6.44, that’s a heck of a lot easier to interface than 16 separate chips.