log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: The Playpen: Error recovery in RISC OS
 
  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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
:laugh:

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
PhlamethrowerHot 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
PhlamethrowerHot 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 :o

[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
PhlamethrowerHot 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
PhlamethrowerHot 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
monkeyson2Please 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 :flamethrower: buy an Iyonix :P
  ^[ Log in to reply ]
 
Jeffrey Lee Message #55546, posted by Phlamethrower at 17:09, 9/6/2004, in reply to message #55544
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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 :E

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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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*
:duck::duck::duck::duck:? :o

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 ]
 

The Icon Bar: The Playpen: Error recovery in RISC OS