Bolo works correctly (if not swiftly) on a Mac Classic. I played Bolo on a Classic for years in the 90s.
I did not have Internet access at the time and only played local games using AppleTalk, so I never used Internet Bolo Buddy.
Interesting... so the same error, "Undefined A-Trap at 003477FE KevAppIsRunningCopyOfThisApp__FP19ProcessSe..." for both.
I suspect that's not the case.
KevAppIsRunningCopyOfThisApp__FP19ProcessSerialNumber is not a symbol in Bolo, but it is a symbol in Internet Bolo Buddy. I suspect the Internet Bolo Buddy crash screenshot was taken first, and then Bolo was run without restarting in between. If so, MacsBug's output does not clear between programs, so the line about
KevAppIsRunningCopyOfThisApp__FP19ProcessSerialNumber should be ignored for the Bolo crash, since that was from the Internet Bolo Buddy crash.
- I've tried it with minimal 6.0.8, and also 7.1 and 7.5.5 with extensions. Same result in every OS.
I am able to reproduce the crash with Internet Bolo Buddy 2.0 in Mini vMac emulating a Mac Classic and running System 6.0.8. It crashes into MacsBug with an unimplemented trap error while in the
KevAppIsRunningCopyOfThisApp__FP19ProcessSerialNumber function. By disassembling the code around the program counter with the
ip pc command, I can see that the trap it's trying to use is
_GetCurrentProcess. That's part of the Process Manager which was introduced in System 7, so Internet Bolo Buddy evidently requires System 7 or later, and was not programmed to fail gracefully on older systems.
If I try under System 7.0.1, it crashes in a different function,
KevDevGetMainDeviceRect. It's still an unimplemented trap error, but here the trap it's trying to use is
_GetMainDevice which is part of Color QuickDraw, so Internet Bolo Buddy evidently requires Color QuickDraw, which does not exist on a Mac Classic.
- I installed MacsBug and that allowed me to somewhat get past the crashing in Bolo by continuing program execution every time it happened, but it didn't help with the Bolo Buddy.
Using MacsBug to continue past a crash will usually get you more and weirder crashes, especially if the crash was an unimplemented trap and the trap required parameters.
The Mac toolbox uses Pascal calling conventions which means that before calling a toolbox function, the program pushes the required parameters onto the stack. The act of calling a function with the
JSR instruction then causes the current program counter to be pushed onto the stack, so that execution can return here after the function call is done. (Toolbox traps aren't called with
JSR but the principle is the same.) The toolbox function is expected to have popped our parameters off the stack before it returns.
With an unimplemented trap, that means there's no code in the OS for that function, not even code to remove those parameters. After all, how could an earlier OS know how many parameters are expected by a future OS function? Hence, if you continue past an unimplemented trap error, the stack can have more items on it than it should. This may be what MacsBug means when it says "Warning: The command completed without using all parameters" in your screenshot. When
your function eventually wants to return to its caller using the
RTS instruction, it pops what it thinks is the return address off the stack, but actually something else is at that position of the stack and gets misinterpreted as a return address, so execution then jumps to a completely wrong location in memory. That location could contain unrelated code from your program, any other program (even one that is no longer running but whose memory has not yet been reused), the OS, non-code data, or random garbage. Depending on what's there, the CPU may continue executing these meaningless instructions for some time before it eventually reaches one that doesn't make sense and causes a crash, so the information MacsBug tells you about what function you're in when you crashed or what it was doing may be meaningless.
For example,
_GetCurrentProcess requires one parameter: a memory location into which the process serial number will be written. Continuing past that unimplemented trap will corrupt the stack and lead to a crash.
Each application gets its own stack, so if you crash with an unimplemented trap error, you might be able to recover your computing session by force-quitting the program using MacsBug's escape to shell command
es (after which you should immediately save work in other programs and restart properly), but trying to continue the program after a crash is likely to lock up the computer and require an immediate restart.
The error in your Bolo crash screenshot was:
Code:
Address Error at 0008CD92 'CODE 0005 011C Mac Support'+28B6
'CODE 0005 011C Mac Support'
+28B6 0008CD92 *ORI.B #$6E40,D4
But looking in Bolo's
CODE resource ID 5 around that offset, its code is actually:
Code:
+28B4 CMP.W $0004(A0),D0 ;B068 0004
+28B8 BGT.S Anon40+$0152 ;6E40
Offset +28B6 where it crashed is not the start of an instruction. It's in the middle of the
CMP instruction. As a result, the CPU misinterprets the
CMP operand
0004 as an
ORI opcode, and misinterprets the
BGT opcode
6E40 as
ORI's operand. Knowing that this crashed with an address error isn't useful since this isn't an instruction that anyone ever intended it to run.
If you still get this crash when running Bolo, and you don't have any weird extensions installed, and you haven't run Internet Bolo Buddy or any other programs this session that might've messed up the system, and you haven't used MacsBug to continue past any earlier errors, then some investigation would be needed to determine what caused program execution to continue at this incorrect address. MacsBug's stack crawl commands
sc6 and
sc7 can be useful to show what functions were called, except that if the stack is corrupted it might not be completely accurate.
