I was looking at the schematics of Apple II and Apple III floppy disk drive analog boards on Bitsavers late last night, and made a surprising discovery: the DuoDisk 5.25 dual floppy drive sold for use on the Apple II is actually directly usable on the Apple III+, with the full functionality the Apple III SOS operating system expects.
At the moment the floppy drive of my Apple III isn’t working properly, so I’ll have to fix that or replace it with one of my spares, though the spares aren’t necessarily in working order either. This evening I purchased a two-pack of inexpensive LED flashlights from Harbor Freight, and I plan to modify one, adding a PIC or AVR microcontroller, crystal, and NFET, to make a timing light for adjustment of motor speed. I hope that just adjusting the motor speed will be sufficient to get at least one of my floppy drives working; I don’t presently have a head alignment diskette.
In 1983, I mostly reverse-engineered the version 1, 2, and 3 (no revision letter) of the Infocom ZIP interpreters into source code that could be assembled using Microsoft ALDS on CP/M. Until recently, all that survived of that effort was a printed listing, which my friend Richard had preserved, and returned to me in 2002. I put a scanned PDF of the listing online, and . The listing has false conditionals disabled, so only the code for the version 3 interpreter is seen, with a two-instruction modification I made to display lower case. (Infocom’s 3A interpreter supported 80 column display with lower case on the Apple IIe.)
In the last few weeks, I retyped the source code, converted it to assemble with a modern cross-assembler, added back the conditionals for ZIP versions 1 and 2, and added the code for 3A and 3B. I’ve put it on Github. This source code will be used as the basis for the SOS port of the interpreter.
The display output and keyboard input code will have to be replaced with code that uses the .CONSOLE driver, and the disk I/O code, both for “story file” and save file access will have to be replaced with code that uses the SOS file system calls, which are similar to the ProDOS file system calls used on the Apple II.
I’ve added the DE-9S connector, TRS202ECN transceiver (equivalent to MAX202), and ceramic capacitors, which make up the TIA-232-F serial interface. The serial interface uses a female connector and is wired as DCE (Data Communication Equiment) to facilitate direct connection to a USB-to-serial adapter.
Not shown: two trace cuts and two orange jumper wires on bottom of main PCB.
Next I’ll need to get a VHDL UART working with my 1802 core.
My RetroChallenge RC2017/10 project was to update and improve my FPGA-Elf. The resulting hardware may be seen here:
I have succeeded in accomplishing my main goals for the project, which were:
- Update my FPGA-Elf design to use a currently-available, relatively inexpensive FPGA board/module
- Design a base PCB for the FPGA-Elf, using only through-hole components, and have it fabricated
- Implement CDP1861 PIXIE graphics
I originally wanted the new hardware design to use only currently-manufactured components, which would rule out both the HP 5082-7340 hexadecimal LED displays used by the original Elf and the TI TIL311 hexadecimal LED displays often used in more recent Elf builds. As an alternative I chose the Liteon LTP-305HR, which is a 5×7 dot matrix LED display, a drop-in replacement for the Monsanto or GI MAN2A or the TI TIL305.
I spent the first week of the RetroChallenge building a breadboard prototype of a six-character display using the LTP-305HR, with serial low-side and high-side drivers, and a MicroBlaze soft-core CPU in the FPGA controlling them. While I got the displays working, there were issues with the drive circuitry resulting in off pixels glowing, though less brightly than on pixels. I also did not like the appearance of the displays as much as the original hexadecimal LED display, so I abandoned the use of 5×7 dot matrix LED displays and proceeded to design my new board to accept either HP 5082-7340 or TI TIL311 displays.
I completed the PCB board designs by October 17th and placed the order for the boards. Due to the rush to get this done, there are a few minor errors in the board design that require some trace cuts and jumps.
While waiting for boards to arrive, I built a second breadboard prototype using the hexadecimal displays, and used it to design my CDP1861-compatible graphic display core. As with my earlier CDP1802-compatible CPU core, it is designed in synthesizable VHDL. There are no vendor-specific constructs except in the top-level Elf design which instantiates a Xilinx PLL clock multiplier.
The printed circuit boards arrived on October 23rd, and I assembled one on the 24th. After fixing one design error and removing one solder bridge, the FPGA-Elf was able to run my dice program.
By October 27th I had the PIXIE graphics fully working, running the PIXIE demo as shown in the July 1977 Popular Electronics article. I also ran my clock program. The FPGA-Elf is currently configured to run at 256 times the speed of an original Elf, so the clock runs at 256x real time. However, the clock display output is somewhat garbled, suggesting that my 1802 core has a previously undetected error.
Almost all of the project was done while I was out of town on a business trip. I returned home on October 28th, and badgered Richard Ottosen into cutting and drilling wood mounting rails for the FPGA-Elf, as seen in the photo. I have not yet done any further work on the hardware, FPGA code, or software.
I have quite a few Post-RetroChallenge tasks:
- Fix issue resulting in garbled clock display. (This issue will affect other programs also.)
- Publish design documents and source code:
- FGPA code for top-level design and CDP1861 graphics core (base Elf design and CDP1802 CPU core are already on github)
- Eagle CAD files for schematics and PCB designs
- PDF schematics
- PCB Gerber and Excellon files
- Add MicroSD and TIA-232-F serial port components to the board and test them. The serial port will require two more cuts and jumps, because I forgot to deal with the FPGA not being 5V-tolerant. Note that the MicroSD and serial port were not part of my project objectives; I included them in the PCB layout for future use.
- Write a manual, including BOM and assembly instructions (including rework needed for rev 0 main board)
- Update main PCB design to correct errors, and order rev 1 main board
- Update FPGA code for rev 1 main board
- Build and test rev 1 main board
- Add UART to FPGA
- Write 1802 code to support SD card
I have six extra sets of bare PCBs of the current design which are available for sale. I do not offer kits or assembled units.
Richard Ottosen cut and drilled some mounting rails for me, out of some scrap wood. They’re standard Elf size, 3/8 inch wide by 3/4 inch tall by 6 inches deep, each with four 1/16 inch pilot holes for #4 wood screws.
I’d vaguely considered the idea of nice stained hardwood rails, but that doesn’t really seem in fitting with the general COSMAC Elf idea.
I haven’t actually mounted the boards on the rails yet, because I still need to cut and jump a few PCB traces.
Once I put these babies on my Elf, she’ll corner like she’s on rails!
My VHDL reimplementation of the CDP1861 PIXIE graphics chip is mostly working! This still image looks almost the same as the one from a few days ago:
The difference is that now it’s being generated by the 1802 program (seen in the top 1/4 of the bitmap) actually running, whereas before it was hard-coded into the frame buffer memory to test the output half of my VHDL code.
Since that worked, I decided to try my clock program. Because the 1802 is running 256 times as fast as a normal Elf, I expected the clock to run at over four hours to the minute, and it does, but the graphics is garbled:
It’s possible that my 1802 core isn’t executing some instruction correctly, though it worked well enough to run a number of Forth programs on CamelForth. I’ll debug this using a VHDL simulator to capture a trace of my hardware design from reset to the completion of the first video frame, and a logic analyzer to capture the same from the electrical signals of the Elf II for comparison.
After removing one solder bridge, cutting one trace, adding one wire*, and changing a few lines in a Xilinx constraints file, My RetroChallenge Elf project has now let me successfully toggle in and run its first simple program, which is my old dice program.
I also learned how to program the FPGA config into the SPI flash on the Cmod-A7 module, so that the Elf is available after every power up. Suprisingly this is more complicated with the newer Xilinx Vivado development software than it was with the older ISE.
I don’t have a tripod here, so I won’t be able to shoot a demo video until the weekend.
* I’m going to claim that having blue wire-wrap wire for the bodge matching the blue of the PCB soldermask is due to good planning. Couldn’t possibly just be a coincidence.
Not everything is installed, but the power supply, data hex LEDs, most of the switches, and the composite video output are working.
The switch for data bit 3 doesn’t work because I wired it to an analog input pin of the Cmod-A7 module, and the FPGA internal pullup isn’t enough when the switch is on (open) to overcome the 2.4K series resistance on the module and bring the signal up to a logic 1.
I just hacked up more VHDL code to get the Elf hexadecimal displays working. I’ve only tested the data displays, but the address should work as well. This probably doesn’t sound like much of an accomplishment, especially compared to my original work on driving six multiplexed 5×7 dot matrix displays, but it’s not quite as trivial as one might expect.
While the original Elf only had two digits of hexadecimal LED display for data, my #retrochallenge FPGA Elf will also have four digits for displaying the address, particularly useful in load mode. While the Xilinx Artix 7 has quite a few I/O pins, the Digilent Cmod-A7 FPGA module only brings out 44 to module pins, and I can’t use 24 of them for the hexadecimal displays.
I originally considered having eight data lines and three each strobe and blanking lines (for the address high, address low, and data, and blanking isn’t really necessary), but I was in a hurry to route the board and it wasn’t as easy as I’d have liked to route two sets of four data lines to alternate digits. To make the board routing easier, I ended up with four data lines, six strobe lines (one per digit), and three blanking lines.
As a result, I had to write a state machine to detect when either the address or data has changed from the previous value, latch the new value, and sequence through updating all six digits.
I haven’t wired up the address displays on the breadboard, but the data displays are working fine. I’m now able to toggle in a short program, such as my dice program, and run it with the expected data display output.