On 6/11/2013 12:10 AM, A. Fachat wrote: > Am 11. Juni 2013 05:39:46 schrieb Jim Brain >> > >> > http://www.github.com/fachat/XD2031 >> > >> I'm curious, as I thought sd2iec firmware supported a number of >> platforms already. What was the issue that prevented re-using that >> code? > > But 1) last time I looked there were many calls into IIRC led, sd card > and other subsystems in the iec loop, which made it hard to reuse. Now > our iec code is iec only, all other stuff is separated out and shared > between iec and IEEE488. As far as I can tell with the latest code, there are just a few calls to led functions in the main loop, but they are inline calls defined in config.h, and can be nulled out if desired. Also, the loop is contained entirely in iec.c for brevity, but could be changed to not do "while(1) and then all of those functions could be eliminated from iec.c. THere is a chunk of code in the mainloop as well for disk changes, but it could be factored out if needed. Ingo actually notes he put it there because it seemed a good a place as any. > > 2) it was under gpl2 only, while our code is gpl2 or later. You can > actually see the remnants of Ingo's code in those files of XD2031 that > are still gpl2 only. I can't argue that point. 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. 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. I realize my position will seem biased, but it's not that. Since your code is GPL as well, I'm free to use it, as any one is. Jim Message was sent through the cbm-hackers mailing listReceived on 2013-06-11 06:01:23
Archive generated by hypermail 2.2.0.