Bible Series I and II reviewed - and possible problem

[orion70]

Hi all, here's a short note for a possible technical issue. Alessandro C. was kind enough to review Bible Series I: New Testament and Bible Series II: Pentateuch in two posts of his excellent blog.

Now, he wrote in these articles - and to me via personal mail - noting that, while the *.d81 works like a charm in VICE (true drive emulation, D81 drive, full blocks RAM), the very same configuration presents with a glitch on a real machine. In Alessandro's own words:

Basically everything starts up, the graphics are displayed, the menus, even the summary verses of the stories are OK...
but when you try to open a book, probably due to the "weight" of it, you return to the main menu ...

Currently I don't have a VIC sitting on my desk, so could someone please verify? Does anyone (notably Mike) remember if this issue was encountered back then, and if so, how it was solved? The D81 files are downloadable HERE and HERE

TIA

[Mike]

If I assume, that Alessandro actually used a 1581 (judging from the photos in the blog), exactly how did he transfer the *.d81 files to disk?

1. The chapter texts are contained in the CBM partitions, therefore a full sector-based copy is necessary. A file-based copy won't work.

2. On a sidenote, both installations of the Bible Series are known to not work on SD2IEC drives, because these lack support for aforementioned CBM partitions. I asked the maintainer of the sd2iec firmware, Ingo Korb, about this as early as 2011, but he never got to implement this.

Point 2 being noted in case Alessandro had tried to run the applications on a SD2IEC, but for the moment I assume point 1 with a 1581.

[orion70]

Excellent Mike, thanks also for the private call . In the meanwhile, I realized three things:

1. Alessandro C. does not have a real 1581, only two "newer" devices i.e. one SD2IEC and one Final Expansion 3, both unsuitable to read the Bible series correctly. He put pictures of the 1581 in the post to signify it'd work only with a real drive. So your kind offer to help transferring data to real 1581 diskettes must be declined.

2. Nobody addressed this problem with SD2IEC and direct access to CBM partitions before, which is quite surprising indeed! Ingo should really listen for our cry to update such an old firmware. I don't know if someone here could help him with that.

3. Alessandro also told me he subscribed to Denial long ago with the user name "alex.kirk", but I can't find him in the list of members - maybe I don't have the permission to see the older ones. Can someone more "powerful" than me check if his account can be resuscitated (the verb is apt, given the matter of this thread )?

[Mike]

1. Alessandro C. does not have a real 1581, only two "newer" devices i.e. one SD2IEC and one Final Expansion 3, both unsuitable to read the Bible series correctly. He put pictures of the 1581 in the post to signify it'd work only with a real drive. So your kind offer to help transferring data to real 1581 diskettes must be declined.

... at least in the sense that under these circumstances I can't be of more help, yes.

If anyone else needs assistance for transferring *.d81 files to 3 1/2" disks for the 1581, and both a SD2IEC and the 1581 are available, I can whip up a transfer program in a spare hour. I would work much akin to d64trans.

2. Nobody addressed this problem with SD2IEC and direct access to CBM partitions before, which is quite surprising indeed! Ingo should really listen for our cry to update such an old firmware. I don't know if someone here could help him with that.

I do not think Ingo needs any assistance here. Ingo has an account here in Denial, I sent him a PM to direct him to here.

3. Alessandro also told me he subscribed to Denial long ago with the user name "alex.kirk", but I can't find him in the list of members - maybe I don't have the permission to see the older ones. Can someone more "powerful" than me check if his account can be resuscitated (the verb is apt, given the matter of this thread )?

Would be the case for Jeff-20 or joshuadenmark.

[joshuadenmark]

I only find alex.kirk (inactive user 2019)

[orion70]

Yep it's him! He just cannot login, it prompts "please contact an administrator". Can you please just reset his password and let him login to set up a new one? TIA

[joshuadenmark]

Activated account, please try now.

[brain]

I think it would be best to modify the implementation to not use 1581 sub-partitions, quite honestly. sub partition support in sd2iec requires a ton of code to make it work (one has to implement formatting inside an image, and the code for sub-partitions cannot be shared with any other drive type), meaning some devices at the edge of their code size would then be unable to run this new firmware, not the mention the bugs that might crop in with this addition. In all the years, this is probably the only app known not to run on the device, and I just don't see Ingo (or anyone) taking up the project to add it.

From a design standpoint, most folks who have seen sub partition support in the 1581 absolutely abhor it, as it is ill designed and ill-implemented.

Jim

[Mike]

Jim,

