ADFFS 2.86 public beta

[JonAbbott]

Zelanites (Play It Again Sam 3) is an ADF, so there is no option to Auto flush when imaging.

Thanks for confirming, I'll check both games. Zelanites could also be an issue with writing ADF back - so I'll check that as well.

Zelanites isn't flushing because the game disables interrupts. It will probably on a RiscPC/Pi etc (I've not checked) as the code is patched, but I've yet to roll the patching back to RISC OS 3.1x

Turns out it's not due to the game disabling interrupts, it only saves the highscores when you exit via ESC at the main screen. The game however immediately reboots the machine, so the buffered save never occurs.

I've modified the script for both the PIAS version and the original to patch the game back to RO3. It now uses legal calls to check the keyboard and will exit back to the desktop. If you grab the latest obey.zip and use "Boot floppy" it should flush back to the JFD shortly after exiting via ESC.

As your copy is an ADF, you'll either need to manually launch it via *ADFBootFloppy F1048701 or image it as a JFD.

[wmd]

I knew about the Esc to save scores thing on the PIAS version. However, I had no idea that is how it was supposed to work. I used to own the original Micro Power release and I don't remember having to press Esc to save scores. It's possible I am misremembering though as I must have sold it on over 10 years ago now. The PIAS version can be copied to hard drive and run from there if you ADFMount the ADF in the !Run file. Doing it this way, when you press Esc the scores are saved to the hard drive rather than the ADF.

[JonAbbott]

I knew about the Esc to save scores thing on the PIAS version. However, I had no idea that is how it was supposed to work. I used to own the original Micro Power release and I don't remember having to press Esc to save scores.

It's the same, if you look at the two script I'm performing exactly the same patching, just at different addresses.

The PIAS version can be copied to hard drive and run from there if you ADFMount the ADF in the !Run file. Doing it this way, when you press Esc the scores are saved to the hard drive rather than the ADF.

Correct, the PIAS version uses Obey$Dir and RealPath$Dir to load/save the scores so can be copied to HD and the boot script should work for both floppy and HD installs. The disc protection is stripped so you probably don't even need to mount the floppy image, just copy !Superior across...I'll test and add HD install instructions to the scripts.

The original release is hardcoded for ADFS::0.$.!Zelanites although I could patch it to run from HD as well.

EDIT: I've just noticed SFS (SquishFS) in the PIAS version performs a disc protection check during init and hangs the machine if it fails. I'll probably patch it to avoid this.

[JonAbbott]

Updated build in the OP which fixes two fatal bugs I've spotted whilst testing.

[wmd]

Regarding Zelanites - a patch to have the game auto-save the scores after name entry would be nice, rather than having them save after an Esc press. I'm not even sure if the Esc press thing is mentioned in the instructions, it's very unintuitive.

[JonAbbott]

Regarding Zelanites - a patch to have the game auto-save the scores after name entry would be nice, rather than having them save after an Esc press. I'm not even sure if the Esc press thing is mentioned in the instructions, it's very unintuitive.

I'm well ahead of you, just ran out of time to test prior to uploading this morning. I've already modified both versions to save the highscore table after you've entered your score, which will be in the next update.

[wmd]

That's great, thanks for adding it.

[JonAbbott]

I've spotted an issue with the JFD imager - it might fail to write the tail of the image to the JFD, which isn't obvious unless you byte compare the disc contents. Avoid using it until the next update.

The bug was introduced with the 21st Feb build.

[wmd]

Is it only when flushing that bug occurs? Is it still safe to create new JFD images with?

[JonAbbott]

I've spotted an issue with the JFD imager - it might fail to write the tail of the image to the JFD, which isn't obvious unless you byte compare the disc contents. Avoid using it until the next update.

Updated build in the OP which resolves this issue.

Is it only when flushing that bug occurs? Is it still safe to create new JFD images with?

Flushing wasn't affected, the problem was in the JFD imager.