ADFFS 2.84 public beta

[JonAbbott]

It's caused by issues in the BCMVideo implementation of overlays. I've raised them and until they're resolved I'm not sure there's any more workarounds I can implement. I've got several already to cover most of the issues, this isn't one I can workaround though.

[Idge]

Hi Jon,
I have noticed an odd issue with imaging that has cropped up with the latest version.

If I try and image Heimdall disk 0 with the latest version (5th July 2024), it images ok, however if you try boot floppy or by running the game directly from !Heimdall it gives an error Internal error: address exception at &001601E4

I have tried using the recording file within ADFFS as well as a custom recording file with the same results. I have also tried a shift boot and I get the same error.

I am imaging it on an a3010.

If I use ADFFS 2.83 to image it, it images fine and also runs that image without issue from 2.84 Beta.

[JonAbbott]

If I try and image Heimdall disk 0 with the latest version (5th July 2024), it images ok, however if you try boot floppy or by running the game directly from !Heimdall it gives an error Internal error: address exception at &001601E4

Thanks for the report. The only change to the imager that isn't GUI related was:

Code: Select all

JFD imager now compresses sector data in track chunks to improve Wimp updates/responsiveness

Although I wouldn't expect that to cause any issues as it only changed the timing of the compression step.

I'll see if I can reproduce the issue. I have imaged a few games with 2.84 without issue, so it might be specific to that disc.

[JonAbbott]

If I try and image Heimdall disk 0 with the latest version (5th July 2024), it images ok, however if you try boot floppy or by running the game directly from !Heimdall it gives an error Internal error: address exception at &001601E4

Try the latest version in the OP.

The only file that's changed is !ADFFS.imaging.imageJFD3. The issue was caused by the compression being done in track chunks so I've recoded the compression loop from scratch.

NOTE TO SELF: Before formally releasing, drop imageJFD3 from ADFFS 2.83 into a copy of ADFFS 2.84 and confirm via binary compare that the output is the same across a random selection of JFD's.

[Idge]

Thanks Jon,
I can confirm that has fixed the issue.

Cheers

[Idge]

Hi Jon,
I am having an odd issue with Dune II. I have imaged my disks successfully using your recording files as well as my own.
Everything works fine, however when you go to quit the game, it asks for disk 8, which I select and it then asks for disk 4 which I swap to, but it then doesnt continue to exit the game and just sits there with the disk icon.
When I reboot and check the disk image, disk 4 is replaced with disk 8's image.
I have reimaged again and it did exactly the same thing. I also tried making it write protected when imaging it which made no difference.
I havent tried it with the latest 2.85 Beta as yet, which I can try, but thought I would post here in case its a known issue
I have got around the issue by locking the image file so it is protected, but it then overwrote disk 1 as well with disk 8's contents

This is on a physical A3010 with ZIDEFS running RISCOS 3.11

[JonAbbott]

when you go to quit the game, it asks for disk 8, which I select and it then asks for disk 4 which I swap to, but it then doesnt continue to exit the game and just sits there with the disk icon.
When I reboot and check the disk image, disk 4 is replaced with disk 8's image.
I have reimaged again and it did exactly the same thing. I also tried making it write protected when imaging it which made no difference.

From memory I think disc 8 is the save disc and is possibly created with a utility from another disk, or just needs to be blank? I think I may have imaged disk 1-7 as JFD and created disk 8 as ADF to avoid compressing when saved? The hard disc install is available here if you want to avoid floppies altogether.

The overwriting behaviour is odd as JFD images are only saved back if: It's dismounted, has been written too and the image doesn't have the write protected flag set.

ADF's behave slightly differently, they're always saved back when dismounted if written too.

Either way it doesn't explain what you're seeing as the save should occur before it does the disk swap, so thanks for the report, I'll check the code.