Mike wrote: ↑Sat Dec 12, 2020 12:58 pm
Ingo's dedicated opinion is not a good basis to get things done,
Well, given that these things are passion projects, not financial items, I think it's as good a basis as any if one expects Ingo to do the work. The promise of open source was that lots of people would contribute to source code, but the reality is that most often only the original author contributes to the project, and if others contribute, they often contribute lightweight additions. So, in effect, the discussions focuses around Ingo. I did some heavier lifting in the codebase (REL support, CMD directory support), but my contributions were pretty light compared to the main codebase.
That's different from "no use (except one case)". It is not clear to me why you would not accept the TEST DEMO disk as independent example, but so be it,
My point is that it was designed to show how to use the function, not to provide intrinsic value to an app. It's the "example" code one sees with a new system.
The whole CBM DOS is ill-designed and ill-implemented from that point of view. Nonetheless the feature is there and it works.
Well, can't argue that, but the awfulness of most of the code can be spread (amortized) over many emu containers in the codebase.
I notified Ingo about the issue in early 2011, and put it into a feature request. At that time, Ingo reacted somewhat surprised that anyone would actually use CBM partitions, but at least I put in the request not just because. Even though he promised to take a look at it, nothing happened.
Well, I hate to bring personalities into the discussion, but Ingo seems aligned with a category of developers who tend to be pretty blunt. If he ultimately decided he did not want to implement the functionality, he probably would not have been diplomatic in responding (or respond at all). I can't defend that, you're not the only one who has experienced that.
Later correspondence regarding full REL file support in disk images, support for a VIC-20 native old-style drive-speeder (HYPRA-SYSTEM, to be precise) and most recently a bug report about a timing issue with KERNAL single byte writes were met with similar response.
Well, I can't help with the speeder code, but the other two I might be able to help with. I have another bug report about REL files in native mode that I need to fix, so I can look at adding REL files in d64 and D71 format. I think D81 uses super side sectors, so that will require learning more about them.
Lesson learned, here's my conclusion: I will not bother Ingo or you anymore with these things. Likewise you can't expect me to adapt the Bible Series programs for SD2IEC use.
Oh, I don't know if that's the lesson to take away. I at least am interest in REL file support, for example, though my expertise is limited on the other items. So, I think we should have some way to log the bugs, in case someone can address them. I'm merely wanting to ensure folks don't get overly frustrated trying to get these items fixed.
Right now, I am not at 100%, but I am hoping to get a copy of the sd2iec repo, since I have a 'V'alidate codebase that I think should be merged into the main codebase, and the REL fixes I intend to make. If I can get a copy of the complete repo, I intend to fork and place at github. If I do, then we can open these as bugs/issues, and see if folks want to take up the cause.
Jim