Site hosted by Build your free website today!
Home | Design | Features | Compatibility | Ordering





1. Bluetooth

Originally I planned to find a Bluetooth module that I could directly use through a simple UART port, so it won't make this project too complicate. But it turned out to be that such module is not very easy to obtain, either the cheap ones but slow transmission rate (USD$25 with real transfer rate 1-2Kbytes/Second) or OK transmission rate but expensive (USD $60 with transmission rate around 10KBytes/Second). Besides, the availability of those Bluetooth modules are also questionable. So I decided to use a Bluetooth USB dongle which is readily available on many PC stores and they are cheap (USD$10-15) with very high transmission rate (real life test showed 50-70KBytes/Second if using very fast PCs).

Another cool thing will be that if Bluetooth can connect to any PC equipped with Bluetooth without any special software to connect to BlueFlash card, so you can just connect to your neighbor's PC through Bluetooth without asking your neighbor to install a special software first to make the connection, so no change needs to be made on the PC side, so your neighbor won't worry you mess up his PC with some strange software, hey, how fantastic!!

Furthermore, almost all the commercial available Bluetooth modules talk to PC through virtual COM port. This is not exactly what I want, I need file transfer not a virtual com port, so I tried to find a solution for that. The first thought was to find an open source Bluetooth protocol stack and just use it without understanding it. I did find some, but they are either not complete, or they are all written for some OS (especially Linux) not for embedded system. I tried to read the code and hoped that I could modify it for embedded microcontroller, but those codes are really difficult to read without any knowledge on Bluetooth and the targeted OS. After struggling for some time, I finally decided to write my own protocol firmware, so I started reading Bluetooth specification and started writing the firmware code. It took me about two years to do so, and the most difficult part was, there are many vague places in the specification, so I have to examine off-shelf bluetooth dongles to see how they are implemented, that took me a lot of time, very tiresome......

The complexity of this comes from the fact that 5 protocol layers are needed in order to transfer even one bit of data. Each one of them took times to understand , to write and to test, not really a hobbyist's project, to be honest!.

You might be wondering why Bluetooth was chosen over Wi-Fi. The answer is mostly because the information on Wi-Fi card is really scarce. There is no common standard on how to interface the Wi-Fi card and you need to write different driver for different card even if you can get the information for the card. While Bluetooth has specification on the interface so you can virtually go to any store to get any Bluetooth USB dongle, plug it into BlueFlash card and it will work (at least on the hardware level). Besides, Wi-Fi card consumes lots of power, could close to 500mA, and Apple ][ slot can supply 500mA at most, so you need a power adaptor connect to the Wi-Fi card, so you get rid of one cable but introduce another one along with a bulky power adaptor, well, not a neat solution to me!


2. USB Host controller

Unlike interfacing a BT module with UART port, to connect to Bluetooth USB dongle introducing another level of complexity. A USB host is needed and firmware is also necessary to drive the USB dongle. USB itself is a big topic, fortunately I managed to find an off-shelf 8051 USB board with USB driver firmware plus USB mass storage+FAT system firmware, so the USB part of efforts was reduced a lot.

Another benefit from this is that now the Apple ][ has a USB host port!! You can connect any USB device to it with appropriate firmware, say how about a USB mouse for Apple ][ as next project....... (somebody volunteer to do that?!).

This photo shows the wire-wrapping prototype of the dual USB host ports.



3. Disk Image Archive and File System

Originally I was planning to use USB flash pendrive as the file archive because it doesn't need card reader to read it on PC. Even though I had the FAT firmware code already, I still had to rewrite the FAT firmware since the one came with the development board was slow.

Unfortunately, after finished the USB pendrive firmware writing and testing, I decided to abandon it. The reasons were first, it increases the cost of this card because another USB host controller IC is needed (one already used for Bluetooth USB dongle). Second, the read/write speed was not as fast as I expected. Third, compatibility will be a big issue since there are much much more USB pendrives out there and I won't be able to test each one of them. So I switched to CF hoping it will be faster and asking for much less testing efforts! However, to make CF really work also took some time!



4. Microcontroller

As said before, I obtained a 8051 development board with USB host port, so I did all firmware writing on that. About a year ago, when most of the firmware codes were ready for testing the transmission speed, I found the it was mediocre. It seems 8051 was not a good choice to run such a massive chunk of firmware, so I need to find another higher speed microcontroller. A logical alternative was ARM, so I bought an ARM-7 board and ported all my firmware codes to it. Since I did not have any prior experience on ARM, it took me couple of months to read the document and fine tuned the parameters of the ARM controller. Right now ARM runs at arounf 57 MHz and it generates a satisfying result.


The entire firmware code takes about 90K bytes (after optimization). Bluetooth takes about 50K bytes, and 40Kbytes for others.


5. Disk Controller (Woz Sequencer)

Finally comes the most interesting part, the Disk ][ clone. (honestly, other parts are good engineering practice but very boring dirty-handed jobs). I want the disk controller to be exactly the same (should say almost the same) as the original one. That means the original Woz sequencer needs to be studied thoroughly. Without any prior knowledge on how Disk ][ controller card works, I picked up the great book - "Understanding the Apple II" and study every word about the disk controller, also I had to study the monitor firmware and RWTS code to clear up any confusion. At first it did not seem to be too difficult, but it turned out to be not the case, ito make it work needs lots of understanding, thinking and experimenting. The Woz sequencer is indeed a masterpiece, very clever and a very complex design even looking at it in 2007. It is amazing how it could be done in the 80s. I think the source of complexity comes from the hardware-firmware co-working scheme. It needs understand both hardware and firmware. And during my design, I even implemented a 6502 in verilog code and typed in the disk controlling piece of firmware in order to test my disk controller clone!

(BTW, the 6502 clone I made is exactly cycle-matched to the original 6502 and 65c02, otherwise it won't work for floppy disk since floppy disk needs a very precise timing loop to perform disk read/write)


The entire disk controller was implemented with Verilog and runs on a Xilinx XC95144XL CPLD, ARM controller also takes some part of the disk controlling mechanism. The utilization of CPLD is almost 90% which is considered full!



Another good feature is that I put an SRAM on the card for running two disk images (Drive A and Drive B) at the same time just like the old Disk ][. I thought about using CF card as the Drives and reads off data and write data to it directly at run time. But this introduces two issues, first, flash memory has write number limitation (usually 10000 times), this means you could damage your CF card in a short time if you play with your beloved Apple ][ with BlueFlash heavily! Second, you must have CF card plugged all the time to work. But with BlueFlash, you can just directly transfer (wirelessly of course) disk images from PC to BlueFlash's SRAM and strightly run it there without CF card. How neat!!


6. PCB

Originally I planned on using a double-sided PCB for this card to save cost, but it turned out to be a 4-layer PCB is really needed since ARM runs at near 60 MHz and USB also needs very clean signal, which means a large ground plane is necessary to keep the signal clean. That makes the PCB cost high, also there are several large pin ICs, soldering also cost more. The parts cost is no doubt also high for buying a small quantity. The end result is that this card is expensive and effort swallowing to make!