-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".
26bit Module support
Re: 26bit Module support
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.Vanfanel wrote:Inferno hangs here after I press 1 to start game.
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.Vanfanel wrote:Will we see "The Dungeon" supported soon?
Re: 26bit Module support
I had a look at the protection this morning to see just how bad the situation is, its bad:JonAbbott wrote: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.
- The protection Module 'janitor' claims the following vectors: FileV, ArgsV, BPutV, GBPBV, FindV and CLIV
- 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
- 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
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.
Re: 26bit Module support
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.
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.
Re: 26bit Module support
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.JonAbbott wrote: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.
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.
Re: 26bit Module support
wow!! You're going for it! Awesome!! Will be checking this thread daily!
Re: 26bit Module support
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.
Re: 26bit Module support
Tried this earlier and it breaks BASIC in various places, so is a non-starter.JonAbbott wrote: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.
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.
Re: 26bit Module support
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.JonAbbott wrote:I think the only way to resolve this, is to Sound_InstallVoice and Sound_RemoveVoice from the Hypervisor to the SWI vector.
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.
Re: 26bit Module support
PSR corruption is occurring in one or all of the sound Modules, if I prevent the sounds loading the game works.JonAbbott wrote:it's crashing in IRQ mode in Appspace, but the JIT is unaware of any Vector claims.
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.