Johan Kotlinski

Yes, you should be able to do that following those instructions in the manual. ons 31 juli 2024 kl. 20:56 skrev Andy De George ***@***.***>: > Sorry, I missed the...

@ekipan thanks for the tip. however. i will leave that code unoptimized until later. in case my solution turns out to be wrong.

Another difficult decision: Allocate blocks once upfront, or just-in-time? I am toying with the idea to allowing addressing blocks 1-199, but that block sectors are only allocated on first write....

Another idea that kind of dodges all problems, but adds complexity and other problems in return: ``` \ maps the given 1541 drive for BLOCK usage. \ the drive is...

The 40x25=1000 bytes most importantly leaves space for eight sprite data pointers.

On more thought. Maybe "LOAD" is not that great, it is normally used for Block loading, so there is some risk of conflict or confusion. SuperForth64 uses "LOADRAM" and "SAVENAME...

I like LOAD-FILE/SAVE-FILE best, because this naming is similar to Forth Standard words (OPEN-FILE, CLOSE-FILE, ...) but it is unclear if it is worth a breaking change...

I think "binary data" is nonsense, you are right in that it reads whole .prg files. Maybe load-prg/save-prg is good.

Another gripe about `saveb`. The range is given as start address + end address. In Forth, it is nearly always start address + length.

Yet another confusing thing... loadb takes first filename, then data address. saveb takes first data address, then filename. It is set up for mistakes.