I got the file and am currently analzying it. Thanks! I will post again when I have some definite answers.Quote:
Originally Posted by redelf
Don Hodges
Printable View
I got the file and am currently analzying it. Thanks! I will post again when I have some definite answers.Quote:
Originally Posted by redelf
Don Hodges
I play stuff mostly on MAME, except for the real ones at the local classic arcade (no Robotron there though). Anyway, tournament is 5 men to start, no extras, whereas marathon is default settings, with an extra man every 25K (which, of course, can be marathoned)Quote:
Originally Posted by cocacolakid45
Wow John!! Change of heart?? I remember asking you about a Robatron marathon at the NW show last June and you figured "no way!" Partly due to the fact the current WR is completely bogus and everyone knows it!!
Was it Ken that proved you could NOT mathematically score what the current mark is? With all the controversy that surrounds the WR on robatron I would love nothing more to see you tear that sucker apart!! Just make sure when you do that there is a medic present. The intensity of that game can give someone a heart attack especially in the higher levels :mrgreen:
Go for it my friend!! 70-80 hours would be the greatest marathon EVER!! TG has to re-issue the reset rule. If they don't.....then that is even further verification that the current mark is bogus!!
Geeze figures you'd beat me to this too :)Quote:
Originally Posted by redelf
Yesterday I played about 140 levels (~60 minutes game time) with zero crashes.
I'll keep trying to create another crash until we get Don's initial report (just in case we need more data points)
I personally am really curious if my gut analysis of what causes the problem will match up with the reality of the code... cool stuff.
Can't wait to see what Don comes up with. The Robotron rug reset is one of the most well known glitches in classic arcade gaming.
So come on John! 350,000,471 or bust!!!! Do it at the KEn-cade, I'll drive up for support!
Ez
I second that! Heck, with as close as the Kencade is and as long as this would take, I could make three or four trips up :)
This is a good idea. I am having a little bit of trouble with the INP from the older version of MAME. It seems the debugger is crashing when I try to open a memory window. An INP from a newer version of MAME would be great and would help me figure this out.Quote:
Originally Posted by dfonda
Don Hodges
OK. I have analyzed this crash and found the cause. I'm still working on the patch ... I've got one that works, but I haven't gotten around to fixing the checksums yet.Quote:
Originally Posted by redelf
Basically, when enforcers (and possibly other enemies) are killed by diagonal shots at certain screen locations, it is possible for a subroutine which handles the explosion, to jump to an unexpected location in the game's code. When this happens, the game's watchdog eventually kicks in and reboots the program.
In more detail: [I use the # to denote numbers in hexadecimal.]
The subroutine which handles the explosion is fairly complex. One of the things that it does is compute a number that should be between #0 and #10 (16 decimal). [Actually, if it result is 0, this is checked for and the routine is aborted]. This result is then subtracted from #10 to produce a new number which is then multiplied by #D (13 decimal). This result is added to #478C to produce a jump vector which handles the explosion.
Normally, this all works. However, on rare occasions, it is possible for the first computation to result in a number larger than #10. In the .INP file supplied, this first result is #29. When subtracted from #10, a the result is #E7 which is then multiplied by #D and gives an offset of #BBB. When added to #478C, the result is #5347, which is the address the program eventually jumps to a few instructions later.
Well, #5347 is not even program code, it is data code. But the program tries to execute from here anyway, and before long the watchdog kicks in and resets the game.
I have written a patch which hooks into the game right after the first result is computed. It jumps to a new subroutine which checks if this result is over #10, and if it is, to set it to #10, and then return to the program. It seems to work. However, this game has some complex checksum routines which must also be tricked, in order for this patch to really work properly.
I will try to post more details in the next few days, when I can find the time to do a proper write-up.
It would be very cool to get another recording of a reset, so I could see how the behaviour is the same or different at this section of code. I suppose that other locations would give slightly different jump vectors, but still "out of bounds", and causing resets.
Don Hodges
sweet..that is exactly what several of us suspected was the cause.Quote:
Originally Posted by PhantomDJ
Sounds very confusing but I understand what Don is talking about.