Login  •  Register


The time is now: Wed Jul 24, 2019 8:35 am

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 1 of 1 [ 12 posts ]
Print view Previous topic  |  Next topic
Author Message
PostPosted: Sat Jan 19, 2019 2:42 pm 
Offline
Space Cadet

Joined: Sat Jan 12, 2019 3:03 pm
Posts: 6
Hi,

I got my little project to a milestone that it can actually run something more than a Hello World so I thought I'd start a thread here.

Woolshed is a naive attempt to write an API compatible runtime and PPC user mode CPU emulator for Classic MacOS applications running on modern operating systems. I'm personally interested to run as many games as possible on it if it ever gets far enough to run even one. I started it just a few weeks ago (around a week before the first public commit).

The project name is naturally a pun of a pun (SheepShaver) that I inherited the CPU emulation code from.

I know the code is still in quite rough shape but it's slowly getting cleaned up as I go along refactoring. There's still a lot of hacks around but they are getting cleaned up when they start failing.

https://github.com/hifi/woolshed

Here's the SillyBalls example application from Macintosh Programmer's Workshop running on 64-bit Linux:

Image

Disclaimer: I'm not a current or previous Mac user or have any idea what I'm doing.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Jan 20, 2019 5:40 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2646
Location: Emaculation.com
That's really quite impressive, especially with no MacOS programming experience! The trickiest bits are still to come, but if you've made it this far already, please keep going! Hopefully some on here like Paul Pratt and Kanjitalk755 (and me to a minor extent) can help you out when you run up against the toolbox. SheepShaver works by patching into that and using the toolbox as implemented in the ROM file and patched in the System file, swapping out toolbox routines for modern system handlers as appropriate. So it has a few built-in recipes for where you're going to need to start implementing your own call library, but there's a bunch that's not handled at all.

You might also want a copy of Ardi's Executor, as that has a full clean-room implementation of the System 7.0 toolbox for x86.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Jan 20, 2019 6:36 am 
Offline
Space Cadet

Joined: Sat Jan 12, 2019 3:03 pm
Posts: 6
Thank you for the support!

Could you please elaborate about the toolbox and ROM? As far as I've understood the binaries I've been loading and the disassembly I've been reading that the applications don't have more entry points to the system than the libraries it loads (no syscalls) and I'm implementing that API in a compatible manner by converting the PPC calling convention manually into host native. Like Wine with CPU emulation and calling convention conversion.

So in my naive attempt at this point I'm just thinking about implementing all of the required API for some simple games to run as-is.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Jan 21, 2019 7:05 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2646
Location: Emaculation.com
So on Classic Macs, a sizeable chunk of interacting with the hardware (including the APIs for drawing to the display, audio output, etc.) is coded into a ROM on the motherboard. The hard drive then has a partition that indicates where on disk a file is located that will hook into that ROM providing the rest of the code required to load up an entire operating system - the System file. This file also includes direct patches to the Toolbox stored on the ROM (the APIs and ABIs) that loads into memory, such that the new or updated routines get run from memory instead of from ROM.

On top of all this sit any compiled applications, which when loaded will immediately use some of the more basic toolbox calls, such as loading QuickDraw to handle drawing to screen, managing video RAM, compositing window and menubar elements, etc.

The list of Toolbox elements changed over time, first from the original Macs through System 7 when more of the toolbox was offloaded from the ROM to the System file, and then in the transition from M68k calls to PPC. When OS 9 replaced 8.6, Apple was pushing to isolate the hardware-dependent parts of the toolbox and related libraries from the logic-specific parts, and created a core set of calls they called "Carbon" that could be easily virtualized and used in the upcoming OS X environment as well as in the classic OS. These were handled via CarbonLib, and software compiled against that ran on both classic Mac OS and OS X, as all the toolbox calls inside were directly translatable to OS X APIs.

OS X also came with a second native target, Cocoa, which was an extended set of libraries that talked directly to the xnu kernel and was based off of the libraries developed for NextStep. This all ran on top of a core POSIX runtime based loosely off of FreeBSD and NextStep.


The go-to place to look up all the toolbox information for classic Macs is Inside Macintosh: https://developer.apple.com/library/arc ... ntials.pdf

Much of that is from a functional programming perspective, but there's good details from a Toolbox handling perspective in there as well.

A good outline of what I wrote above is here: https://en.wikipedia.org/wiki/Macintosh_Toolbox


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Jan 22, 2019 5:30 am 
Offline
Apple Corer

