GCC-based cross compiler for 68K Macs

[autc04]

Hello everyone

If you're like me, then you've been frustrated that THINK C++ 7.0 doesn't support all the newest features from the C++11 standard.

Well, you probably aren't.

But anyway, I've managed to get the GNU C/C++ Compiler (version 4.7) to cross-compile from modern day Linux or Mac OS X to System 6:

https://github.com/autc04/Retro68

So, I hope that people will soon start writing new software for my old Mac SE

 

[cb88]

Cool Its good to hear you are still working on this! I'm in the process of getting a copy of CodeWarrior Pro 4.. but the more the merrier.  I it would be interesting to compare the code both generate.

What are the chances of porting gcc itself to say a 68030 mac with plenty ram perhaps things like MacRelix have enough of a compatiblity layer to work?

 

[Elfen]

Hello everyone

If you're like me, then you've been frustrated that THINK C++ 7.0 doesn't support all the newest features from the C++11 standard.

Well, you probably aren't.

But anyway, I've managed to get the GNU C/C++ Compiler (version 4.7) to cross-compile from modern day Linux or Mac OS X to System 6:

https://github.com/autc04/Retro68

So, I hope that people will soon start writing new software for my old Mac SE

That's nice and all but you will still need a resource Editor (ResEdit is good start) to create your resources and then a way to tie your resource forks with your data/program forks which are needed to create an app for systems .97 to OS 9.2.2.

Programming on Mac was never easy.

 

[johnklos]

Very, very cool!

Question: Is Haskell used for anything except PrepareHeaders.hs? Also, is Haskell needed after it is used to prepare the headers? It's a tremendous dependency, and it'd be nice if I could run a VM just for Haskell, then dispose of it when I'm done.

 

[autc04]

Haskell:

Yes, the dependency on GHC is just for PrepareHeaders.hs. Once the headers are generated, it's no longer needed.

I realize it's a big dependency, but Haskell is very well suited for the task of hacking up a parser quickly (as opposed to using perl and a big heap of regular expressions that will probably never work right...).

Resource Forks:

The MakeAPPL tool creates the resources that are mandatory, and it could theoretically be extended to include a proper Rez-style resource compiler in the future. Let's say that for now you should probably be using NewWindow instead of GetNewWindow.

 

[rickyzhang]

Very cool stuff.

I used to have trouble in finding the proper development tool. After reading some old mac magazine, I figured out that the easiest way to get the tool set is to get a Apple E.T.O CD. It got MPW, Mac App, MacBugs, SADE and detailed documentation. Everything that you can dream of...

 

[3583Bytes]

Very cool, great job

 

[LOOM]

Is it possible to make a stand alone project/a Makefile that compiles using the toolchain as an example I can build upon? Because the examples in the build folder have been auto generated by cmake, so I'm not sure how that work. I managed to almost fix one by looking at c-streams and Retro68Test, but it seems like they have problems finding the Rez data.

 

[mactjaap]

I would like to add on LOOM his request if it is possible to make a "Hello World" example how make a real Macintosh application of a piece of example C code (like Hello World). This would make it also possible for less talented programmers or starters to develop a classic Macintosh app.

Compilation in gcc is doable for most of us, but how to run it on your Macintosh?

What to do with ResEdit for example?

 

[LOOM]

I tried following this Code68k tutorial I've used before that works using Codewarrior, but I end up with the same error as when I'm trying to compile the retro68Test project. I'm not sure if it's the Retro68Test Makefile that is the problem, or if it's a toolchain bug:

$ make

/retro68-build/toolchain/bin/MakeAPPL -c Retro68Test.68k -o Retro68Test -n -t ALRT  -n -r 129 rsrc/ALRT/129.dat  -n -t DITL  -n -r 129 rsrc/DITL/129.dat  -n -t MBAR  -n -r 128 rsrc/MBAR/128.dat  -n -t MENU  -n -r 128 rsrc/MENU/128.dat  -n -r 129 rsrc/MENU/129.dat  -n -r 130 rsrc/MENU/130.dat  -n -t vers  -n -r 1 rsrc/vers/1.dat
​unrecognized flag
​make: *** [Retro68Test.dsk] Error 1

It seems like it adds some stuff from "rsrc-args" in the Makefile that shouldn't be there (see error above). If I comment it out the program will compile but crash when I run it.
c-streams (another project using the toolchain) is using another Makefile, but gives out errors when linking StreamTest: stream.c.text+0x174): undefined reference to `alertf'
 
That's why it should be nice to see a standalone Hello World-project with a simple Makefile we know works, to rule out our own bugs 
 
Edit; I can't get the Code tag to work.

 

[michaelengel]

I tried following this Code68k tutorial I've used before that works using Codewarrior, but I end up with the same error as when I'm trying to compile the retro68Test project. I'm not sure if it's the Retro68Test Makefile that is the problem, or if it's a toolchain bug:

Hmm, the code is not quoted, strange. The problem seems to be with your version of "echo" (which might be an internal function of your shell). The makefile uses "echo -n" to suppress newlines:

        echo -n "-t $code "; \

        cd "$code" && for file in *.dat; do \            echo -n "-r ${file%.dat} rsrc/$code/$file "; \

Your version of echo does not support this option, so it echoes "-n" as text, which is prepended to all "-t" and "-r" command line parameters.

Edit: also can't get the code tag to work...

 

[LOOM]

I'm on OS X so it seems like the Makefile wanted to run another 'echo' (maybe from the toolchain?), because when I changed 'echo' to '/bin/echo' in the Makefile it compiled successfully (and ran fine in BasiliskII). Thanks!

 

[autc04]

I've opened an issue (#16) on github so I don't forget about the "Simple Example" request. No time right now, though.

And as far as resources are concerned, I had a little free time a few months ago that I used for reimplementing (parts of) the Rez compiler. It's buggy, has various missing features and it prefers crashing over reporting an error if it's given incorrect input, but it can compile .r files.

 

[michaelengel]

And as far as resources are concerned, I had a little free time a few months ago that I used for reimplementing (parts of) the Rez compiler. It's buggy, has various missing features and it prefers crashing over reporting an error if it's given incorrect input, but it can compile .r files.

Are you aware of the fact that the ancient SUMACC cross-compiler tools from Stanford include a resource compiler called "rmaker"? The SUMACC code can be found in the 4.3BSD "new.tar.gz" fileset at http://www.tuhs.org/Archive/4BSD/Distributions/4.3BSD/

Building the cross-compiler itself on OS X fails due to ancient K&R C code, after fixing the compiler errors, the compiler continues to crash. It works fine when compiling on 4.3BSD in the simh VAX emulator. However, rmaker seems to work fine on OS X - but I don't know how useful it is, considering it was last updated in 1984.

 

[autc04]

Are you aware of the fact that the ancient SUMACC cross-compiler tools from Stanford include a resource compiler called "rmaker"?

No, I wasn't aware of SUMACC. It was before my time. Very interesting stuff. I don't think it can compete with good old THINK C though .

RMaker was available on the Mac, too, and was basically the predecessor of Rez, which was introduced a few years later with MPW. It's a much simpler tool that only supports a few standard resource types, while Rez is extensible (and has a nicer syntax).

 

[LOOM]

Being able to add the rsrc file directly into the project without DeRez+unrez would be amazing 

 

[salgernon]

I've never really been a fan of ResEdit for production. I'd rather use Rez directly - which I think Apple still ships and should create compatible resource forks.