, ,

I can`t actually remember when I stumbled uppon the famous CDP1802 based COSMAC ELF project. However I do remember that it immediatelly caught my attention as I admired the beautiful simplicity of the design. Of course I saw other front panel driven designs before, mainly Z80 and 8080, but it was incredible that you could put together a functional computer with memory and I/O with such small chip count at that time. Also the CPU itself was fascinating – so much different architecture from anything I knew before, just like it was designed by aliens or at least Russians 😉

I knew I want to build my own machine with CDP1802 and start a new journey with a new project ! The question was how would my project be like, what I want to achieve with it. First I thought about keeping it as close to the original COSMAC ELF as possible. I saw many successful attempts, one particulary pretty is even from Poland:


However I quickly abandoned the idea for two reasons: First – I doubt that I could do it as good as “hvman” user in the post above. Second: without strong expandability, I feared that the project would just quickly found its way to a shelf in my basement, and that would be the end of it. I`m sure I wouldn`t be motivated enough to learn the fascinating world of 1802 assembler beyond just a blinking LED program that would be mindlessly poked in to the computer from time to time for my or my friends amusement.

I was then sure, the project will look different. I knew, that I wouldn’t just be ok with some simple expansion header and memory mapped I/O. That would be too simple and too similar to other projects. I wanted to utilize 1802’s built-in I/O subsystem, so to get a good feeling of it. At the same time I was also sure that I want my computer to be still “ELF compatible”, so the toggle buttons and RAM at 0000h must stay. That led to an idea to finally go for a real, serious front panel computer, more in a style of Altair 8800 that was the first front panel, ROMless, but extendable toggle button programable computer that I saw and immediatelly loved 🙂 The project that is maybe the closest to my imagination is the Astrorat’s Retro Elf project. Now that’s a real beauty right there! check it out in a link below:


That’s basically the idea that I’m now following, and I would like to share the build progress with you.

As a first stage, I bought necessary components and started breadboarding a classic COSMAC ELF circruit. I highly recommend to start with http://www.cosmacelf.com/ and from there: Publications -> Books & Papers -> COSMAC ELF Manual and Build Details. Paul Shmidt did a great job of creating manual and build details of the classic circruit. His schematics on single A4 page describe just every detail needed to build the machine and test it`s basic functions. Important signals and circruit elements are carefully labeled and described. You really need just a single A4 page and handful of components to build the complete machine from scratch ! Here is my breadboard version of the classic ELF, it does not have TIL311 displays yet (package from China was lost in the transit), so I have to make a quick substitute out of standard 7-segment LEDs and ATF16V8 GALs:

I played aroud with this protoype for a while, mainly to get used to the user interface. It took me some time to get fluent with entering, reviewing, correcting and running the code.I may say that when you finally get the idea behind it, it becomes your second nature and you find it oddly satisfying :).

In the second stage, I decided to partition the prototype to separate boards that will fit into a passive backplane. This step also implied some circruit adjustments and modifications, which I’ll describe later. I’ve made a point-to-point soldered prototypes of:

CPU and control board:

ELF specific I/O board with toggle buttons and LED display support:

Memory board:

I/O frontend interface card:

All the cards are sitting on a passive 39-pin wide backplane:

Odd number of pins comes from the readily available prototype board with long stripes, that I bought instead of making it. Its solid, sturdy and looks good. As it turned out, one pin less than typical 40pin did not made any difference in the design process – number of pis was just enough. As you can see in the picture above, there are some tracks that were cut just above the third godpin slot from the bottom. The idea was like this: the basic 3 cards composing a standard ELF require most of the CPU signals. However the I/O devices that I will add in the future do not require many of them – mostly address bus and few control signals are not used. To avoid unnecesary wired inter-card connections, I decided to replace the signals that are irrelevant to I/O circruity with more useful ones on the top 4 goldpin connectors. The generation of new signals is taking place on the I/O frontend card, which makes it a separator element for the “core” ELF and the I/O section. It’s a good moment to present the bus connector pinouts: the core section and the I/O section respectvely:

Core sectionI/O section
15(NOT USED)15/IO4
16N2 / LOAD16/IO5
28MA428/IO RD
29MA529/IO WR

Let’s now focus on the specific details of each card. I will not include the full schmatics right now – they will be available when I’ll be moving to dedicated PCBs.At this moment it’s just important to understand what changes had to be made to the original circruit in order to make it modular.

