Coding for the 512K (possibly 128?) with Symantec

[Mu0n]

I usually go as low as using the Mac Plus as a target, using:
-Symantec C++ 6.0
-Using MacTraps and/or ANSI
-Default compiler settings, at least 384K of partition memory for the app

However, that starts to fail if I try launching those programs with a 512K emulated in Snow, Finder 4.1, using its 64k ROM file. I get a mac bomb ID=02.

I've tried:

-using the "Old MacTraps" library instead of "Mac Traps"
-lowering the partition memory used to 256K
-forcing the compiler settings to use 1-byte alignment for structs

None of those move the needle.
Do you absolutely have to use something like THINK C 3 or 4 to get there?

edit - Finder 4.1 under a Plus is able to launch my program, so it's not a Finder/System issue.

 

[Snial]

I usually go as low as using the Mac Plus as a target, using:
-Symantec C++ 6.0
-Using MacTraps and/or ANSI
-Default compiler settings, at least 384K of partition memory for the app

However, that starts to fail if I try launching those programs with a 512K emulated in Snow, Finder 4.1, using its 64k ROM file. I get a mac bomb ID=02.

I've tried:

-using the "Old MacTraps" library instead of "Mac Traps"
-lowering the partition memory used to 256K
-forcing the compiler settings to use 1-byte alignment for structs

None of those move the needle.
Do you absolutely have to use something like THINK C 3 or 4 to get there?

edit - Finder 4.1 under a Plus is able to launch my program, so it's not a Finder/System issue.

I bring you: MacBaby! A full-speed (0.7KIPs) Manchester Baby emulator (the world’s first stored program computer).

It’s written in THINK C 5 and runs on a Mac 128kB and 512kB Mac down to System 1.

At least one of the downloads should include the source code!

https://68kmla.org/bb/threads/macbaby-an-emulator-for-the-worlds-first-von-neumann-computer.49556/

 

[Mu0n]

That's a really cool project.

edit - I got THINK C going, but simply creating a THINK C 5 project with:

-MacTraps
-384K partition size
-adding the main .c source file, crossing my fingers it includes the tree of source file I made in the same directory as my Symantec C++ 6.0 project

It builds!
But it crashes under my dev environment (bus error) and crashes under Snow w/512K, still ID=02

 

[thecloud]

I also used THINK C 5 (or earlier) for my stuff that ran on early Macs. The ID=2 error is an address error, which means something is accessing a nil or odd memory address. The first thing I would look for is whether anything in your code calls a Toolbox function which is in the 128K ROM but not in the 64K ROM. That means you have to limit yourself to what's documented in Inside Macintosh I-III. Inside Macintosh IV is new 128K ROM material, while Inside Macintosh V has 256K ROM and 68020-related stuff.

You should definitely read this post by @David Cook as it lists a number of things to look out for when writing code for a 64K ROM Mac.

 

[Mu0n]

Oh, I bet it's related to the timing routines I'm using..

 

[David Cook]

forcing the compiler settings to use 1-byte alignment for structs

Not sure what that is, but it doesn't sound correct for a 68000. Short and long integers must be aligned to even bytes (2 byte) boundaries.

Try running with MacsBug installed and make sure your compiler is including MacsBug symbols. Then, instead of a bomb box, you'll be dropped into the section of code that caused the crash. If the crash occurs in the System or ROM, then you can list the stack to see which of your routines called it. I'm confident you'll find the answer quickly!

 

[Snial]

<snip> The ID=2 error is an address error, which means something is accessing a nil or odd memory address <snip>

<snip> -forcing the compiler settings to use 1-byte alignment for structs <snip>

So with 1 byte aligned structs:,

typedef struct {
    short iX;
    char iY;
}tBadAddress;

typedef struct {
    tBadAddress iOk;
    tBadAddress iBad;
}tBadInfo;

tBadInfo gBadInfo;

void BadFunc(void)
{
    gBadInfo.iBad.iX=0x1234; // Boom!
    gBadInfo.iOk.iX=0x1234; // Or Boom!
}

If iOk is aligned, iBad.iX won't be and if iBad is aligned, iOk won't be. Either way: address error.

 

[thecloud]

The thing that made me initially discount struct alignment issues is that his program runs ok on a Plus, which is also a 68000. The biggest salient difference is the 64K ROM vs. 128K ROM. He is running System 2.x/Finder 4.1 which is from 1985. As was pointed out in David's excellent post, there were no "unimplemented" traps until 1986. What is the behavior when the trap table doesn't contain some trap, because it isn't implemented in your machine's ROM?

 

[David Cook]

Good example @Snial.

Simply put, the 68000 processor can read single bytes at any address. But, the 68000 processor will crash if it tries to read 2-byte or 4-byte values at odd addresses. They 'fixed' this in the 68020 and later processors, which can read at odd addresses (although will be slower). Hence, the option in Think C if you know you aren't going to run on a 68000.