Originally Posted by JimDrew
Thanks for the link! Looks like he used discrete logic, and from his description it is a block-level device. This means that the parallel port has to setup the card and also transfer the data to/from it. My plan was to use a high speed PIC24 to handle the SD card via its DMA, and use the parallel port really for just moving data to/from the on-board buffer. After thinking about the floppy port a bit more, that idea is completely out because you have to emulate a disk drive and although I can certainly do that (and will be with SuperCard Pro, much like the HxC does) the speed would be dramatically lower than I was thinking because you would need to use MFM encoding/decoding because you can't write all values (0-255) as MFM.
I wrote empscsi.device for the EMPLANT board, so I suppose I could make the device driver support all of the same commands and then it could be used with HDToolbox. The PIC24 would query the card and determine the geometry. However, this is not going to solve the problem I have been talking about! It would just get you a nifty little SD card hard drive, not something that you could use to transfer files to a PC formatted SD card, which is what we are after here. We want something that we can copy Amiga files to and then pull the card and put it in a PC and read those files on it.
It would need a transfer program that would let you pull up a file requestor and select a bunch of files and then copy those files to the SD card. I would like to support both directions so you could move files back to the Amiga as well. I guess I could make the driver so you could mount it, but that would only be handy if you had a couple of real Amigas you wanted to share data with.
It's a bit of hardware to make it all work, so it would probably be in the $50 range retail, depending on the quantity. That's cheaper the C64 SD2IEC type devices that do the same basic thing.
Hi JimDrew (and all the other people here...)
You're right, my device is based on standard TTL logic, just a simple SPI UART, and yes, it's a block level device (512 byte/sector).
The driver "only" has to handle all the sector (block) requests and translate them to the SD card.
It's not trivial, but quite simple.
The main bottleneck here is the low speed of the parallel port, and the fact you need to send a byte (0xff) to get another byte (this is how SPI bus works), so you need to write a byte, change the I/O port to input mode, read a byte and put back the I/O into output mode (to be ready for the next byte).
If you let the PIC microcontroller (I would use an Atmel Atmega...) to control all the SPI part, I'm sure you can use some sort of SCSI packet commands, speeding up the thing a little bit more.
Something like this: send a request command packet, wait for answer and start reading bytes one by one...
I suggest you to use SCSI-like packets, so you can pass them to upper layers of the driver with minimal changes, and providing Direct-SCSI from the start (I have to implement Direct-SCSI in software right into my driver).
So, the more you put into the microcontroller, the easier to write the Amiga OS driver.
By the way, my device supports FAT through fat95 filesystem driver, and I can use it as a transfer method between Amiga & PC.
In fact, it supports any filesystem you want if it's based on 512bytes sectors (or multiples of it), just like any other drive.