Joined: Sun Feb 01, 2009 4:55 pm
Posts: 266
Keep in mind, while this old PPC emulation code is good enough for a lot of older games, there are also quite a few that want the FPU to function. Still, this is a good start and I hope more people join in. There's plenty of documentation for how the libraries work, but there should also be some people chipping in to help get these games running.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Jan 22, 2019 9:32 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2646
Location: Emaculation.com
Oh, and one other thing I forgot to mention: the Carbon framework that allows single-build applications that will run on Classic and OS X started being deprecated as of 10.8, with more significant deprecations in 10.11 and 10.12.

Most of Carbon will still work as of 10.14, but it's 32-bits only, so the writing is on the wall; as soon as OS X starts rejecting 32-bit library calls, anything depending on Carbon will break. Still, it's pretty impressive that for the most part, a lot of code compiled against Mac OS 8.6 in 1999 will run properly in OS X 10.5 (PPC) and with woolshed should theoretically still run in OS X 10.14 in 2019, a full 20 years and a full OS and 2 CPU architecture changes later.

I'm guessing that what we'll need to do to make Woolshed future-proof is to re-implement CarbonLib, potentially mapping it to SDL2 as a compatibility layer, allowing for 32-bit calls inside a 64-bit call space.

Interestingly, this may also be similar to what we'll soon need to run software compiled against 32-bit 10.6, just without the instruction translation.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Jan 22, 2019 10:02 pm 
Offline
Master Emulator

Joined: Fri Sep 17, 2004 4:22 am
Posts: 343
Neat. Do you have a particular target in mind? A few years ago I would have suggested Pegasus Prime, but there's a Windows-friendly variant legally available these days. And I might suggest Chu-Teng, but it seems an English version for Windows is also well on its way.

3D accelerated games that can't be emulated in Sheepshaver would be something, but I doubt that would be easy to code for.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Jan 23, 2019 4:27 am 
Offline
Space Cadet

Joined: Sat Jan 12, 2019 3:03 pm
Posts: 6
I'm starting with the Macintosh Programmer's Workshop example applications because their source is included and I can compile them and compare the runs between a real MacOS and Woolshed.

It'd be useful to have a bunch of freeware titles that weren't "library heavy" and continue to those. I'm hitting the menu bar now and am wondering what approach should be used, external GTK/Qt/whatnot toolkits or use some SDL2 in-window ones. Host native look would be neat in my opinion.

Making sure the libraries would run without PPC emulation is probably a good idea. Adding another call layer between the calling convention switch would be one but then some of the data mangling inside functions may do endianess conversion so that can't probably be completely hidden away at this point.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Jan 23, 2019 6:38 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2646
Location: Emaculation.com
hifi wrote:
Making sure the libraries would run without PPC emulation is probably a good idea. Adding another call layer between the calling convention switch would be one but then some of the data mangling inside functions may do endianess conversion so that can't probably be completely hidden away at this point.


Yes; added to this is the issue I pointed out of 32-64-bit conversion, which is going to become more of an issue going forward (although not as much on Linux yet).

Personally, I've always had a soft spot for Qt from the host integration standpoint. However, SDL2 would be much simpler to integrate. Maybe support both as options?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Jan 27, 2019 7:48 am 
Offline
Space Cadet

Joined: Sat Jan 12, 2019 3:03 pm
Posts: 6
Qt5 seems like the way to go. It can draw most 2D primitives directly and it indeed has host native look. I've replaced all 2D drawing with Qt5 and removed SDL2 completely. Going to focus on getting basic resource fork loading working because pretty much all applications that do anything store and load data from it.

In the long run I probably want to refactor all of the code to use Qt data types et al.

Next I want to see some Alert() dialogs with proper content and buttons from the resource fork.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Jan 28, 2019 8:45 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2646
Location: Emaculation.com
Resource fork loading will be interesting: you'll probably have to support by-filesystem (so named forks for HFS/HFS+/AFS, alternate data streams for NTFS), and appledouble/applesingle encoding for filesystem-agnostic fork read/writes.

If you're going purely Qt5, you'll miss out on a lot of the heavy lifting that SDL can do with video/audio integration, etc. But then, if you're planning to do a strict primitive mapping, that may not really matter anyway.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Mar 19, 2019 2:57 pm 
Offline
Space Cadet

Joined: Tue Mar 19, 2019 2:52 pm
Posts: 1
Wow! This brought back memories.
Hopefully enough to be of use.

I used to program using MPW Shell, and later CodeWarrior and XCode.
Started with System 5.

Still developing on OSX and iOS.
I'll try to keep an eye on this thread and help, if I can


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 1 of 1 [ 12 posts ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group