I think it would be best to modify the implementation to not use 1581 sub-partitions, quite honestly. sub partition support in sd2iec requires a ton of code to make it work (one has to implement formatting inside an image, and the code for sub-partitions cannot be shared with any other drive type), meaning some devices at the edge of their code size would then be unable to run this new firmware, not the mention the bugs that might crop in with this addition. In all the years, this is probably the only app known not to run on the device, and I just don't see Ingo (or anyone) taking up the project to add it.

From a design standpoint, most folks who have seen sub partition support in the 1581 absolutely abhor it, as it is ill designed and ill-implemented.

Please don't come up with straw man arguments. I am surely not the only one who has ever used CBM partitions, even the 1581 TEST DEMO disk demonstrates their use! I also used it on more than those two occasions mentioned here: at those times I transferred four 5 1/4 inch disk sides of a game compilation onto one 3 1/2 inch disk - with 4 CBM partitions -, and added a menu.

That being said, I am not going to modify the implementation of the Bible Series programs to account for what I consider a serious shortcoming in the feature set of the sd2iec firmware. If the goal of the SD2IEC device was to implement a mass storage solution at CBM DOS level compatibility, after all those years, it is still incomplete.

Greetings,

Michael

[brain]

Jim,

I think it would be best to modify the implementation to not use 1581 sub-partitions, quite honestly. sub partition support in sd2iec requires a ton of code to make it work (one has to implement formatting inside an image, and the code for sub-partitions cannot be shared with any other drive type), meaning some devices at the edge of their code size would then be unable to run this new firmware, not the mention the bugs that might crop in with this addition. In all the years, this is probably the only app known not to run on the device, and I just don't see Ingo (or anyone) taking up the project to add it.

From a design standpoint, most folks who have seen sub partition support in the 1581 absolutely abhor it, as it is ill designed and ill-implemented.

Please don't come up with straw man arguments. I am surely not the only one who has ever used CBM partitions, even the 1581 TEST DEMO disk demonstrates their use! I also used it on more than those two occasions mentioned here: at those times I transferred four 5 1/4 inch disk sides of a game compilation onto one 3 1/2 inch disk - with 4 CBM partitions -, and added a menu.

That being said, I am not going to modify the implementation of the Bible Series programs to account for what I consider a serious shortcoming in the feature set of the sd2iec firmware. If the goal of the SD2IEC device was to implement a mass storage solution at CBM DOS level compatibility, after all those years, it is still incomplete.

Greetings,

Michael

Huh?

I don't think you're using "Straw Man Fallacy/Argument" correctly here. I'm not taking another person's point and distorting it.

I'm stating facts:

• Adding sub partition code to the 1581 emulation layer is a large task
• Part of that addition is formatting code, which I do not believe exists in the codebase either
• No other drive emu layer uses sub partitions

And expressing my opinions, and those folks who have conversed with me on it:

• Ingo hates the sub partition functionality
• It sees extremely limited use. I don't count the test demo diskette as a use case, but I am sure there are a handful of apps that require the functionality. Still, it's important to note that this is the only app in 16 years of sd2iec development I have heard not working for this reason. That implies there's not much use of this construct in the wild.
• I believe it to be ill designed and ill implemented in the DOS.

The goal of the sd2iec project was to enable DOS-level compatibility with SD cards and the FAT file system, and enable enough of various emulation formats to support their use, prioritized in order of 1541, 1571, DNP, 1581, in roughly that order. Many DOS commands and constructs not in significant use were excluded from the emulation functionality. This use case is not unlike some others in that not everything runs on sd2iec, so those games/utilities must be copied back to real media for correct operation.

I'm trying to bring a realistic light to the discussion. Ingo is not going to add sub partition support to the codebase on his own, because it is not in heavy enough use. And, he is not a fan of it. But, there are a number of options:

