Bolle Carrera040 issue with Macsbug

[powellb]

Colleagues,

I have been running my SE/30 with GW ROM installed (using standard IIsi) and Bolle's Carrera040 clone without issue for some time. I have been using TMON Pro as my debugger, but now that I am doing some development on this machine as well as on a PPC machine running OS9, I wanted to use the same debugger. So, I switched back to Macsbug (which is what I had used 40 years ago).

To my surprise, Macsbug won't work on my SE/30 configuration. I boot a fresh System 7.1 install with Carrera040 drivers and Macsbug. On boot it says "Debugger Loaded"; however, once booted, triggering the debugger, I get the standard Macintosh monitor (> prompt).

I removed the Carrera040, and Macsbug works just fine. I have tried Macsbug versions 6.2.2, 6.5.3, and 6.6.3. I think TMON Pro works because it is loaded after Carrera040; whereas, Macsbug is loaded prior.

It would seem to me that the Carrera040 driver overwrites trap to invoke Macsbug, putting it back to the ROM monitor.

Searching the forums (maybe I missed something), I can't find anyone else with this issue, so I want to find out if others have this issue.

Edit: add Macsbug versions.

 

[zigzagjoe]

Colleagues,

I have been running my SE/30 with GW ROM installed (using standard IIsi) and Bolle's Carrera040 clone without issue for some time. I have been using TMON Pro as my debugger, but now that I am doing some development on this machine as well as on a PPC machine running OS9, I wanted to use the same debugger. So, I switched back to Macsbug (which is what I had used 40 years ago).

To my surprise, Macsbug won't work on my SE/30 configuration. I boot a fresh System 7.1 install with Carrera040 drivers and Macsbug. On boot it says "Debugger Loaded"; however, once booted, triggering the debugger, I get the standard Macintosh monitor (> prompt).

I removed the Carrera040, and Macsbug works just fine. I have tried Macsbug versions 6.2.2, 6.5.3, and 6.6.3. I think TMON Pro works because it is loaded after Carrera040; whereas, Macsbug is loaded prior.

It would seem to me that the Carrera040 driver overwrites trap to invoke Macsbug, putting it back to the ROM monitor.

Searching the forums (maybe I missed something), I can't find anyone else with this issue, so I want to find out if others have this issue.

Edit: add Macsbug versions.

This is expected. The transition between CPUs thrashes the vector table, killing macsbug. Geekdot wrote a post that goes into some detail on the topic.

 

[powellb]

This is expected. The transition between CPUs thrashes the vector table, killing macsbug. Geekdot wrote a post that goes into some detail on the topic.

Thanks, that is what I was suspecting in my original post. I just wasn't sure.

Searching 68kmla, I couldn't find any posts about this from Geekdot; however, searching the web, I found his wonderful series of articles looking at how the Carrera040 driver gets another processor up and running. This one address the vector table. Too bad the driver doesn't try to examine the vector table for macsbug and restore its vectors after installing a new table for the '040.

I suppose that someone could modify Geekdot's decompiled code (github) and try to get it compiled and running as a new driver. I'll add that to my many possible to-dos that are low priority...

Geekdot: CARRERA 040 IN AN SE/30