My Retro68 notes...



Welcome, Guest \| Home \| Search \| Login \| Register


Author	My Retro68 notes... (Read 72443 times)
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #15 on: January 19, 2025, 00:14 Was able to build SillyBalls, which is an early example from Apple. There aren't clear (any?) instructions on setting up a new "project" (not an IDE project, but the Makefiles, etc), so I just took the "Dialog" sample, and replaced the .c file! It comes with a clever tool called "LauchAPPL" which can launch a built app, natively if you are on MacOS X (in Classic), remotely in a couple quite obscure ways, or using either MiniVMac or Executor (a very rare Mac "emulator"). There doesn't seem to be a MiniVMac package for the Ubuntu variation I'm using ("Mint" actually), but was easily built using https://github.com/minivmac (modern browser) Setting up LauchAPPL to actually use minivmac was a pain, and it requires the disk image from here https://www.gryphel.com/c/minivmac/extras/autoquit/ (modern...blah...) Also was able to use the created disk image in Basilisk on Linux (for which there WAS a package). But, yes, got SillyBalls to build and run, was not "fun". Building anything that is more than just a single .c file will require figuring out Retro68's use of CMake, and creating CMakefiles for it(?)...which doesn't seem documented. So, it is true, you CAN build System 6 apps on Linux...but it is not for the faint of heart.
Last Edit: January 19, 2025, 00:16 by lauland
ShinobiKenobi 256 MB Posts: 362 System 7 fan	Reply #16 on: January 19, 2025, 04:30 Thanks for this awesome info!!! It's really appreciated! Especially as I just embarked on my own 68K journey

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #17 on: January 19, 2025, 17:25 After further thought, I actually AM going to give it a try building this beast under Tiger PPC. Reasons: The author specifically mentions it works, I can see in the LaunchAPPL config a lot about using it with MacOS X's Classic. So it has a good chance of working. "TigerBrew" is not the same thing as "HomeBrew". It is a separate project, and, obviously, supports older machines and OS's. So actually has a better chance of working, and having the right dependencies, than using HomeBrew on an older Intel Mac. I've got the dual G4 1.6 ghz I used to build Classilla on. It is technically not as fast as my 2 ghz Intel Mac, but gcc takes full support of multiple cores/cpus. Building Retro68 on it may actually be a lot faster than doing so in a VirtualBox VM on Intel. Besides, I've already figured out the pain points, and so know what to expect, what can go wrong and when, and how to get around things.

