Monday, June 14, 2010

CHED - Update

The serial output of the Apple's floppy disk drive produces a continuous bitstream where one bit is output every four microseconds. Generating this bitstream has been more difficult than I had expected. The difficulty comes from doing the hard drive reading, data conversion and output of the bitstream all at the same time using the existing resources. The output of the bitstream requires a fair chunk of the CPU time just by itself. I was unable to utilise the Atmega's USART as the start/stop bits can't be disabled so bit banging was the only other option available. Adding some extra processing power will be required.

Another shortfall is the amount of available memory. Presently there is only room for a few sectors to be buffered. By emulating a spinning disk, a given track's data is output again and again. This causes the hard drive to read the same sectors over and over again. Being able to buffer an entire track would save wear and tear on the hard drive. Extra memory will also allow me to write a better implementation of FAT.


Tiger said...

Hi Lukazi,

I like what you're doing with this project. I have a similar goal, I'd like to build an SD card reader for the disk port, also using an AVR controller. If possible, could you post some of the logic analyzer output of the port pins? There is not much documentation for the actual pin signals.

Thanks and good luck :)


Lukazi said...

Hi Tim,

Everything that I needed for the Disk II communications (not the smartport protocol) I managed to get from the following two books :-
Chapter 9 of "Understanding the Apple IIe" by Jim Sather and
Chapter 3 of "Beneath Apple DOS (Fifth Printing)" by Don Worth and Pieter Lechner

The pulse train code has turned out to be more difficult than I had expected. Basically the length of the pulse is 1 microsecond and the length between bits is 4 microseconds. Therefore each bit is output once every 64 clock cycles (on the 16MHz Atmega128). This uses a lot of cpu time. I need to rewrite my pulse train code in assembler and if I can't get it working fast enough then I may need to look at alternative solutions ie a faster microcontroller, extra microcontroller or shift register.

I'll try and post some logic analyzer captures soon. Send me an email on which signals you need in particular and I'll try and capture them for you.