|
Error recovery in RISC OS |
|
Phlamethrower (15:20 9/6/2004) Phlamethrower (15:34 9/6/2004) adrianl (15:47 9/6/2004) Phlamethrower (15:56 9/6/2004) adrianl (16:08 9/6/2004) Phlamethrower (16:21 9/6/2004) adrianl (16:29 9/6/2004) monkeyson2 (16:38 9/6/2004) Phlamethrower (17:09 9/6/2004) adrianl (18:44 9/6/2004) adrianl (18:52 9/6/2004) Phlamethrower (19:45 9/6/2004) Phlamethrower (20:02 9/6/2004) adrianl (20:33 9/6/2004) Phlamethrower (20:59 9/6/2004) Phlamethrower (21:30 9/6/2004) adrianl (21:40 9/6/2004) Phlamethrower (21:55 9/6/2004) adrianl (22:43 9/6/2004) adrianl (23:16 9/6/2004) Phlamethrower (23:31 9/6/2004) Phlamethrower (18:57 9/6/2004) Phlamethrower (16:20 9/6/2004)
|
|
Jeffrey Lee |
Message #55537, posted by Phlamethrower at 15:20, 9/6/2004 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Anyone got any ideas on how this could be improved?
For example I'm currently trying to get Wolf 3D working, but it locks up when I load/start a new game. GrabError is able to generate a report, but I'm forced to restart the machine each time I try something out. The fact that GrabError can generate a report suggests that the machine isn't completely dead, hence that recovery from the error should be possible - yet it does not happen. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55538, posted by Phlamethrower at 15:34, 9/6/2004, in reply to message #55537 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Curiously enough, it appears to be some code which makes Wolfenstein quit that's causing the problems. It's trying to use R14 in IRQ mode with interrupts enabled, and leading it to fail when R14 gets corrupted by an interrupt routine. So now I've got to fix the bug there, in order to find why Wolf is trying to exit |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55539, posted by adrianl at 15:47, 9/6/2004, in reply to message #55538 |
Member
Posts: 1637
|
Logging all the SWIs that are called would probably help you track down why it's quitting. If you get really stuck I'll run it under a debug build of Aemulor if you like (Aemulor can record all sorts of things about the 26-bit program that it's running). |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55540, posted by Phlamethrower at 15:56, 9/6/2004, in reply to message #55539 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Interesting. The code isn't quitting, becuase if it was it would fade the screen to black. And quitting the game normally doesn't cause any problems.
However, I have just managed to coax it into a branch through zero from within a module - and it's returned to RISC OS without any problems
[edit]
Until I try opening the error report, that is
[Edited by Phlamethrower at 16:57, 9/6/2004] |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55541, posted by adrianl at 16:08, 9/6/2004, in reply to message #55540 |
Member
Posts: 1637
|
You probably know this, but looking at R14 is often the easiest way to find out how it arrived at address 0. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55542, posted by Phlamethrower at 16:20, 9/6/2004, in reply to message #55540 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Fun! The branch through zero is coming from a RISC OS exception handler. But I can't track down where the error block for the exception (and hence the exception name) is - the closest I can get is that it's stored at R14 of the interrupted program |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55543, posted by Phlamethrower at 16:21, 9/6/2004, in reply to message #55541 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
You probably know this, but looking at R14 is often the easiest way to find out how it arrived at address 0. In this case, R14 = &FE. Not the most helpful!
[edit]
Although I guess that would place it inside the FIQ handler, with the processor in SVC mode - but still doesn't really explain what's going on!
[Edited by Phlamethrower at 17:26, 9/6/2004] |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55544, posted by adrianl at 16:29, 9/6/2004, in reply to message #55543 |
Member
Posts: 1637
|
Nah, don't believe R14 in that case - it's prob holding a temporary value rather than a return address. My DebugLog module would probably help catch it (it claims the processor vectors and catches the first exception - RO's exception handlers often generate further exceptions ) but it's no use on pre-Iyonix machines ATM. Is it worth me having a look? |
|
[ Log in to reply ] |
|
Phil Mellor |
Message #55545, posted by monkeyson2 at 16:38, 9/6/2004, in reply to message #55544 |
Please don't let them make me be a monkey butler
Posts: 12380
|
My DebugLog module would probably help catch it (it claims the processor vectors and catches the first exception - RO's exception handlers often generate further exceptions ) but it's no use on pre-Iyonix machines ATM. Is it worth me having a look? Nah, make buy an Iyonix |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55546, posted by Phlamethrower at 17:09, 9/6/2004, in reply to message #55544 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Is it worth me having a look? Well I can't make any sense of it - expect to see a copy arriving in your inbox in the next few minutes
I've also got a copy of the source code I could send you if you need to work out what a particular bit of code is meant to be doing. I would probably be working directly from the source, but there doesn't seem to be a way to disable the disc protection & code compression without hacking around in the code. |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55547, posted by adrianl at 18:44, 9/6/2004, in reply to message #55546 |
Member
Posts: 1637
|
How did you produce WolfExe? It looks as though you've saved the application memory rather than run the executable through an unsqueeze utility... if so, are you sure nothing had been executed that would cause the memory contents to change? |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55550, posted by adrianl at 18:52, 9/6/2004, in reply to message #55547 |
Member
Posts: 1637
|
As a bit of background, in case you're unfamiliar with the Acorn dev suite - if you find 'rcc x.yz' (where the version number x.yz is usually 4.0x or 5.0x) at the end of the executable, followed by some trailing spaces, it means the program's been compressed using the 'squeeze' utility. It's purely a way to compress executables, it's not an encryption/protection algorithm. There's a module that will do this unsqueezing for you, though I think I may have knocked it about a bit to get it to do this! You probably realise that coredumping an application that's started running won't necessarily give a working executable because it will have modified its data already. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55551, posted by Phlamethrower at 18:57, 9/6/2004, in reply to message #55547 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
How did you produce WolfExe? It looks as though you've saved the application memory rather than run the executable through an unsqueeze utility... if so, are you sure nothing had been executed that would cause the memory contents to change? Yes, I saved the application memory, after allowing the code to unsqueeze, decrypt, and run a checksum on itself. I could have used an unsqueeze utility if I had one, but I'd still have had to decrypt it and remove the checksum code so saving application memory seemed the simplest way to do it. As far as I remember, the only thing it did apart from the above was to switch to mode 0 - which I made sure got left behind/reimplemented anyway. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55553, posted by Phlamethrower at 19:45, 9/6/2004, in reply to message #55550 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
As a bit of background, in case you're unfamiliar with the Acorn dev suite - if you find 'rcc x.yz' (where the version number x.yz is usually 4.0x or 5.0x) at the end of the executable, followed by some trailing spaces, it means the program's been compressed using the 'squeeze' utility. Yup, after hacking around in numerous programs I managed to deduce that myself.
You probably realise that coredumping an application that's started running won't necessarily give a working executable because it will have modified its data already. Yup - hence why I use ARM_Debug's single/multi stepper to stop the program just before it does anything beyond the decompression/decryption.
[edit]
I've located the 'new game' code in the source code & executable, and am inserting calls to the game quit code in an effort to find the bit which is breaking.
[edit #2]
Tracked it down to the clsred function - disable that, and the game works fine
Now to work out why it's going wrong, and find out what the keys were to increase the screen size! (Back before the game broke completely, it was possible to run it on my Risc PC - but only with the cache turned off. So I shrunk the screen to its smallest size and played like that in )
[Edited by Phlamethrower at 20:58, 9/6/2004] |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55554, posted by Phlamethrower at 20:02, 9/6/2004, in reply to message #55553 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Ah, clsred calls another evil copy protection function which calculates a checksum of the code. Shouldn't be too hard to fix!
[edit]
CMP R0,#0 MOVNE PC,#0
I guess that could be the cause of the branch through zero!
[Edited by Phlamethrower at 21:05, 9/6/2004] |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55555, posted by adrianl at 20:33, 9/6/2004, in reply to message #55554 |
Member
Posts: 1637
|
Searching for MOVcc PC,#0 in WolfExe produces 3 other matches. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55556, posted by Phlamethrower at 20:59, 9/6/2004, in reply to message #55555 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Hmm, so it does. The first is in an error generator, but will only crash if it's been told too. Probably a good idea to disable it though.
The second is there to prevent an invalid music file being loaded, so I'll swap that for an OS_Exit.
The third is the checksum code (Which gets modified when it's output, hence why CMP R0,#0 is in the source yet CMP R0,#&26 is in the executable)
And the final one looks, erm, tricky
I can assume that it's something to do with error checking like the second one (It looks like it could be checking for bad object types, or possibly to do with the disc key), so I'll swap that for an OS_Exit too.
Now all I need to do is convince it that Risc PC's are capable of playing the music while in game! |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55557, posted by Phlamethrower at 21:30, 9/6/2004, in reply to message #55556 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Done |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55558, posted by adrianl at 21:40, 9/6/2004, in reply to message #55557 |
Member
Posts: 1637
|
And for an encore, RISC OS 6: * preemptive multitasking * modernised, non-blocking, DMA-based I/O transfers * multi-monitor support * symmetric multiprocessing * full memory protection PLUS * rounded buttons! |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55559, posted by Phlamethrower at 21:55, 9/6/2004, in reply to message #55558 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I'll do all but the last one |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55562, posted by adrianl at 22:43, 9/6/2004, in reply to message #55559 |
Member
Posts: 1637
|
In case you haven't spotted it - code at &19E48 checks CP15,C2 to determine whether the cache is enabled. This doesn't work on post-ARM3 processors because C2 is now the Translation Table Base..... So, it thinks the cache is disabled and moans if you try to use Mode 49 instead of 13. Well, it does here anyway under Pro.... strictly speaking bits [13:0] are undefined for StrongARM and they just happen to read with bit 0 set because it's actually driving the data bus with bits [13:0] of the Control register (and the MMU's always enabled - hence bit 0 set). I'll prob change Pro to mimic this behaviour anyway, but whilst you're working on the code.... |
|
[ Log in to reply ] |
|
Adrian Lees |
Message #55563, posted by adrianl at 23:16, 9/6/2004, in reply to message #55562 |
Member
Posts: 1637
|
Oh, one other thing.... *ducks* Please let me know if you ever encounter a freeze when hitting F7 to reduce the screen size. Running with the SA engine, I invariably get this if the screen's at max size (it reduces, the mouse pointer appears and then it's lights out).... never seen it on the SA RPC but it could be intermittent. Have you seen any evidence of self-modifying code on your travels? Oh, and can I download the source from somewhere, BTW? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #55564, posted by Phlamethrower at 23:31, 9/6/2004, in reply to message #55563 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
In case you haven't spotted it - code at &19E48 checks CP15,C2 to determine whether the cache is enabled. This doesn't work on post-ARM3 processors because C2 is now the Translation Table Base..... Yes, I spotted that - and couldn't make head nor tail of any of the MRC/MCR instruction documentation, nor precisely what the code was trying to do with it. So I just hacked the processor check to always return ARM 3
*ducks* ?
Please let me know if you ever encounter a freeze when hitting F7 to reduce the screen size. Running with the SA engine, I invariably get this if the screen's at max size (it reduces, the mouse pointer appears and then it's lights out).... never seen it on the SA RPC but it could be intermittent. Seems to work fine here
Have you seen any evidence of self-modifying code on your travels? The only bit I spotted was the usual evil code in the disc checking function. The rest appears to be fine
Oh, and can I download the source from somewhere, BTW? I'll email you a copy. We're not allowed to put it on the web
http://web.archive.org/web/19990901175046/powerslave.com/wolf3d/
[Edited by Phlamethrower at 00:31, 10/6/2004] |
|
[ Log in to reply ] |
|
|