>The best general way to tackle something like this is software fuzzing. You >run your test in a tight loop and randomly (or sequentially) poke in values >until you have some difference in behavior, > resetting back to a clean slate each iteration. By comparing where/what > causes a change in behavior, you’ll understand the code. You can also do it without resetting back to a clean slate after each iteration. Running in an emulator and opening a memory window and holding down the 0 key so it repeats can often show you a lot about how a game works. If it crashes then you need to restart and sometimes changes can hide the effects of other changes. It depends on the overhead for restoring and trying again, I'd probably trace the code and use watchpoints if my initial attempts were not giving fast results. Message was sent through the cbm-hackers mailing listReceived on 2014-07-20 18:01:30
Archive generated by hypermail 2.2.0.