Snial
Well-known member
Near the beginning of my exploration for Mac Color Personal (I now prefer MacCP to MacPC 
), I considered how developers might develop on it. The biggest issue is how to run a suitable compiler on a Mac 512K. At the time, I was aware of Consulair C, but I had the feeling that it was a bit too primitive and therefore thought that an early THINK Lightspeed C would be the minimum, and it'd need 1MB, i.e. an expanded Mac CP.
More recently I've come across the MegaMax C compiler. There's a download for it on the Macintosh Garden. It's a really interesting compiler, a one pass 'C' compiler (and inline assembler) that fits in 96kB!!! It's still very primitive. It's probably most famous for the Asteroids clone Megaroids, which was written entirely in MegaMax C and is very playable!
The way it's designed to work is that you run the Editor and the Editor's file menu (note the non-standard lower case!) has some options to transfer to the compiler and linker. However, I found that when I tried to do that, it crashed and corrupted my project disk, so until I get around to seeing if that can be fixed, I just quit the editor and then run the compiler.
So, this is my main desktop when running MegaMax C under MFS System 3 (because the Mac ColorPersonal only has a 64kB ROM).
I have a list of the apps in one desktop window, so when I quit the editor I can choose another app. mmcc is the compiler itself, which produces .o files so you then need mmlink (just off the bottom of the window) to link an application. Most of the time MFS disks get in the way, because all the folders are fake and I'd forgotten how frustrating that can be. When you open a file, you see every single file on the disk and they all have to have different names, as do the folders. Then when you compile, it doesn't matter if your .c files are in a folder, they end up at the root of your project disk anyway. That's why you can see edit.o, Edit and parts of my other compiled files.
MegaMaxC supports the Macintosh Toolbox, but stupidly, they made all the Toolbox symbols (types, functions etc) lower-case. Also only the first 10 characters in an identifier count and really oddly,
And indeed it works too:
Also, the cursor is initialised properly to an arrow, which is recognisable on the colour screen. As before, with my palette setup we get green on the left and magenta on the right, because a single colour scanlines is 128 bytes, or 2 standard Mac 512K scanlines and the checkerboard pattern has 0x55 on even lines (Green) and 0xaa on odd lines (Magenta).
According to a book I was reading on the compiler, it can't handle programs bigger than 32kB. I think that's not true since at least 2 code segments get linked into a fairly standard program and they have individual names. This means the segment names are part of the object files and I guess it's possible to define your own segments then.
Finally, one of the real oddities about the MegaMax C compiler is that it has no make program and no project manager. Instead, large, multifile projects are handled using a batch language driven by the application batchX. Bizarre huh? But it makes a bit more sense once you know that MegaMax C was also available on the Atari ST, also within its 512kB limits and I guess the ST's MSDOS-like file system made batch processing a more natural tool (or maybe they developed it as a cross compiler on a PC first?).
Anyway, that's my foray into the world of 1985 Macintosh 'C' compilers. I'm not totally traumatised, so I count it as a win !
), I considered how developers might develop on it. The biggest issue is how to run a suitable compiler on a Mac 512K. At the time, I was aware of Consulair C, but I had the feeling that it was a bit too primitive and therefore thought that an early THINK Lightspeed C would be the minimum, and it'd need 1MB, i.e. an expanded Mac CP.More recently I've come across the MegaMax C compiler. There's a download for it on the Macintosh Garden. It's a really interesting compiler, a one pass 'C' compiler (and inline assembler) that fits in 96kB!!! It's still very primitive. It's probably most famous for the Asteroids clone Megaroids, which was written entirely in MegaMax C and is very playable!
The way it's designed to work is that you run the Editor and the Editor's file menu (note the non-standard lower case!) has some options to transfer to the compiler and linker. However, I found that when I tried to do that, it crashed and corrupted my project disk, so until I get around to seeing if that can be fixed, I just quit the editor and then run the compiler.
So, this is my main desktop when running MegaMax C under MFS System 3 (because the Mac ColorPersonal only has a 64kB ROM).
I have a list of the apps in one desktop window, so when I quit the editor I can choose another app. mmcc is the compiler itself, which produces .o files so you then need mmlink (just off the bottom of the window) to link an application. Most of the time MFS disks get in the way, because all the folders are fake and I'd forgotten how frustrating that can be. When you open a file, you see every single file on the disk and they all have to have different names, as do the folders. Then when you compile, it doesn't matter if your .c files are in a folder, they end up at the root of your project disk anyway. That's why you can see edit.o, Edit and parts of my other compiled files.
MegaMaxC supports the Macintosh Toolbox, but stupidly, they made all the Toolbox symbols (types, functions etc) lower-case. Also only the first 10 characters in an identifier count and really oddly,
short is 8-bit. Nevertheless, the initial colour palette demo is very similar to the THINK C version:
C:
#include <qd.h>
#include <misc.h>
#include <mem.h>
#include <res.h>
#include <win.h>
#include <control.h>
#include <event.h>
#include <qdvars.h>
#define kPalSize (16)
unsigned int gClrPal[kPalSize]={
0x000, 0x400, 0x080, 0x480,
0x008, 0x408, 0x088, 0x255,
0x4aa, 0x700, 0x0f0, 0x7f0,
0x00f, 0x70f, 0x0ff, 0x7ff
};
#define VidMdSet(aVal) *((unsigned int*)0xbffffa)=(aVal)
#define PalSet(aEntry, aColor) VidMdSet(0x8000|(aEntry<<11)|aColor)
#define MdeSet(aMode) VidMdSet(aMode)
rect gSrcRct;
windowrecord gMainWin;
windowptr gWin;
InitTlbx()
{
/*
Startup toolbox managers
*/
initgraf(&theport);
initfonts();
flushevents(everyevent, 0);
initwindows();
initcursor();
}
BtnWait()
{
while(button()) { /* wait for button up */
}
while(!button()) { /* wait for button */
}
}
main()
{
int ix;
InitTlbx();
/*
Initialize screen rectangle
*/
setrect( &gSrcRct, 4, 40, 256, 128);
/*
Create Initial window
*/
gWin = newwindow( &gMainWin, &gSrcRct, "Video", 1, 0,
(long)-1, 1, (long)0);
setport( gWin);
moveto(0,12);
drawstring("Click the button!");
BtnWait();
for(ix=15; ix>=0; ix--) {
PalSet(ix, gClrPal[ix]);
}
MdeSet(1); /* now we're in color mode */
BtnWait();
PalSet(0, 0x7ff);
PalSet(1, 0);
MdeSet(0); /* now we're in mono mode */
}And indeed it works too:
Also, the cursor is initialised properly to an arrow, which is recognisable on the colour screen. As before, with my palette setup we get green on the left and magenta on the right, because a single colour scanlines is 128 bytes, or 2 standard Mac 512K scanlines and the checkerboard pattern has 0x55 on even lines (Green) and 0xaa on odd lines (Magenta).
According to a book I was reading on the compiler, it can't handle programs bigger than 32kB. I think that's not true since at least 2 code segments get linked into a fairly standard program and they have individual names. This means the segment names are part of the object files and I guess it's possible to define your own segments then.
Finally, one of the real oddities about the MegaMax C compiler is that it has no make program and no project manager. Instead, large, multifile projects are handled using a batch language driven by the application batchX. Bizarre huh? But it makes a bit more sense once you know that MegaMax C was also available on the Atari ST, also within its 512kB limits and I guess the ST's MSDOS-like file system made batch processing a more natural tool (or maybe they developed it as a cross compiler on a PC first?).
Anyway, that's my foray into the world of 1985 Macintosh 'C' compilers. I'm not totally traumatised, so I count it as a win
!
