Not working with Arculator?

[IanJeffray]

I thought I was going mad... "I'm sure ADFFS used to work on RISC OS 3.1" ... but try as I might, every version just crashes (aborts in whatever the filesystem is that's containing the image file being loaded by ADFFS) when mounting an image.
...With Arculator

On a real honest (rusty) RISC OS 3.1 machine, all is well. Maybe I'm not going so mad after all.

So the question is ... are there known issues / reasons ADFFS doesn't work with Aculator? This smells somehow like it must be an Arculator issue to me, but I fear to suggest that to Sarah and I can't really see why this should be the case. Am I being stupid?

Advice appreciated... even if it's user error ... because this has had me boggling for a good 30mins today before I finally tried it on real hardware and found it wasn't "just a RISC OS 3.1 issue" - and it would be 'handy' to have ADFFS working on Arculator

[JonAbbott]

I can't say I've ever tested ADFFS under Arculator as the version I have has built in JFD support. I'm not sure if that ever made it into the public build.

I will investigate.

EDIT: I've tested with Arculator v2.0 and not had any issues. That would imply its possibly something in your !Boot? Try with a SHIFT-BOOT, so nothing is loaded when you test.

[IanJeffray]

EDIT: I've tested with Arculator v2.0 and not had any issues. That would imply its possibly something in your !Boot? Try with a SHIFT-BOOT, so nothing is loaded when you test.

I already did Same experience with no !Boot right through to a full Uniboot setup.

But I've found that this issue only happens with a 16MB selected in Arculator. With 8MB, it runs! Sadly I don't have more than 8MB real hardware machine to test with... will ask around!

[JonAbbott]

I've found that this issue only happens with a 16MB

That will be it. If you read the ADFFS pre-reqs it does state 16MB isn't supported, the max it will run on is 12MB.

The reason 16MB isn't support is because ADFFS back-ports OS_DynamicArea to RO3.1 and it needs an unallocated area in memory to place them.

[IanJeffray]

I've found that this issue only happens with a 16MB

That will be it. If you read the ADFFS pre-reqs it does state 16MB isn't supported, the max it will run on is 12MB.

Perhaps it could check and error, rather than just exploding?

[JonAbbott]

Perhaps it could check and error, rather than just exploding?

If only it were that easy, I never invested any time in the issue as there are next to no machines out there with 16mb of RAM. You're actually the first person to notice it to date outside of Steve and I.

Steve Harrison has actually developed a utility to dynamically reduce the size of physical memory, but has yet to release it. I was going to look at hooking that into ADFFS when appropriate.

[IanJeffray]

Perhaps it could check and error, rather than just exploding?

If only it were that easy, I never invested any time in the issue as there are next to no machines out there with 16mb of RAM. You're actually the first person to notice it to date outside of Steve and I.

I try and max-out every machine I own Just can't get hold of a 540/260 again. But it seemed 'reasonable' to have Arculator set to 16MB at least - possibly less unusual than 16MB in a real machine. Unfortunately it has no 12MB setting.

Anyhoo - mystery solved and I won't run !ADFFS on my "A540" Arculator config

[JonAbbott]

I've just looked at the code and in theory it should work on 16MB machines, the original thread is here, where I discussed the issue.

From testing however, it looks like the 2nd page of memory onwards disappears from the floppy buffer on 16MB machines. The error you're seeing is Clib or the filesystem attempting to write the floppy image into memory.

I'll see if I can track down the issue.

[JonAbbott]

Turns out it does return an error with 16MB or RAM and should refuse to load. Due to a bug further up the call chain however, the V flag is being cleared so ADFFS loads without reporting the error.

Having fixed that issue, I’ve gone on to look at how to get it loading on a 16MB machine. That’s a lot more work as it needs to take over OS memory management to cap AppSpace and lose 4MB of RAM somewhere.

There appears to be a bug/feature in RO3.1x which isn’t helping. If you allocate memory to any of the DA’s (RMA, Screen, Font, Sprites, System), the OS resets them when you exit the Wimp. It also appears to keep reducing the RMA if there’s any free space at the end of it.

I can’t allocate memory to any DA other than the RMA as all are locked at the time memory is allocated, so I think the only option is to increase RMA to a min of 2MB and prevent it being reduced by the OS. The more problematic issue is capping AppSpace, that’s going to need Page Zero hackery and/or changes to the Window Manager.

[JonAbbott]

Ian, do you want to give the attached a go. From the brief testing I've done, it works on a 16MB machine provided you don't quite out of Desktop. Quitting out of the Desktop is bad as the OS appears to internally modify all the DA's, without doing it via legal means

Whilst loaded, ADFFS will take 2MB of RAM for itself and restrict the RMA to a minimum of 2MB, to prevent AppSpace from ever overwriting the ADFFS DA area.