Re: Code re-use

From: Jim Brain <>
Date: Tue, 11 Jun 2013 08:31:50 -0500
Message-ID: <>
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

       Message was sent through the cbm-hackers mailing list
Received on 2013-06-11 14:00:03

Archive generated by hypermail 2.2.0.