OK, progress. Epyx used some really dodgy techniques to prevent anyone using Macsbug while running Winter Games!
Here's just part of it:
I dropped into Macsbug from the Finder and did "ATB _Launch" to break when launching an application, then "G" to return to the Finder and double-clicked Winter Games. Then I did "SS $64 $7C" to step-spy until anything in the low memory range $64-$7C (the interrupt vector table per Inside Macintosh II-197) changed. Sure enough, Winter Games' CODE #489 at offset $31E is changing some of the interrupt vectors to $40000A, in other words it redirects the code to the start of ROM -- which reboots the system! (See Inside Macintosh II-386.) This instruction I circled here just moved $40000A into low-memory location $70, which is completely rude: (it's inside a loop so it threw that same address into a bunch of other low-memory locations I didn't recognize, based on the array-of-bytes constant data embedded in this CODE resource at offset $32C -- by NOP'ing out this instruction, I prevented all that)
So I NOP'ed out that instruction with Resourcerer, patted myself on the back and thought Macsbug would now work inside Winter Games and I could figure out why it was freezing ...
NOPE. Now, instead of restarting the Mac, the interrupt switch from the Winter Games splash screen
does nothing at all. How is that possible? I repeated my earlier steps and kept stepping through the code after my NOP ... lo and behold the subroutine in CODE #489 at offset $384 is
changing Macsbug code. Talk about belt & suspenders, Epyx first destroyed the interrupt vector table then, it seems, erased parts of Macsbug itself in RAM just in case someone like me came long 35 years later and fixed the interrupt vectors! Need more investigation to rectify this. Will try to pick it back up over the weekend. Damn '80s programmers!!