26bit Module support

[Vanfanel]

-Inferno hangs here after I press 1 to start game.
-Bug Hunter In Space only shows an starfield. No actual game layer to see.
-Tower Of Babel says "end of file".

[JonAbbott]

Inferno hangs here after I press 1 to start game.

Wimp support may have broken it, it's broken a few games for no apparent reason. Its looking like it may be a compiler issue, but I've not managed to track down the root cause yet.

Will we see "The Dungeon" supported soon?

Unlikely as the protection doesn't play well on RO5, the game essentially takes over all filesystem vectors and decodes all reads. Any read to a file other than one it's expecting, or any * command causes the protection to lock the machine.

[JonAbbott]

Unlikely as the protection doesn't play well on RO5, the game essentially takes over all filesystem vectors and decodes all reads. Any read to a file other than one it's expecting, or any * command causes the protection to lock the machine.

I had a look at the protection this morning to see just how bad the situation is, its bad:

1. The protection Module 'janitor' claims the following vectors: FileV, ArgsV, BPutV, GBPBV, FindV and CLIV
2. It has a bug in the code, in that it should also claim ByteV, but ends up claiming ArgsV twice instead breaking ArgsV in the process
3. The FileV code makes assumptions about the way RISCOS' own FileV handler exits and tries to get it to exit back to itself, by stacking PC

To get this to work will require a complete rewrite of the Vector handler in ADFFS. It would need to examine the stack when the Hypervised vector call returns and determine if PC was stacked, it will then have to allow the vector to proceed, taking over its return and instead Hypervise a return back to the stacked address.

It's a lot of work for a few games (The Dungeon and Catalyst that I know of) and certainly not future proof as ADFFS would have to also make assumptions on RISCOS' Vector behaviour. It may be some time before these games can be supported, if at all.

A more future proof method would be to modify the 'janitor' Module to handle re-entrancy on FileV and call OS_File, so it's not dependent on the OS behaviour - essentially how it should have been written in the first place. This isn't particularly complex, however at the minute there's no means to patch Modules on-the-fly in ADFFS, so I'd have to add that functionality first.

[Vanfanel]

Oh, well, sad to hear it will take some time even if if ever happens, because The Dungeon really impressed me so much it sparkled my interest on Risc OS.
Are there any other first person dungeon crawlers on the system, Jon? I know it has great Amiga conversions but not stuff of this genre I believe.

[JonAbbott]

A more future proof method would be to modify the 'janitor' Module to handle re-entrancy on FileV and call OS_File, so it's not dependent on the OS behaviour - essentially how it should have been written in the first place. This isn't particularly complex, however at the minute there's no means to patch Modules on-the-fly in ADFFS, so I'd have to add that functionality first.

I added Module patching today and modified the janitor Module as described above. It now loads under the JIT on RO3.71 SA, but hangs when you start a new game. I've not looked in detail at the BASIC code, but it looks like it loads a lot of sound Modules and some code from disc 2. I'm not sure how far it gets into this process.

On RO5 I can't get it to load, the janitor Module is inserted to the RMA but it stops there. From the short time I've spent on debugging, it looks like itsFileV vector code is working, as the JIT sees all the relevant instructions, but there's possibly stack or PSR corruption as things start to go wrong after the first OS_File.

[Vanfanel]

wow!! You're going for it! Awesome!! Will be checking this thread daily!

[JonAbbott]

I've got it to the menu on RO5 SA, its failing beyond that because BASIC's SYS command isn't being intercepted and hypervized. I mistakenly thought BASIC used OS_CallASWI for SYS but it instead writes an SWI instruction to memory and branches to it. I'll need to either patch BASIC, or check if R14 is within BASIC and the previous instruction is MOV PC, Rx at the SWI vector.

[JonAbbott]

I'll need to either patch BASIC, or check if R14 is within BASIC and the previous instruction is MOV PC, Rx at the SWI vector.

Tried this earlier and it breaks BASIC in various places, so is a non-starter.

The Dungeon is failing because it makes assumptions about the position of the Voice name in an installed voice. From the address Sound_RemoveVoice returns in R0 (voicename pointer) it assumes R0-&3C is the voicegenerator start - which it isn't, so it subsequently fails when the next line tries:
SYS "Sound_InstallVoice",C%-&3C,I%+1

I think the only way to resolve this, is to Sound_InstallVoice and Sound_RemoveVoice from the Hypervisor to the SWI vector. There may be other Hypervised SWI's that also need moving across to fix BASIC code, but I'll probably deal with them as they come up, otherwise it's a major rewrite of Hypervised SWI's.

[JonAbbott]

I think the only way to resolve this, is to Sound_InstallVoice and Sound_RemoveVoice from the Hypervisor to the SWI vector.

This is now done, which gets the game a bit further. After fixing a bug in the SWI flag preservation of OS_BGet it gets into the game and then crashes.

It crashes as slightly different points on RO3.71 SA, RO5 SA and the Pi. From the crash on the Pi it looks like some code may be getting called directly instead of via the JIT - it's crashing in IRQ mode in Appspace, but the JIT is unaware of any Vector claims.

[JonAbbott]

it's crashing in IRQ mode in Appspace, but the JIT is unaware of any Vector claims.

PSR corruption is occurring in one or all of the sound Modules, if I prevent the sounds loading the game works.

EDIT: At the end of the fill code, they all switch into SVC, perform SWI Sound_Stereo and then switch back to IRQ. I suspect this is failing by corrupting SVC SPSR, but will need to modify all the Modules to confirm. Another solution is to call all Sound Generators in USR with IRQ's disabled - which is how it should be done anyhow as the CPU mode should be paravirtualized.

EDIT2: It's not the switching in/out of SVC that's at fault, but it is the Fill code in the 'click' sound Module that's causing the issues. I can't see anything obviously wrong with it on first glance, so will have to instruction trace it to see why it's causing PSR corruption.