Wolfenstein 3D (Original) Abort on Data Transfer

[JonAbbott]

I now get an SWI &103F10 not known error

Now fixed. I meant to go back and completely rewrite the CPU / Cache detection, but forgot.

I've not managed to produce the other errors you're seeing with the revised script - I've tested on 4MB ARM2 and 4MB ARM3 both with RISC OS 3.11. It does sound like there's not enough memory though - or its bordering on the point it cuts over to the 2MB version.

[Idge]

Amazing Thanks Jon.

So latest update is I tried running the game with boot floppy and the new script and got the Abort on Transfer message, but I then shift rebooted and put it in mode 13 and set the WIMP next slot to 2048k, and it then played fine. (This did not work before the revised script.)
I then tested a second time, doing the same thing to make sure it wasnt a one off and this worked again, so yes it does seem to be something memory related still.

I then just did a shift boot without the mode change or next change, and it still worked, so it now seems to be related to something in my boot.

I will have a play around with what is in my boot and see if I can tweak it to get it working.

So I think can probably say its now working as is your recording file you provided.

Thanks ever so much for perservering with this.

[JonAbbott]

I then just did a shift boot without the mode change or next change, and it still worked, so it now seems to be related to something in my boot.

If you can pin it down and it's something I can fix in the script, I'll alter it.

Things to check, off the top of my head:

• The size of the RMA and amount of free RMA after boot
• The WindowManager version
• The amount of free RAM available to the app (F12 / *BASIC will confirm this)

The Abort you're seeing is triggered after ADFFS / ZLib allocate RMA while loading the floppy image. *ADFReserveMemory pre-allocates memory for the ADFFS floppy buffer, so you've already ruled that out. ADFFS also ensures there's 64KB free in the RMA to try and avoid ZLib extending the RMA, at these points:

• When Boot floppy is used
• When *RMAFree is used
• When *RMASize is used

If Boot floppy works, but running !Wolf directly does not, it might be fixed by adding RMAFree 4 prior to GO 80CC in the script

[Idge]

Cheers Jon,
I will have a proper go at it at the weekend, but did quickly try the RMAFree 4 in the script, This actually gets the game to load without asking for the disk swap, however when you try and start a level, I get a lockup.

[Idge]

Hi Jon,
Did the tests, results below

Normal Boot (using Uniboot3.1) - Doesn't work

Basic: 651516 bytes free
Window Manager Version: 3.98
RMA Size: 256K
Free in Module Area: 245K

With ADFFS loaded and Disk 1 mounted for Wolf3D

Basic: 651516 bytes free
Window Manager Version: 3.98
RMA Size: 256K
Free in Module Area: 199K

Shift Boot - Works

Basic: 651516 bytes free
Window Manager version: 3.16
RMA Size: 256K
Free in Module Area: 131K

With ADFFS loaded and Disk 1 mounted for Wolf3D

Basic: 651516 bytes free
Window Manager version: 3.16
RMA Size: 256K
Free in Module Area: 82K

[JonAbbott]

Cheers Jon,
I will have a proper go at it at the weekend, but did quickly try the RMAFree 4 in the script, This actually gets the game to load without asking for the disk swap, however when you try and start a level, I get a lockup.

Try increasing it from 4; 256 for example.

[Idge]

I couldn't pin it down unfortunately this weekend.
I tried the RMAFree 256 with the same result, I also tried not loading Vprotect as well as trying the low mem option in Wolfenstein.

I did notice that in the Uniboot run file it has several AddtoRMA statements so maybe it is related to this.

Nothing other than a shift boot would get it to run without the abort error, however now I can't even get it to start a game even with shift boot!

Now even with a shift boot, I get the menu to load, but when I start a game and select the difficulty, I just get a lockup.

I am going to do a bit more testing on Arculator to see if I get the same results there

[JonAbbott]

Mirror your *Configure settings exactly in Arculator, perhaps it's a combination of memory settings that's triggering an edge case? Check the Modules match up as well.

The lockup after selecting the difficulty might be sound related, so also try turning it completely off in the options.

Does running !Wolf directly, then launching via the taskbar behave the same as "Boot floppy"?

[Idge]

Unfortunately, not able to test in Arculator so far. No matter what I do Disk 3 always shows a Broken Directory error. It works fine on the physical machine. I have tried copying into a zip file, a sparkfs file, reimaging the disk, nothing worked. Disk 1 and 2 work fine, so very strange.

I tried disabling all the sound and still get the lockup

Running !Wolf directly gives me the internal abort on data transfer error, whereas boot floppy loads the menu ok (if I shift boot) but I then get the lockup on level select.

Currently the only thing that works is if I install it.

UPDATE: The lockup after selecting the level seems to be something new in the script. I tested the installed version I had again, which had the old script in the run file and it worked fine. I replaced the !Run with the new obey file from the script and I got the same lockup.

[JonAbbott]

Unfortunately, not able to test in Arculator so far. No matter what I do Disk 3 always shows a Broken Directory error. It works fine on the physical machine. I have tried copying into a zip file, a sparkfs file, reimaging the disk, nothing worked. Disk 1 and 2 work fine, so very strange.

I can't reproduce this, if you're not using it already try the latest ADFFS beta.

If you're still seeing issues with disk 3, mount it and copy everything to RAM: - to confirm it can all be read.

That all said, I am aware of a random issue where ADFS reports that error when accessing a floppy. I've not managed to track down the cause, but suspect its not flushing its cache when the floppy changes and returns sectors from a previous floppy. You could try *Configure ADFSDirCache 0 / *Configure ADFSbuffers 0 to see if that makes a difference.

UPDATE: The lockup after selecting the level seems to be something new in the script. I tested the installed version I had again, which had the old script in the run file and it worked fine. I replaced the !Run with the new obey file from the script and I got the same lockup.

Fixed in the latest latest script, which is also included with the latest ADFFS beta. I've also removed the requirement to mount disc 1 when running from HD.