Yep, your brother has most probably moved the vector table into fastram
(for a slight speed increase) using the VBR command.
Worms has used the "TRAP #0" instruction, but it's patched it's self into
the location where the vectors used to be in chip ram.
--
Robin Grzasko E-Mail: ro...@robski.demon.co.uk
The most probable explaination is that the CPU vector table has been moved
into fast ram (for a slight speed increase) with the VBR command. Just
run it again to reset it back to it's original location and everything
should work fine.
AT> Hi,
AT>
AT> Worms has stopped working on my brother's 1200! Oh no! It gurus
AT> with 80000020 quite consitently whenever it gets to the creating level
AT>
AT> Luckily it still works fine on my, only slightly expanded, 1200.
AT> Basically, does anyone know what the above guru number stands for? If
AT> so, does it mean he's deep fried his chips?
The guru would seem to be -
"uninitialised Trap #0 error"
which usually means that the program is executing a TRAP 0 exception
instruction, but that the appropriate handling vector is not set.
I have absolutely no idea why it should be happening in this case,
though...
TTFN,
Keith.
--
"640k will be enough for anyone" - Bill Gates, 1981.
> I have absolutely no idea why it should be happening in this case,
> though...
Knowing it's most probably just a software error helped; what got me was
the fact that the error still ocurred when booting cold from floppy.
Finally tracked it down to AFS of all things, being loaded from the RDB
and obviously doing funny things to Worms.
Cheers for the pointers everyone. Now back to the game in hand...
Alex