On 5/31/2011 1:41 AM, Baltissen, GJPAA (Ruud) wrote: > > > The advantages for you: > - you don't have to worry about supporting all kind of commands and file > formats (relative files !!!) There are indeed tunkey microcontroller projects that offer a 8042 IO, RS232, or SPI-based interface to the SD card, complete with a high level API and support for FAT and FAT32 filesystems. But, sd2iec already supports REL files (I wrote the support), and it supports all the commands that make sense for SD cards, including commands that are not in normal CBM DOS (like $=P and timestamping) As well, fixing bugs in sd2iec-based devices (with bootloader support, which nearly all the commercial offerings support) involves simply popping in an SD card with the new code. A hybrid approach that limits the functionality of the Atmel means more bugs will require a new DOS ROM for multiple drive types. > - only one program is needed for all drives. True, but then each drive must have a custom ROM to enable the functionality. With sd2iec, you just need the firmware. > And about communicating with the Atmel, what about using the register > set as used by IDE harddisks? One change: 256 bytes sectors instead of > 512 ones for the C= drives. Anything is possible, but I think it's too low level, and it forces all things to subscribe to an IDE-view of the universe. > About using it in other computers: with 512 bytes/sector I can use it to > replace the old MFM drives in my IBM-XT (clones) :) I think there are already solutions for this as well. Check the classic-computers cctech and cctalk archives. Jim Message was sent through the cbm-hackers mailing listReceived on 2011-06-01 03:00:12
Archive generated by hypermail 2.2.0.