I received my first Raspberry Pi in the mail today. It is a
Raspberry Pi Zero W. I am excited to really try it out. I have it running, but I need to get a USB keyboard and mouse hooked up to get everything installed.
The Raspberry Pi is pretty neat hardware that bridges the gap between a micro controller and a full desktop computer. I have done some micro controller development, but never got really engaged with it. Development on the Raspberry Pi looks a little more my speed. At $10 for the Raspberry Pi Zero W, it is significantly more powerful and cheaper than the Mega AVR Arduinos and the necessary add-on cards. Most of the cool stuff is already built in to the Pi!
So, my hope was to port a2usbdsk to Raspberry Pi, so that people never have to use 5.25" disks again. I love the nostalgia, but they are cumbersome to use and ADTpro transfers to and from the Apple II are fairly slow. Don't get me wrong, ADTpro is a wonderful piece of software that I have used and quite a bit myself. But if you don't want to actually use disks to use disk images on your Apple II, it seems like the wrong solution, and a piece that is missing in (and could easily supplement) other packages like Ivan Drucker's RASPPLE II.
To pull this off, I am going to attempt it in 2 steps:
- Port a2usbdsk to Raspberry Pi to run the FT232H adapter;
- Create a new program a2spidsk to run on the native SPI ports on the Raspberry Pi.
I am very concerned that the Raspberry Pi may not be able to analyze the incoming data fast enough from the USB adapter. There is quite a bit of latency between transmissions to the disk drive that I was barely able to overcome on my MacBook. This puts a long gap between sectors which the Apple II is pretty good about ignoring, but it will eventually give an I/O error.
I am also concerned that the SPI buffer for the bcm2708 in the Raspberry Pi is quite small (12-120 bytes) which could make it difficult to output the bytes fast enough and with the regularity needed by the Disk ][ interface card. Since the Disk ][ interface card doesn't really understand SPI, we need very regular SPI clock transitions and data to keep synced up with the card in order to match up the synchronous SPI bus to the asynchronous Disk ][ interface card connection.