For the record, Even though an Atmel AVR probably really isnt suited for this task, I do have libraries that turn an AVR into an IDE controller, So you can hook CF or CDROM/HDDs directly to the atmel via IDE cable and talk to it. The fastest 8-bit AVR thats around i think is 20mhz. Most I/O instructions take 2 clocks. all internal instructions are single clock, few are 2. So any operation on the I/O ports of the AVR take 2 machine cycles. So the timing constraints would have to be within that window.
I played with this long ago and it actually worked ok, was able to read/write files directly on the HDD, via the AVR and issuing commands to the AVR from hyperterm, listing the directory structure, etc. (also had a FAT library loaded on the AVR as well). People made HDD based MP3 players back in the day using the same libraries, with the arduino around that probably has evolved, I dont know. But I dont use C or arduino anyway.
But the trick from that point is addressing the AVR on the bus of course, but then having a driver.
Thought ponder:
If I were to build hardware, I would find an empty address space in map it, Basically i would map a few bytes for control and signal commands for the peripheral MCU. Then the 512bytes that follow that would be the databuffer for reads/writes.
That would be all the address decoder would have to handle in that regard. So if i perform a write to the control/command bytes, it tells the AVR to write to what LBA location, or read from what LBA location. etc.. Then the following bytes would be your 24bit/32bit LBA addy, then the sector data.
Of course you would have to provision a fetch for max LBA Size or CMS which ever way you chose, so the driver would know the drive's capacity. Fetching Sector 0 from after that would tell the system the partitioning scheme, etc.. but you could just patch around the SCSI manager maybe? feed the sector data where the SCSI data would normally be so the MAC could boot from the drive, or handle raw drives instead of dealing with just image files.
I think you would need polling too, so the driver would know when the instruction to the AVR has completed, or data is available, etc... So toss a vector in the VBI. But first I want to make some free time and get the serial hardware done first to make sure it works. Then deal with this project.
Something to throw out there and let simmer for now I guess. But I am almost finished with this major R&D project for a display company, then ill get free time again on the weekends to work on this stuff. Its been killin me, projects backed up and no time :-(
I played with this long ago and it actually worked ok, was able to read/write files directly on the HDD, via the AVR and issuing commands to the AVR from hyperterm, listing the directory structure, etc. (also had a FAT library loaded on the AVR as well). People made HDD based MP3 players back in the day using the same libraries, with the arduino around that probably has evolved, I dont know. But I dont use C or arduino anyway.
But the trick from that point is addressing the AVR on the bus of course, but then having a driver.
Thought ponder:
If I were to build hardware, I would find an empty address space in map it, Basically i would map a few bytes for control and signal commands for the peripheral MCU. Then the 512bytes that follow that would be the databuffer for reads/writes.
That would be all the address decoder would have to handle in that regard. So if i perform a write to the control/command bytes, it tells the AVR to write to what LBA location, or read from what LBA location. etc.. Then the following bytes would be your 24bit/32bit LBA addy, then the sector data.
Of course you would have to provision a fetch for max LBA Size or CMS which ever way you chose, so the driver would know the drive's capacity. Fetching Sector 0 from after that would tell the system the partitioning scheme, etc.. but you could just patch around the SCSI manager maybe? feed the sector data where the SCSI data would normally be so the MAC could boot from the drive, or handle raw drives instead of dealing with just image files.
I think you would need polling too, so the driver would know when the instruction to the AVR has completed, or data is available, etc... So toss a vector in the VBI. But first I want to make some free time and get the serial hardware done first to make sure it works. Then deal with this project.
Something to throw out there and let simmer for now I guess. But I am almost finished with this major R&D project for a display company, then ill get free time again on the weekends to work on this stuff. Its been killin me, projects backed up and no time :-(