Mac II with Turbo 040 - Unimplemented Trap

[esselfortium]

Is this with 7.1?

Yes.

Attached is Alessandro Levi Montalcini's Trap Check 1.1.1 report tool. Prior to crashing, run this and post the output file. I'm curious to see if you actually have unimplemented traps or have a memory issue.

I'll try it, thanks!

 

[cheesestraws]

I don't actually know when _CursorDeviceNextDevice turned up: the only header file I have here that I can see it mentioned in says System 7.5 at the top, and I can't see it in my 7.1-era hypertext reference thingy either.

 

[David Cook]

Is this with 7.1?

This is a good question. CursorDevices was added in System 7.5. So, maybe the first version of the game required System 7.5, and that was fixed in the other version of Doom II that you have.

 

[David Cook]

Yes.

I'll try it, thanks!

On the report, look for AADB or CursorDeviceDispatch.

The dispatch routine looks at the value of D0 to determine which function to ultimately execute. So, D0='0B' means call CursorDeviceNextDevice whereas D0='0A' calls CursorDeviceUnitsPerInch and so on. Combining multiple functions onto a single trap reduced the number of traps needed (which they were running out of). The downside is that patching a multiplexed trap patches all variations. So, init code would need to check the value of DO each time to determine if it was a call it wants to intercept.

 

[esselfortium]

The report says:

AADB _CursorDeviceDispatch TB ---

 

[cheesestraws]

Yeah, this sounds to me like the port requires 7.5 and is just being incredibly ungraceful about telling you that fact

 

[esselfortium]

Seems that way. I found version 1.0.3 of Mac Doom II in an old, old backup I had on here, tried it out, and it runs on 7.1.

Getting inexplicable crashes (macsbug telling me "bus error", as seen in the most recent screenshot on the previous page) loading it with certain WAD files that should work, though.

 

[David Cook]

CursorDevices was added in System 7.5.

I was wrong about this. CursorDevices was added to support the PowerBook 100/140/170 release. It was then added to the ROMs of computers released starting in 1992. So, maybe it exists generally in earlier versions of the system prior to 7.5. I cannot find documentation of it in Inside Macintosh, Develop Magazine, or the Technical Notes. But, I haven't done a complete search.

In any case, I would consider this a bug in Doom II, not in your computer.

 

[esselfortium]

I was wrong about this. CursorDevices was added to support the PowerBook 100/140/170 release. It was then added to the ROMs of computers released starting in 1992. So, maybe it exists generally in earlier versions of the system prior to 7.5. I cannot find documentation of it in Inside Macintosh, Develop Magazine, or the Technical Notes. But, I haven't done a complete search.

In any case, I would consider this a bug in Doom II, not in your computer.

Interesting. Thanks for the info on this!

I do believe there's still something odd with the computer itself -- I tried installing QuickTime 2.1, and that extension errored on boot.

 

[David Cook]

I was wrong about this. CursorDevices was added to support the PowerBook 100/140/170 release. It was then added to the ROMs of computers released starting in 1992. So, maybe it exists generally in earlier versions of the system prior to 7.5. I cannot find documentation of it in Inside Macintosh, Develop Magazine, or the Technical Notes. But, I haven't done a complete search.

In any case, I would consider this a bug in Doom II, not in your computer.

I've found one reference to CrsrDevDispatch (aka CursorDeviceDispatch), on Page 47

https://vintageapple.org/macprogramming/pdf/Mac_Programming_FAQs_1996.pdf

I'm disappointed that they just say "newer machine", rather than being specific to a year or OS version. Nevertheless, checking for the trap is the correct coding practice.

I do believe there's still something odd with the computer itself

Agreed. You have an interesting mix of technology there.

 

[joshc]

I don't have a specific source for this, but I think it is generally known that the Mac ports of Doom / Doom II are... a bit shoddy. If someone thinks that is categorically untrue, please correct me. But I am sure I've heard/read that somewhere several times, and it wouldn't surprise me if there are various compatibility issues with those games depending on your Mac OS version and hardware.

But yeah... an 040 in a Mac II? There will just be a lot of games/software that won't like to run on that.

 

[Phipli]

Yeah, very old ROM, new processor.

 

[esselfortium]

Fair enough. Thanks again for the advice, everyone! I may be back with more questions at some point.

 

[esselfortium]

I've been getting pretty common (and replicable) bus errors. Latest one was at BlockMoveData. Something is definitely not right but I'm not sure what to do about it. Is it likely that this is caused by bad RAM, or is something else a more likely culprit with this sort of setup?

 

[joshc]

I've been getting pretty common (and replicable) bus errors. Latest one was at BlockMoveData. Something is definitely not right but I'm not sure what to do about it. Is it likely that this is caused by bad RAM, or is something else a more likely culprit with this sort of setup?

What sorts of things are you doing when these bus errors occur?

 

[esselfortium]

Off the top of my head: Got one while trying to install NetBSD, got another while trying to open a level in Hellmaker, got one while trying to install OptiMem to see if patching the memory management would make any difference to all the bus errors, got one while trying to load a larger wad in Doom II. It's pretty frequent and doesn't seem to be related to one specific application.

I did briefly try the Toka040 init that was linked earlier in this thread, just in case it was a similar issue, but it didn't help either, so I've disabled it.

 

[zigzagjoe]

Off the top of my head: Got one while trying to install NetBSD, got another while trying to open a level in Hellmaker, got one while trying to install OptiMem to see if patching the memory management would make any difference to all the bus errors, got one while trying to load a larger wad in Doom II. It's pretty frequent and doesn't seem to be related to one specific application.

I did briefly try the Toka040 init that was linked earlier in this thread, just in case it was a similar issue, but it didn't help either, so I've disabled it.

If you still have macsbug installed, recommend taking pictures of the crash screens so you can look for points of commonality.

Bus error means a read or write was attempted to an address, and nothing responded; usually means for some reason you're trying to read a bad address. Many potential causes, dodgy RAM is one of them.

If you still have the link to my site, there should be a Mac Test Pro image in there. This is Apple's bootable diagnostics, you can try running it. In particular it has a loopable rigorous RAM that that may be of use.

 

[esselfortium]

If you still have macsbug installed, recommend taking pictures of the crash screens so you can look for points of commonality.

Bus error means a read or write was attempted to an address, and nothing responded; usually means for some reason you're trying to read a bad address. Many potential causes, dodgy RAM is one of them.

If you still have the link to my site, there should be a Mac Test Pro image in there. This is Apple's bootable diagnostics, you can try running it. In particular it has a loopable rigorous RAM that that may be of use.

Thanks.

The logic board test says that the ROM checksum test failed. That seems bad.

I'm guessing that it's not expected for the ROM to appear unusual when an accelerator is installed, or anything like that, and that this probably is an actual indicator of a problem.

Tried a RAM test afterwards. It got most of the way through, but the computer locked up and went completely unresponsive (requiring a force-reboot) testing RAM at address $13D54C4, right toward the end.

 

[Phipli]

Thanks.

The logic board test says that the ROM checksum test failed. That seems bad.

I'm guessing that it's not expected for the ROM to appear unusual when an accelerator is installed, or anything like that, and that this probably is an actual indicator of a problem.

Tried a RAM test afterwards. It got most of the way through, but the computer locked up and went completely unresponsive (requiring a force-reboot) testing RAM at address $13D54C4, right toward the end.

Run the test without the accelerator.

There is a chance that the accelerator is automatically patching the ROM, and this might be the source of all your problems. If the accelerator isn't designed to work with your ROM revision, then it might be... making a mess.

 

[esselfortium]

I'm unsure how to pry out the accelerator without damaging it.