Double Action Pseudo Disk
What's available now.
The current version's features:
- Loading disk images to an SD/MMC card under FAT16. However the files must be written to newly formated or blank media so that files stay contigous.
- Three modes selectable by DIP switches: old raw images mode, selection from FAT directory by name and automatically booting the FIRST (ProDOS) image.
- BASIC selection program no longer needed. Almost instant booting.
- Comes with 128 MB SD card that contains the boot sector with selection program, a 32 MB ProDOS volume with hundreds of games and 4 NIB images (DOS 3.3 master, CPM, Lode Runner and DOS 3.3 volume with a few more games). Add your own images. 512 images will fit.
The project history
So after a couple of decades I decided to play some more with Apple 2
computers. I dug out the ancient ][ plus from the garage. I got a "new" //e on Ebay. The problem is that
most of the software exists in the form of disk images on Asimov and other servers. I used ADT to create 5.25" floppies out of some images, but it's not much fun. 140K does not look like a lot in 21st century either.
There are modern solutions for ProDOS - at least 2 different CF interface cards. But they are already designed. No fun left for me. In addition not all old software can use ProDOS volumes.
So I have decided to create my own solution: a dual purpose card that will do everything that
a CF card does and in addition pretend being a disk II interface so as to support all the DOS 3.3 and self-booting software at the hardware level.
The heart of the circuit is an AVR microcontroller with enough internal RAM to buffer a sector
at a time read from a MMC/SD card. The card chosen over CF for a simple reason - very few pins.
And the speed is much faster than what Apple can possibly read anyway. Originally I though that AVR may be fast enough to directly interface to the Apple bus. Not so. Even running at 20 MHz it is not possible (or I don't see how) to respond within some 150 nS. I didn't want to add any wait states because the game software is time critical. So I have added a CPLD (Xilinx 9536XL) as an interface. It also serves as a voltage translator - memory card is 3.3 V.
The CPLD captures the 4 low addresses during an access to the card's i/o memory space and the data in case it was a write. In a read cycle it puts 8 bits of data to the bus. An SPI interface is used to exchange data between the CPLD registers and the AVR.
The MMC card is also using the SPI interface that AVR happens to support in hardware. A couple of pins select the type of operation: SPI exchange with MMC, same with the CPLD and one extra mode where data coming out from the MMC can be read directly into the CPLD's register. The idea is that one can write firmware that will directly pass data from MMC to Apple's bus via the CPLD. I didn't. My simple firmware reads a 512 byte sector from the MMC into a buffer inside the AVR first. The third chip on the board is an EPROM. No less than 27C256! That is one hell of an overkill given that just 512 bytes are needed, but they are cheaper and easier to find than smaller EPROMs
BetaPlenty of space left on the board in case I forgot something important.
The production version.
The soldermask doesn't make it work any better but sure looks good.
Theory of operation
The device has two modes: ProDOS and Nibble.
ProDOS modeThe only real difference for the card is that a different 256 bytes page is enabled in the EPROM. In ProDOS mode it is a ProDOS compatible driver that doesn't do very much: all the work is done by the AVR. One of the DOS 3.3 disk controller READ addresses (Q6H = $C08D,x) is used for sending commands to the AVR. For example to read a block one sends operation code and the block address (2 bytes). Wait for the data at the $C080,x address to have the MSB high. Then 512 bytes can be read from the "Q6L" ($C08C,x) address.
I suspect this is faster than the CF interfaces operates because the read loop is quite tight and all the data is being read from the same address.
Does it get much faster than this short of using DMA?
__next1: lda Q6L,x
sta (buflo),y ;write into the buffer
When the card is powered up it starts in ProDOS mode. The first block of the MMC card's first partition is loaded at $801 and given control. If an image of a ProDOS volume is written to the MMC, ProDOS boots.
Actual boot code/driver source
The real fun starts in nibble mode. Boot code identical to one found in a standard DISK II controller card is mapped into the Cx00-CxFF memory space. AVR interprets reads from the addresses responsible for disk operation. For example it notices attempts to position the head and adds a offset to the beginning of the image. The data on the MMC card is assumed to be a .nib image of whatever: exactly 232960 bytes.
In fact the card holds many such images at 232960 bytes intervals. A write to the AVR control address selects the offset.
The pseudodisk is the only storage device in the system on this picture.
The hardware works great. The firmware is very simple but seems to do the job. There is a huge
room to improve on it: the code takes a small fraction of memory even though it is written in "C".
I have one 32 MB MMC card with an image of a ProDOS volume. Everything I tried to start from it worked. I used HDRV.GDV - a 6 MB volume with tons of games I got from the 'net.
I also have another MMC. The first 232960 bytes are a ProDOS volume. And there is a BASIC program that runs after booting it. This program asks the user to select a nibble image. Then switches into nibble mode.
Of course the same could be done with a much more compact machine code. I'm sure it would fit
into the first sector. I still want to put the first nibble image after 232960 bytes from beginning for consistency. Submissions of new AVR firmware and boot code are most welcome. I will shortly put my version here - as soon as I finish testing it.
- Nibble mode is read-only. This is a limitation of the AVR firmware only. The hardware is designed for read-write.
- Not tested on a lot of nibble images.
- Not tested on IIGS. May not work at high speed.
In theory firmware can be written to take care of just about ANY disk protection method. In practice this is left as an exercise to the user.
A few people expressed interest in getting this board. So I made a short "production" run - meaning GREEN boards with a proper solder mask. 20 PCBs made. I will populate them as the orders arrive.
There is a lot of room for improvement in the firmware in two ways: much to be desired and a lot
of space left in the flash. The project is open source so I hope I'll get some help in this department. Frankly I enjoy designing new hardware much more than writing code for it.