They went back to experience Woodstock, the Gettysburg Address, the Sermon on the Mount. They found the same thing at every major historical event: the audiences consisted entirely of time travelers.
Not only have I not posted any Retrochallenge updates here, but I just noticed that the MariaDB instance was down, for no obvious reason, preventing the blog from working. I started it up again. The real reason for the lack of updates here is that it’s so much faster and easier to tweet about the progress.
I’ll try to gather up some of the stuff I’ve tweeted and write it up here, but here’s an overview of the progress:
- Drew up schematics and PCB layouts for two boards, and submitted both to fab
- The stage 1 board is a very simple double-sided board that interfaces an 8008 to an FPGA board, which has a Xilinx Artix-7 XC7A100T FPGA, and will make it relatively easy to test my RTL code.
- The stage 2 board is a smaller four-layer board with a CPLD that interfaces the 8008 to a Z80-style bus. This board took much more effort to lay out. I originally intended to not send it to fab until the stage 1 board was working, but then there would have been no chance of having it back before the end of the month.
- Received the stage 1 board and parially assembled it: photos
- Started debugging the stage 1 board. Errors found so far:
- I screwed up my Eagle footprint for the DIN 41612 type R male connector. The rows (A, B, C) are correct, but the pin numbering (1 through 32) is reversed. Fortunately the FPGA board uses a symmetric layout so the power rails and ground are still on the correct pins. I just had to redo my Vivado pin constraints file. The 20 MHz oscillator output unfortunately does not end up on one of the FPGA’s global clock inputs, which causes an error, but that can be overridden by another constraint.
- The data bus signals being driven by the FPGA look funny. While trying to track that down, I discovered that the 74HCT245 data bus buffer was hot enough to burn my finger. There must be one or more shorted outputs, which I now need to track down.
My RC2019/10 project is to design and build a new CPU board using the Intel 8008. The 8008 was Intel’s first 8-bit microprocessor, first announced in April 1972. The 8008 architecture was based on that of the Datapoint 2200.
I’ll try to get the LLL DODT monitor running on it, or something similar. It would be nice to have other demo programs, but I haven’t decided what to write.
I reviewed the 8008 datasheet last week. Because the 8008 is a PMOS chip, it requires two power supplies, +5V and -9V, but does not have a ground pin. Effectively it runs on a single 14V power supply, but referenced to +5V. All of the 8008 signals are almost TTL compatible. Vil(max) is 0.8V, which is fine, but Vih(min) is 3.5V, which cannot be guaranteed when driving from bipolar TTL families. However, given how slow the 8008 is, for all pins but the clock, adding a pullup resistor would probably be sufficient to solve that problem.
While most early microprocessors required multiple-phase MOS level (high voltage) clocks, I had forgotten that the 8008 clock inputs have the same electrical requirements as the logic signals.
For my CPU board, I plan to use two SN74AHCT245 8-bit bidirectional bus buffers, one for the data bus and one for the other 8 unidirectional signals. (Bidirectional buffer chips make perfectly fine unidirectional buffers.) Being CMOS, the AHCT family will drive outputs high to nearly 5V, easily meeting the 8008 Vih(min) requirement. The “T” in AHCT indicates that the chip will accept TTL input levels, rather than requiring CMOS levels. The AHCT family is similar to the HCT family, but much faster; the SN74AHCT245 maximum propagation delay is 8.5 ns, vs. 28 ns for the SN74HCT245. Not that the 8008 needs fast timing.
The normal 8008 operates with a 2 us clock cycle. While there are various constraints on the timing of the clock phases, there is some flexibility. There was a speed-binned 8008-1 which was rated to operate with a clock cycle as short as 1.25 us. To operate the 8008-1 at the minimum clock cycle, there is no flexibility in the clock phase timing at all.
I can derive suitable timings for both 2 us and 1.25 us cycles from a 20 MHz clock input, using a counter and decode logic.
The first version of my 8008 CPU board will be designed as a daughterboard to plug into an FPGA evaluation board I have on hand, to let me easily develop the HDL code that I will later put in a CPLD in a later version, which will be much less expensive.
I’ve been curious about some details of how the Apple II emulation disk for the Apple III works, so I’ve been working on reverse-engineering the code. I’ve just put it up on github.
The first 1 1/2 tracks of the disk get loaded into memory from A000..B7FF. That loads the Apple II ROM images into memory from 2000 up. Then it gives the user a chance to change some configuration options. Finally it copies the ROM images into place, does some more hardware configuration, sets the hardware Apple II emulation mode, and jumps into the Apple II monitor ROM.
On Twitter, Mike Finger (@Retro2Neo) mentioned that he used a Python script dsk2po by @paulhagstrom to convert the sector order of Apple II floppy disk images. I just needed to do that this week for Apple III images, and not having been aware of dsk2po, a few days ago I wrote reinterleave.py a to do the same thing. Currently it can convert between physical order, DOS order (which is what most .dsk images are), and ProDOS/Pascal/SOS order.
Because of the lack of working Apple III floppy drives, I made a cable to connect a BMOW Floppy Emu to the Apple III internal floppy connector. The Apple III uses a 26-pin cable to the floppy drives, while the Apple II uses a 20-pin cable. Pins 1-20 are wired identically; the extra pins on the Apple III are used for additional signals for daisy-chaining extra drives (up to three total) and supporting Apple II emulation mode. I took a 26-pin cable, split off six wires at one end, and installed a 20-pin header.
After copying some Apple III floppy images to the MicroSD card, I was pleased to find that it works just fine. I’ve been able to boot SOS 1.3 with Business BASIC 1.23, and Pascal 1.1.
In addition to the internal floppy drive that came in my Apple III, and which does not work, I have three additional spare internal floppy drive mechanisms. Today I tried all of them, and found that none of them work well enough to boot an Apple III disk written from a disk image file by my Apple IIe. The disk format is identical to Apple Disk II 16-sector 5.25-inch format, and the Unidisk 5.25 drives I’m using on the Apple IIe haven’t had any trouble reading and writing any other disks from a large collection from various sources, so I’m pretty sure the drive on the Apple IIe is not the problem.
Having four non-working drives made me think that perhaps the floppy controller, an integrated part of the Apple III motherboard, might be bad. I switched to my spare motherboard, and didn’t have any different results.
I also have an external Disk III drive. I tried cabling that to the internal drive port, in place of the internal drive, and was able to successfully boot the Apple III Dealer Diagnostics disk. That mostly worked, and I was able to test the RAM and ROM of both motherboards. Both are the later 5V configuration, one with a 5V 256KB memory board, and one with a 5V 128KB memory board (which could easily be expanded to 256KB).
I say “mostly worked” because the drive did give I/O errors trying to load some of the diagnostics, or to display a CATALOG of the diagnostic disk. So really, I have five Apple /// floppy drives that aren’t working properly.
The floppy drive in my Apple III is not working well enough to boot floppies written on my Apple II. I think the spindle motor speed may be off. I’m hoping that’s what it is, since it’s the easiest thing to fix. I’m putting together a timing strobe light to measure it, using a microcontroller and an inexpensive Harbor Freight LED flashlight.
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.