Mac68k Forums

Home


Welcome, Guest
Guest Settings
Help

Mac68k Forums » Help » Software Help

Thread: Building programs for System 3.2


Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 3 - Pages: 1 - Last Post: Jan 7, 2015 2:03 PM Last Post By: bbraun Threads: [ Previous | Next ]
bigmessowires


Posts: 217
Registered: 10/29/13
Building programs for System 3.2
Posted: Jan 7, 2015 1:27 PM
Click to report abuse...   Click to reply to this thread Reply
Flash Tool 1.2 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:

void SelectFile()
{
SFReply repl;
Point where;
short itemType;
Handle itemHandle;
Rect itemRect;
short fileRefNum;
OSErr err = noErr;

where.h = 100;
where.v = 100;

SFGetFile(where,"\pROM image file:",0L,-1,0L,0L,&repl);

if (repl.good)
{
if (FSOpen(repl.fName, repl.vRefNum, &fileRefNum) != noErr)
{
ParamText("\pError opening image file", NULL, NULL, NULL);
NoteAlert(ALERT_ID, NULL);
return;
}

err = GetEOF(fileRefNum, &imageFileSize);
FSClose(fileRefNum);

if (err != noErr)
{
ParamText("\pError determining size of image file", NULL, NULL, NULL);
NoteAlert(ALERT_ID, NULL);
return;
}

imageFileVRefNum = repl.vRefNum;
GetDialogItem(dg, DIALOG_ITEM_FILENAME, &itemType, &itemHandle, &itemRect);
SetDialogItemText(itemHandle, repl.fName);

sprintf(imageFileSizeText, "%lu bytes (%lX hex)", imageFileSize, imageFileSize);
c2pstr(imageFileSizeText);
GetDialogItem(dg, DIALOG_ITEM_FILESIZE, &itemType, &itemHandle, &itemRect);
SetDialogItemText(itemHandle, (unsigned char*)imageFileSizeText);
}
}

(aside - is there no way to retain text formatting when making forum posts here?)

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


Posts: 493
Registered: 7/25/12
Re: Building programs for System 3.2
Posted: Jan 7, 2015 1:38 PM   in response to: bigmessowires in response to: bigmessowires
Click to report abuse...   Click to reply to this thread Reply
Can you install macsbug on the machine? That should be able to help you figure out what the trap is that's causing the problem. Are you using CodeWarrior? It seems like CW's not setup for developing for older releases. You probably are including the MacOS.lib library that can be doing calls only implemented on later systems. The most common I've found is _StripAddress (0xA055), which I think appeared in system 4?
Just doing a hexdump on the resource fork of Flash Tool 1.2, I see two calls in there. Fortunately, just s/a055/4e71/ works fine for _StripAddress since it modifies A0 in place, so you don't have to do anything to have a correct return value for 24bit only machines.

I've found THINKC5 and earlier work well for developing for early systems. They don't add a lot of the glue code that CW does.
bigmessowires


Posts: 217
Registered: 10/29/13
Re: Building programs for System 3.2
Posted: Jan 7, 2015 2:01 PM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
You're a genius. I know you mentioned that same thing with your ROM disk driver, but I didn't think to check it.

Using ResEdit, I patched the first instance of A055 with 4E71 and now the program seems to work under System 3.2 (still needs a bit more testing). The second instance looks like it was actually part of two other instructions: nnA0 followed by 55nn. When I patched that one, I started getting bomb ID = 03, illegal instruction. So I think only the first one is actually a call to StripAddress.

I should look in the Codewarrior code generation options to see if there's a way to fix this.
bbraun


Posts: 493
Registered: 7/25/12
Re: Building programs for System 3.2
Posted: Jan 7, 2015 2:03 PM   in response to: bigmessowires in response to: bigmessowires
Click to report abuse...   Click to reply to this thread Reply
Cool! Yeah, it's been an issue for the ROM work because the Plus ROM doesn't have it implemented, although once booted into a newer System software, the trap gets installed (although is essentially a nop anyway, at least the trap is there and works).

Point your RSS reader here for a feed of the latest messages in all forums