Knezzen Administrator 512 MB Posts: 608 Village idiot	Reply #18 on: January 21, 2025, 10:54 Great notes, lauland. I want to get back to Retro68 again. It has been a few years since I gave it a go the last time and I can't remember how many potholes I drove into, but there was at least one

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #19 on: January 21, 2025, 15:51 (@Knezzen, I've probably ran into some the very same potholes...got over most, but still stuck in a few!) Here's some (more) excruciating details and explanations of the process, and what bits are involved... Basically it's a two step process: First, you need to have the dependencies, which are a few libraries and tools. On Linux, these are all standard parts of the "distro's repos" so this is trivial. On a Mac, you need to install "Homebrew" if you are on Intel or Apple Silicon. If on PPC, there is a separate "Experiemental Fork" (by different people) called "TigerBrew" (which also supports Leopard). If you are running a recent version of MacOS X, Homebrew SHOULD be easy to set up and use. I had no problems on my M2 Mac. I've kept an older version of MacOS X on my Intel Mac, just so I could continue to run 32-bit binaries...and things haven't gone as smoothly there, with conflicts between the versions of the libraries Homebrew supplies for that older OS, and Apple's dev tools and libs. I haven't installed TigerBrew on my PPC mac yet. It may surprisingly go smoother than Homebrew on older Intel OS's. This is because the HomeBrew maintainers are focused on recent OS's primarily, and tend to neglect older ones, especially when you are several versions behind like I am. TigerBrew (by different people) is specifically for old versions of PPC MacOS X, so what it supplies may end up being better maintained, ironically. ---- The dependencies are: cmake gmp mpfr libmpc boost bison flex texinfo ruby cmake is a modern tool to build programs, it works along with the traditional "make". ruby is a language roughly similar to Python, a little less popular and not as well known. texinfo is a tool used to create documentation, similar to html, but far older. flex and bison are tools used to create compilers. The remaining ones are libraries, mostly dealing with math. So these are what you would get from Homebrew/TigerBrew. (And trivial on Linux). ---- The second step of the process is building it. For this part, you go off and leave your computer and hope for the best. If you're lucky, it builds: * The compilers themselves. * Special mac-specific runtime and libraries supplied by Retro68. * The "standard libraries", these use the math libs above. * Many special mac related tools, like LaunchAPPL, supplied by Retro68. * And finally, it builds several Sample programs for m68k, ppc and carbon. Any problems you'll run into will usually be with the "standard libraries", or the mac related tools. At least that's my experience. Once you've actually got Retro68 built, you must be very familiar with the command line to use it. You must know how to use cmake, which I don't (yet), to be able to create new projects. ---- https://brew.sh/ (modern browser) I've mentioned it before, but Homebrew is both a package manager and a very large collection of open source software, patched or otherwise known to build for MacOS X, primarily command line, but many with gui's also. If it's a unix-y open source thing, it has a very good chance of being in there, but Homebrew itself is not terribly user friendly. Here's an example of asking it for info about a randomly picked game: lauland@localhost ~ % brew info pokemon-trading-card-game-online ==> pokemon-trading-card-game-online: 2.95.0.5815 https://www.pokemon.com/us/pokemon-tcg/play-online/ Disabled because it is no longer available upstream! It was disabled on 2024-07-07. Not installed From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/p/pokemon-trading-card-game-online.rb ==> Name Pokemon Trading Card Game Online ==> Description Play the Pokemon TCG online ==> Artifacts Pokemon Trading Card Game Online.app (App) ==> Caveats pokemon-trading-card-game-online is built for Intel macOS and so requires Rosetta 2 to be installed. You can install Rosetta 2 with: softwareupdate --install-rosetta --agree-to-license Note that it is very difficult to remove Rosetta 2 once it is installed. ==> Analytics install: 0 (30 days), 0 (90 days), 14 (365 days) You need to be a little comfortable with the command line to set HomeBrew up and use it to install things, but if you're on a recent MacOS X, once you've done that, it's not too hard to use. If you're on an older OS like my Intel Mac, even getting Homebrew itself installed may be a bit painful. (The older the worse). Depending on which open source package you use it to install, they may already be pre-built binaries available, which go very quickly and smoothly. If the package is "less popular" or "older" or you aren't on a very recent version of MacOS X, Homebrew actually downloads the source code and builds it on your machine right before your eyes. If it has to build the package, this takes time, and things can go wrong. If they do, and you're on an older OS, you get a messsage to not bother the Homebrew maintainers as they don't support that! ---- I expect TigerBrew to just be a variation of Homebrew, but the maintainers more friendly to old OS's. The collection of packages it can be used to install will likely be MUCH smaller than through Homebrew. Not only because the TigerBrew people won't have as much time to test which ones build on PPC, but, because there's less demand, less packages will have been patched, etc, for PPC and the old OS's it runs. Since the Retro68 guy specifically mentions uses it, using it to install the required dependencies may go smoothy.
Last Edit: January 21, 2025, 16:22 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #20 on: March 16, 2025, 05:25 FINALLY starting to understand how to use how the included CMake files are used to build the sample programs...and should be able to set up building apps using it from scratch soon. Basically you'll copy one of the sample's CMakeFiles.txt file, and edit it to specify the files of your "project" (all the .c, .h, .r ones, etc). Then you can use cmake to generate a Makefile, and just run "make" as expected. This is relatively simple, even though it is all command line, and roughly analogous to setting up a project in CodeWarrior or Think/Symantec. It is also very similar to how MPW Makefiles create a file of MPW commands, even if the contents are WILDLY different. ---- All that is well and good, if you're creating a project from scratch, but, if you're trying to build something that already has a Makefile (like, for example, one of my SDL game ports), you are completely S.O.L. It is forcing you to create a new Makefile, and you can't use the existing one in any way. So, I've been looking at how to use the compiler without cmake, by "reverse engineering" the cmake generated Makefiles. (And use it via "m68k-apple-macos-gcc" and "ppc-apple-macos-gcc"). I wasted a LOT of time thinking there were some "magic commands" it used to convert between Linux gcc file formats and traditional resource based Mac ones. But it turns out all the "magic" is hidden, and based on the extension of the filenames...it will silently use different formats just based on the names. So, by default it creates ELF binary files, just like gcc typically does on Linux and other platforms, .o for the objects, and ".gdb" for the executables. BUT...if you use the the "-o" compiler flag and specify a filename ending in ".bin" macbinary versions of the files are automatically created. Doing so for an executable creates an entire macbinary'ed mac application, using the correct format ("CODE" resources for m68k, and code fragments for ppc). It never (directly) uses "naked" split forks, ie having the data fork as one file, and the resource fork in another, which would then be combined. ---- There is ONE "magic command", which is "Rez" which works very similarly (almost identically) to the same command in MPW or MacOS X, being the resource compiler, which takes .r files. BUT...as a bonus, by passing extra filenames with "-cc", it can create disk images and your application in MANY different formats. Like the "-o" file above, the different formats are chosen automatically by the filename extension...so "-cc myapp.dsk" creates a disk image, etc etc. This disk image can be used directly in Basilisk, or even launched in MVM with a single "LaunchAPPL" command.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #21 on: March 20, 2025, 03:57 Ok...I think everything I said above about filename extensions was completely wrong! It does NOT look at the extension and decide the format automatically AT ALL. My previous try was just with the m68k version of the compiler, and it does, indeed produce macbinary, because the code needs to be "CODE" resources...but it ALWAYS does this as the executable format. Object files (ie .o) are always ELF, which is the same as m68k Linux. Trying the same experiments with the powerpc version of the compiler, instead (also) always just uses the same format, a.out, but not ELF, which I'd instead expected, as that is what powerpc Linux typically uses. Regardless, it does this because the code format is more closely related to code fragments. Anyway, the final step uses the Rez command...I'm not sure how it works yet for powerpc, but for m68k, it copies the CODE resources into the final Mac Application, in macbinary format. So...progress...

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #22 on: March 23, 2025, 06:36 Well, at least one mystery solved. I wasn't wrong about the file extensions completely. It does behave as I described, but only for the linking phase and only for m68k. So, for example "powerpc-apple-macos-gcc -ohello helloc" will produce just a "hello" file, which is an a.out format file. This, I believe is in XCOFF format, which can be converted relatively easily to the standard powerpc PEF format. "m68k-apple-macos-gcc -ohello hello.c" will produce "hello.gdb" which is an ELF binary. This is not directly usable in any way that I can tell, at least not easily converted to an actual Mac Application. But..."m68k-apple-macos-gcc -ohello.bin hello.c" (note the key ".bin") will produce "hello.bin.gdb" which is the same as "hello.gdb" above, but ALSO produce "hello.bin", which is a MacBinary encoded file that contains the "CODE" resource! To get an actual Mac Application you need to use the Rez command. For m68k, this will involve copying the "CODE" resource .bin file, but for powerpc, you copy the a.out format file to the data fork. The Rez command's output is also MacBinary, and allows you to set the creator code and the file type to "APPL" as needed for an Application. (As mentioned before, Rez can also optionally create a disk image and other extremely useful files at the same time). I'm still figuring out the proper way to do this final Rez step, using a standard Makefile, as opposed to the VERY complex cmake way the Retro68 author seems to prefer. This is key for making Retro68 versions of any of the SDL game ports I've gotten working with CodeWarrior. This is so I can use the original Makefiles (that they come with), the same used to build them for Linux and Amiga, etc. (As opposed to setting up cmake JUST for Retro68, which'd be a pain).
Last Edit: March 23, 2025, 06:38 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #23 on: March 24, 2025, 03:08 Got my own code building for m68k with Retro68...in a standard Makefile just needed to change the exe file output to have .code.bin at the end, and then add this step: Rez -I/home/lauland/Retro68-build/toolchain/m68k-apple-macos/RIncludes resources.r --copy $@.code.bin -t "APPL" -c "?" -o $@.bin --cc $@.APPL --cc $@.dsk The produces an Application.APPL, a macbinary version with .bin, and a disk image .dsk. Then I copied the folder from "Unix" in Basilisk to Macintosh HD, and was able to run the .APPL files which are applications, didn't even need to use the disk images. This was a pleasant surprise...not entirely sure how the resource forks "just worked", but they did. So, the next step is to figure out building for powerpc. I'm pretty sure it will be changing "--copy" to "--data" to copy the a.out file as the data fork, which should be legit. The trick will be, I believe, powerpc apps need a "cfrg" resource that describes the code fragments. On the other hand, if that is missing, MacOS might just assume that the entire data fork is a single code frag and will "just work". Building SDL programs "worked" but the result doesn't do anything...but I'll talk about that in the SDL thread...

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #24 on: March 29, 2025, 03:05 Turns out building powerpc apps requires an additional step compared to m68k ones. XCOFF is closely related to PEF, but a PEF header is needed, so instead of using "-o WHATEVEVER.code.bin" for the executable, you use "-o WHATEVER.xcoff" and then have lines like these two: MakePEF $@.xcoff -o $@.pef Rez -I$(RINC) $(RFILES) --data $@.pef -t "APPL" -c "?" -o $@.bin --cc $@.APPL --cc $@.dsk (NOTE: that is four question marks in a row for the creator code) MakePEF takes an XCOFF and converts to a PEF. It is a tiny bit buggy and you must have a space between the name and "-o", which isn't required by many commands (such as gcc, etc). In my makefiles, I use slightly different values for RINC and RFILES depending on the cpu, as follows: RINC=/home/lauland/Retro68-build/toolchain/m68k-apple-macos/RIncludes RFILES=$(RINC)/Retro68APPL.r vs RINC=/home/lauland/Retro68-build/toolchain/powerpc-apple-macos/RIncludes RFILES=$(RINC)/RetroPPCAPPL.r Using RetroPPCAPPL.r is VERY important, because it includes the "cfrg" resource needed by standard powerpc apps. So now I was able to build either m68k or powerpc apps. Retro68 ALSO can build Carbon apps, but I haven't looked into that yet. ---- So I next looked into building Retro68 on my G4 using TigerBrew, that way I'd be able to run any apps built with it directly, instead of having to use Basilisk or SheepShaver. The Retro68 author states this works...long story short: It does NOT. Long story slightly longer: There were reports of people being able to do so (sometimes with minor workaround-able problems) in 2018 and 2019. That may have been the case back then, but, following the instructions exactly doesn't work in 2025. binutils and gcc for both cpus DOES build, but the final step, where tools like MakePEF, Rez, and many more, does not. It fails due to library issues, specifically with the "boost" family of libs. The problem has been reported by someone else in Retro68's github, and the author tracked it down to boost not being new enough. This probably has happened because Retro68 has been updated to require the newer version since 2018/2019. I have been building Retro68 using the master branch, but had the clever idea to try using a branch from 2019. Long story short, this ALSO didn't work. This might have worked, my guess is it doesn't because the dependent packages in TigerBrew have probably been upgraded since 2018/2019. I'm pretty much positive this is the case since some of the reports of people being able to build with TigerBrew mention using an older version of CMake than it currently has. So, what MIGHT work would be to use the 2019 branch of Retro68, with the OLDER TigerBrew packages. This would require figuring out not only ALL the correct versions of the dependent packages, but the dependencies for those themselves, so not easy at all. (And getting TigerBrew to ONLY install ALL those old versions, by hand). This'd be a real pain, so I'm not likely to look into it.
Last Edit: March 29, 2025, 03:09 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #25 on: March 29, 2025, 09:50 sigh... That TigerBrew + Retro68 situation is really upsetting, but far too common an issue with package managers when working with anything non-latest... I really hate how this is a thing. If by ANY chance, anyone can successfully get a Retro68 setup on PPC OS X, any version, that alone would deserve being imaged and shared on MG so that no one else has to EVER go through this. Inaccurate/Incomplete documentation for setup can be REALLY infuriating. Way too common with just about anything UNIX-y, for some really weird and silly reason. At the very least... Retro68 itself still works somewhere. (By the way, keep up with the findings! I'm always at the edge of my seat when catching up to your exploits! I'm glad to see PPC targeting is now also mostly figured out. Carbon can be a plus someday, too, but that can wait.)

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #26 on: April 13, 2025, 03:39 @Jatoba, I uploaded "SDL-1.2-main-lauland.sit" to the s7t hotline. It includes the fixes to build it with Retro68. Very minor: * Disables my AppleEvent stuff in main if not building on CodeWarrior. This hangs with the Retro68 runtime for some reason. I think I know why and will fix it someday. * Had to add a cast to a particular string in main for Retro68. * Retro68 doesn't have "#ifdef powerc", so I had to use "#ifdef __ppc__" in SDL_config_macos.h * Disabled OpenGL on Retro68. It probably actually works, but I haven't tested it yet. * Added Makefile.r68 and Makefile.r68ppc to build with Retro68. Use Makefile.r68 for m68k and Makefile.r68ppc for ppc. First (same for both cpus): make -fMakefile.r68 clean Then: make -fMakefile.r68 This will create libSDL.a, which is a static lib. ---- It will be possible to build a shared version, but I haven't figured out how you build them with Retro68. It'll include adding a section to the Makefile for a "libSDL.so". It will also be possible to build CFM-68k at some point, but also haven't even tried yet. Finally, Retro68 supports Carbon, but again, haven't even looked at it yet. ---- FYI Ignore "SDL-1.2-main-20250412.sit", it was a mistake. It is missing the Finder file types and creators.
Last Edit: April 13, 2025, 03:41 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #27 on: April 21, 2025, 19:02 Just a note that in the build for MacOS X the utilities that deal with resource forks don't include all their features, namely "Rez" is missing many of the functions that it does on Linux. So, if you're going to try Retro68 out, I strongly suggest you do so on Linux. I'm going to look into uploading the Tiger build I got partially done to MG. I was unable to get the tools dealing with resource forks to build without errors, but everything else was ok. This will save others who might be interested LOTS of time. Without the tools for resource forks, you still have the compilers and linkers. It is probably possible to get around this and still build runable apps, but I haven't figured it out, or even much looked into it, yet (since it runs so well on Linux). Maybe something as goofy as using ResEdit to put the resources in by hand?

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #28 on: April 29, 2025, 04:30 I have a particular (peculiar?) bad mental habit. Sometimes when I'm looking for something, I will look for it in all the places where I expect it to be, which makes sense. But if it's not where I expect it, it can be RIGHT under my nose and I won't be able to see it, my eyeballs will glide right past it. It might as well be invisible, because it isn't where I EXPECT it to be. This happens with things like keys or glasses, etc, but also with ideas... Such was the case with the missing "tools for resource forks" for Retro68 for PowerPC Macs, embarrassingly so. Duh. If you're on MacOS X, you don't need them! You don't need the version of Rez that comes with Retro68, because you can just use Apple's native one! It also doesn't matter if Retro68 doesn't finish building all its libs and headers...you can just copy them from a Linux build of Retro68! The .a files are specific to the arch you're BUILDING for, not the host, and the headers are just text files. Thus I was able to build the MacOS 9 SDL2 and all its test apps on my G4 running Tiger, and am joyfully watching 100 smiley faces bouncing around. All under PPC MacOS X, with zero Linux involved. This means you can't use the exact same Makefiles for building Mac Apps on Linux vs on MacOS X, as the resource steps are different. But, let's face it, if you're using Retro68 to build Mac Apps, you really should have a good understanding of resource forks. So, here's the key, use /Developer/Tools/Rez and friends, and you probably should use Apple's .r files too. Another cool trick is you can just copy the resource fork directly by doing something like "cp rfork myapp/rsrc" (ie treat your app as if it were a folder and the resource fork as if it were a file called "rsrc"). I'm going to copy my build of Retro68 for Tiger and my TigerBrew with all the Retro68 dependencies pre-built up to MG soon, which will be a turnkey development environment and save hours and hours of pain for anyone wanting to use Retro68 on their PPC Tiger machines.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #29 on: April 29, 2025, 23:36 Wow, Lauland..when you do upload it, that'll be a real Classic Mac programming lifesaver for sure!!

	Pages: 1 [2] 3

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.