Mike wrote:You can allocate 32 sectors on a freshly formatted disk with the B-A command (say, 21 sectors on track 1 and the rest on track 2), and subsequently access them with the block-read (U1) and block-write (U2) commands. With a 1541 or 1571, this area doesn't show in the directory, and a Validate command will *free* those blocks, so you should explicitly discourage users from doing this (with, like, putting a "DO NOT VALIDATE!" dummy file near the top of the directory).
Of course, with those four *.d64s, the content of the 32 sectors doesn't "propagate" from one disk to the other three ones.
On the 1581, you can use a CBM file to allocate that sector range (tracks have 40 sectors there, so the sectors fit on track 1). You only need to prepare that once, again on a freshly formatted disk. That one also survives a Validate command.
Note though, in both cases reading/writing the entire swap space will take roughly 20 seconds on a 1541/1571 and maybe half the time with a 1581. To speed this up, and if the game is still supposed to run with SD2IEC, JiffyDOS or SJLOAD are about the only viable options for faster drive access.
Thank you. I've actually been reading up on block-write and block-read here:
https://wpguru.co.uk/2016/01/how-to-use ... odore-dos/
So it's pretty self-explanatory, and now I just need to figure out how to do it in ML
I've figured out how to write files to disk, but issuing disk commands is quite another thing.
I only intend to use swap space on side 3 of the 5 1/4" disk version of the game running in single drive mode. This is just to specifically avoid excessive disk swapping for users who are using a single 1540 or 1541 drive. It's not necessary to swap memory for SD2IEC, 1581 or dual disk drive users because the data that's needed can be easily accessed without having to swap disks.
Basically, side 3 of the disk contains all of the game's monsters graphics and data. So if the player is traveling about (side 1 is the outside world, side 2 is the dungeons) and a monster encounter occurs, the player needs to switch to side 3 to fight the monsters.
Since the combat modules and monster graphics data will overwrite the game world data in RAM at $A000, the player would be required to switch back to side 1 or side 2 if I didn't implement this swap space feature.
So, the solution that I envision will be like this:
1. Player encounters a group of monsters
2. If side 3 is not inside the disk drive, the player is asked to insert side 3.
3. If the game world data at $A000 has _not_ been written to swap space, then write it. (if the game world data that the player is currently exploring has already been written to disk, then why write to disk again?)
4. Load the combat modules and data at $A000
5. After the combat has been resolved, the game world data can be loaded from swap space into $A000 and the game can resume WITHOUT HAVING TO ASK THE PLAYER TO INSERT SIDE 1 or 2 because this data was stored in the swap space.
Why support floppy? Well, while I do recommend that people player the game on an SD card, I still want the game to remain "retro authentic" in the sense that if somebody took "Realms of Quest V" back to the year 1983 by way of a time machine and run it on a Commodore VIC-20 with a 32KB RAM cartridge and floppy disk drive, the game will work. That's how RPG games were played on 8-bit machines back in the day: you switched disks at different parts of the game. Pool of Radiance and Ultima V encompassed something like EIGHT disk sides.
, but rather the drive number, which normally is 0 and only in case of dual drives may also assume the value 1.