CPU and control card:

It consists of the CPU itself, crystal oscillator, DMA IN flip-flop crcruity, control toggle buttons debouncing and strobe signal generation for ELF 8 toggle buttons and LED displays. Important modification was to fully decode the N2 and SC1 signals. For classic ELF it`s unnecessary, because we are using only one I/O address (N2=1 , N1, N0 = any) and one state signal. With fully expanded ELF it makes a difference, as any state and I/O address that contains N2=1 and SC1=1 will also trigger the core ELF circruity (the flip-flop, toggle buttons and LED display).

ELF specific I/O board

No significant changes. Only some buffer gates had to be added, as now I`m not able to “borrow” any unused CD4049 and CD4050 gates from the CPU and control section.

Memory card

Consists of 32KB RAM, 32KB ROM, a transparent address latch, and a simple address decoder that consists of just a single NOT gate on the A15 address line (“after” the latch)

I/O frontend card

This circruit generates chip selects, IO WR , IO RD signals for I/O devices, and also contains a latch (seen as a I/O 1 device from the CPU). This latch provides register select signals A0-A3 for I/O devices. It is necessary, as in 1802 architecture we can`t use address lines to select registers in I/O devices. New signals are now placed on the bus instead of the irrelevant ones, and the system bus becomes divided in two sections.

Having all cards connected to the backplane and powered on…

…we may enter a small program that will test the memory subsystem: It will display the contents of ROM memory (starting from 8000h) on the LED display byte after byte. Toggling the IN button will advance to next byte. Here is the program listing:

0001   0000             ; Demo program 1 - reading bytes from ROM memory (8000h) and displaying on the LED display
0002   0000             ; Toggling IN button advances to next address. 
0003   0000             				.org 00h
0004   0000             
0005   0000 E1          				sex R1
0006   0001 F8 80       				ldi 80h
0007   0003 B1          				phi R1
0008   0004 F8 00       				ldi 00h
0009   0006 A1          				plo R1
0010   0007 64          display:		        out 4
0011   0008 37 08       				B4 $
0012   000A 3F 0A       				BN4 $
0013   000C 30 07       				BR display
0014   000E             		
0015   000E             				.end

Here are the contents of the ROM memory:

And here is the effect:

Now let`s connect first true I/O device, which will be the 16450 UART. Thanks to the I/O frontend card doing all the address and control signal decoding, we only need to connect the UART chip itself (and a TTL to USB converter of course):

Here is an example program, that will initialize the UART for asynchronous transmission with typical settings: 9600bps / 8bit data / 1 bit stop / no parity / no flow control, and will send out just few characters over the serial line.

0001   0000             ; Demo program 2 - writing characters from RAM to UART
0002   0000             ; Toggling IN button advances to next character from memory. 
0003   0000             				.org 00h
0004   0000             
0005   0000 E1          				sex R1
0006   0001 F8 00       				ldi 0h
0007   0003 B1          				phi 1h
0008   0004 F8 15       				ldi LO,data
0009   0006 A1          				plo 1h
0010   0007 61          				out 1
0011   0008 62          				out 2
0012   0009 61          				out 1
0013   000A 62          				out 2
0014   000B 61          				out 1
0015   000C 62          				out 2
0016   000D 61          send_chars:		        out 1
0017   000E 62          				out 2
0018   000F 37 0F       				b4 $
0019   0011 3F 11       				bn4 $
0020   0013 30 0D       				br send_chars
0021   0015 03 83 00 0C data:			.db 03h,83h,00h,0ch,01h,00h,03h,03h,00h,41h,00h,42h,00h,43h				
0021   0019 01 00 03 03 
0021   001D 00 41 00 42 
0021   0021 00 43 
0022   0023             		
0023   0023             				.end

Below we can watch the program in action:

There are so many things to do now. Here are some ideas that I`m considering to do next:

  • Write serial downloader code for rapid development.
  • Design and code a ROM momitor program.
  • Design and etch PCBs for each card
  • prepare cards for: UART, video, audio, keyboard, parallel I/O, Compact Flash…
  • Make some research and testing of front panel ideas and solutions.
  • Create a slow clock and single step circruit.

I will be reporting my progress in upcoming posts.