On 6/11/2013 5:15 AM, Nils Eilers wrote: >> 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. Unfortunate, since I have mount code here that Bo Zimmerman wrote for the sd2iec codebase, and I just have not gotten it split into enough chunks to submit. The focus here was mounting disk images on additional partition numbers, so one cold reference a disk image in the root of the partition, not as a subdir. But, such functionality would lend itself to your use case. As I recall, Ingo was not wild about partition support in general, but I added it to support dual drive, multi-partition IDE versions of the codebase. Now, it seems, partitions don't get used much. > > 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. I'd be interested in the patches. I don't have an issue creating a -extra version of the codebase. > >> 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. Cannot argue there. I just lament that the REL file in image support will need to get added in two codebases, for example. > > Nils > > > Message was sent through the cbm-hackers mailing list -- Jim Brain firstname.lastname@example.org www.jbrain.com Message was sent through the cbm-hackers mailing listReceived on 2013-06-11 14:00:03
Archive generated by hypermail 2.2.0.