Software Development and Unimplemented Traps with System 3.2

[bigmessowires]

The flash tool program that I developed for the Mac Plus ROM adapter doesn't work under System 3.2 - it bombs with error ID = 12, which seems to mean I called a trap routine that's not implemented in that version of the system. I fixed one instance of this by changing the program to use GetNextEvent() instead of WaitNextEvent(), so now at least the program starts up and shows the dialog box. But if you select a file to use as the ROM image, it bombs again with ID = 12, and I can't figure out why.

From experiments with commenting out parts of the code, it looks like calls to FSOpen() and GetDialogItem() both cause an ID = 12 bomb. But FSOpen() appears in Inside Macintosh Volume II, which means it's been available since the earliest days of the Mac. I don't know why it would bomb. GetDialogItem() is a renamed version of GetDItem(), which appears in Inside Macintosh Volume I. Again, it's been there since forever, and shouldn't bomb under old System versions. 

Here is the code where the bombs occur when running under System 3.2, inside the if (repl.good) block. There are some references to global variables declared outside this function.



Any ideas why System 3.2 would choke on this code, and how to fix it?

 

[olePigeon]

My official advice as a liberal arts major is to make sure your 1s are straight and your 0s are nice and round... but not too round.  Otherwise it'll mistake it for an O and your program won't work.

 

[CC_333]

OlePigeon: Funny! :lol:

I'm afraid I don't have any useful information to add here, either.

I'm sure you'll figure it out, though (you always do, it seems).

c

 

[Gryphel]

One thing about FSOpen is that it is not a ROM trap, it is provided by glue in your development environment. (The low level trap is PBOpen.) It is possible that your development environment may not support the oldest Macs. I've run into such issues. For my Mini vMac Extras I tend to not use the provided headers, and instead use my own file "MYMACAPI.i". This also makes it easier to work with multiple development environments and not be affect by name changes like GetDialogItem/GetDItem. (My "FILEUTIL.i" provides some higher level file routines using the low level traps defined "MYMACAPI.i".)

For GetDialogItem, that should be a low level trap, so there must be another reason. Your code doesn't include where "dg" is defined. If it wasn't properly initialized that would cause problems.

 

[bigmessowires]

Gryphel is right, and bbraun helped me figure it out. I am using Codewarrior 10, which automatically slips calls to _StripAddress into the generated code. That call isn't necessary on a Mac Plus, since it's always in 24 bit mode, but since _StripAddress isn't implemented in the Plus ROM nor in System 3.2, the program bombs out. There doesn't seem to be any Codewarrior option to disable this "helpful" behavior, but using ResEdit I was able to search the generated code for the _StripAddress trap (0xA055) and replace it with a NOP (0x4E71). Now everything is happy.