* Rewrite the app to not require it (you've noted you're not willing to do that)
* Copy to actual media to use the app (always possible, but less optimal)
* Hire someone to add this functionality to the codebase, via a bounty or something (it was done for the GEOS support, so there is precedent)
* Switch to another emulation solution, (though, I'm not sure if UII+ or Pi1541 supports D81 images...)
* Run the app in emulation on a PC, via VICE.

I proposed the rewrite since it might allow the app to run outside an image format as well. But, the author of an app ultimately has final say on what gets done.

Jim

[Mike]

I'll comment on the last of your points first:

I proposed the rewrite since it might allow the app to run outside an image format as well. But, the author of an app ultimately has final say on what gets done.

You and Ingo reserve that right for the sd2iec firmware as well as Alessandro and I reserve it for the Bible Series. I'll come to that again at the end of my post.

I don't think you're using "Straw Man Fallacy/Argument" correctly here. I'm not taking another person's point and distorting it.

You were somewhat misrepresenting *my* position when you made me the apparent only user of CBM partitions, by implying "other people" abhorred that feature right away.

I'm stating facts:

• Adding sub partition code to the 1581 emulation layer is a large task
• Part of that addition is formatting code, which I do not believe exists in the codebase either
• No other drive emu layer uses sub partitions

I have no other say than to concur with you on those points. At no point I thought it would be an easy task to implement the support.

And expressing my opinions, and those folks who have conversed with me on it:

• Ingo hates the sub partition functionality
• It sees extremely limited use. I don't count the test demo diskette as a use case, but I am sure there are a handful of apps that require the functionality. Still, it's important to note that this is the only app in 16 years of sd2iec development I have heard not working for this reason. That implies there's not much use of this construct in the wild.
• I believe it to be ill designed and ill implemented in the DOS.

In that order:

• Ingo's dedicated opinion is not a good basis to get things done,
• 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,
• The whole CBM DOS is ill-designed and ill-implemented from that point of view. Nonetheless the feature is there and it works.

The goal of the sd2iec project was to enable DOS-level compatibility with SD cards and the FAT file system, and enable enough of various emulation formats to support their use, prioritized in order of 1541, 1571, DNP, 1581, in roughly that order. Many DOS commands and constructs not in significant use were excluded from the emulation functionality. This use case is not unlike some others in that not everything runs on sd2iec, so those games/utilities must be copied back to real media for correct operation.

... and we do have just another case in point here, yes.

I'm trying to bring a realistic light to the discussion. Ingo is not going to add sub partition support to the codebase on his own, because it is not in heavy enough use. And, he is not a fan of it. But, there are a number of options:

* Rewrite the app to not require it (you've noted you're not willing to do that)
* Copy to actual media to use the app (always possible, but less optimal)

That's the main option for real hardware. The two installations of the Bible Series were written before SD2IEC devices got into more widespread use, so I expected the *.d81 files to be written back to actual 3 1/2 inch disks anyhow. Alessandro and I chose this medium, so the body of selected text would fit on one disk.

* Hire someone to add this functionality to the codebase, via a bounty or something (it was done for the GEOS support, so there is precedent)

O.K.

* Switch to another emulation solution, (though, I'm not sure if UII+ or Pi1541 supports D81 images...)

I've read something about D81 support in Pi1541, so point in investigating further. Not sure about Ultimate-II(+), but then that cartridge would be overpowered for use with a VIC-20 anyhow.

* Run the app in emulation on a PC, via VICE.

That's what I resort to at the moment.

...

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. 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.

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.

Michael

[brain]

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

[Mike]

Following up a PM exchange with orion70 ...

If anyone else needs assistance for transferring *.d81 files to 3 1/2" disks for the 1581, and both a SD2IEC and the 1581 are available, I can whip up a transfer program in a spare hour. [...]

... here's d81trans (download). Assuming the SD2IEC drive is device 8, and the 1581 drive is device 9, the user shall proceed as follows:

• copy "d81trans.prg", "bible3.d81" and "pentateuch.d81" into the root directory of a SD card,
• on the VIC-20, check with LOAD"$",8 and LIST, that all three file names appear with uppercase letters and with PRG file type (that one to the left, outside quotes!),
• format the 3 1/2" disk in drive 9 with OPEN15,9,15,"N0:NAME,ID":CLOSE15 and finally
• start d81trans with LOAD"D81TRANS.PRG",8 and RUN.

In the prompts, enter:

Code: Select all

SRC DEV.? 8
FILE? BIBLE3.D81 (or PENTATEUCH.D81 for the second disk)
DST DEV.? 9
FILE? # (<- given as default prompt)

User gets a display of 80 tracks being copied with a progress bar for 40 sectors/track. When "READY." appears and the drive LED goes off, the disk image has been written.

Please check beforehand, that SD2IEC and 1581(-type drive) actually work when both are connected to the VIC-20 and are switched on - I am noting this because some cheap SD2IEC devices are missing necessary bus amplifiers and only work on their own on the IEC bus!

[orion70]

Thanks Mike, as always . This further adaptation of Mike's transfer program comes from a request made by an Italian forum member. Thanks to him, I became aware of the existence of this modern version of the 1581 disk drive, made available as a kit by Francesco Pontecorvo. Googled it, but didn't come up with a link.
Armando?

[armypavarmy]

Thanks Mike for the program." D81transfer"
It works well but it's very slow.
Maybe if it was in LM it would be faster?.
Do you know if it can also work with the C64?.
Francesco Pontecorvo supplying the new Kit is on Ebay or can be contacted on Facebook.
Greetings Armando