> But, I do lament the split of development knowledge... > > sd2iec can be fitted to handle any block device by merely creating a new > block driver. A complete wholesale mod to send all commands to an > endpoint could also be implemented, though it would take a bit of > refactoring. I also thought sd2iec's IEEE488 support was similarly > factored into its own codebase. File access on a file basis instead of block device level would be the next "bit of refactoring". Furthermore, sd2iec uses X:FILENAME to access different partitions 'X' on a SD card just like the CMD hard disks used making the usage of dual drive code (very common in the CBM/PET world) very hard since it requires to hold disk images for different drives on different partitions. Unfortunately, I haven't been able to convince Ingo of the need for a "mount/assign" command to get rid of the current handling focusing only on partitions. Last but not least, it seems to me as if it is not that easy to add code to the sd2iec repository. There's a patch for the usage of a LCD display without the need of a second MCU made by somebody else that never went into the main code base as well as my support for D80/D82 disk images never did. > License issues excepted, it means all of the various fastloaders, GEOS > mods, and the REL file support already in sd2iec will need to be > re-implemented in your codebase. sd2iec's fastloader code assumes the AVR running at 8 MHz which isn't true for the XS-1541 so that code would have to get re-worked anyway and REL file support inside disk images simply does not exist. Nils Message was sent through the cbm-hackers mailing listReceived on 2013-06-11 11:00:04
Archive generated by hypermail 2.2.0.