Executor: Reverse engineering Macintosh ROMs?

About Mini vMac and all other 68k emulators, including SoftMac, Executor, and MESS.

Moderators: Cat_7, Ronald P. Regensburg

Post Reply
User avatar
sentient06
Mac Mechanic
Posts: 188
Joined: Tue Mar 29, 2011 8:57 pm
Location: London, UK

Executor: Reverse engineering Macintosh ROMs?

Post by sentient06 »

I was researching the topic and I came to several references to ARDI's Executor.
As far as I understand, Executor only.. "translates" the binaries used by old macs, behaving, sort of, as if there were a ROM there.
However, I read some sites suggesting they actually reverse engineered a Mac ROM, or at least started doing it. Anyone knows more details?

It would be really cool to have a copyright-free ROM!
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Executor: Reverse engineering Macintosh ROMs?

Post by adespoton »

IIRC, they clean-room reverse engineered enough of the ROM to emulate the core functions of the Mac II-series ROM. I'm not sure if anything further was ever done.
Jorpho
Master Emulator
Posts: 380
Joined: Fri Sep 17, 2004 4:22 am

Re: Executor: Reverse engineering Macintosh ROMs?

Post by Jorpho »

As per the original FAQ:
[N]one of the Apple ROMs or Apple System File were ever disassembled. Instead ROMlib (the section of Executor that emulates the OS and Toolbox) was written from the manuals "Inside Macintosh", and Tech. notes. That isn't sufficient to get the degree of compatibility that we need, so tests were written and run on Macs to see what a real Mac would do. In addition, we run applications under Executor and when they deviate from how they would behave on a Mac, we take a look at what is going on and fix Executor accordingly.
Also amusing:
In other words (as one user sagely posted to the Executor newsgroup): "ARDI has had to figure out what's in the Mac ROMs without reverse-engineering them. Try to figure out how to copy a four-cylinder engine by throwing wadded-up Kleenex at the thing and seeing which way they get deflected, and you'll have an idea of how hard their job is."
(From http://www.stone.com/liesAndPropaganda/ ... /feat.html .)

I agree, a copyright-free ROM would be a triumph indeed. Someone mentioned in a thread a while ago that mini vMac already substitutes portions of its own code for routines in the ROM that handle hard disk access, so perhaps part of the job is already done there.

Remember Bleem!, one of the early commercial Playstation emulators? I forget the details (I might actually be thinking of Virtual Game Station), but I dimly recall they won a suit against Sony when they demonstrated that even though they had disassembled the Playstation BIOS ROM, they had purposefully re-implemented it in a different way that did not infringe on Sony's copyright. Of course, Bleem! ended up sued into oblivion and Sony bought VGS and killed it, so this strategy, however legally sound, was evidently not successful in the long run. I have no idea whether someone could get away with the same thing nowadays with much older hardware that Apple has long since stopped caring about, but then there do seem to be numerous sites that get away with openly offering old ROMs.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Executor: Reverse engineering Macintosh ROMs?

Post by adespoton »

Yes -- I remember that :D I remember thinking at the time that someone didn't know the difference between disassembling and reimplementing a product and clean room reverse engineering (which is what Ardi did).

It seems to me that for the 24-bit ROMs, most of the actual hardware interaction in the original ROMs doesn't really need to be reversed, beyond figuring out what the OS expected to have passed back to it for the various system calls and figuring out the timing. Of course, this would have to sit on top of some generalized stack, or else you'd have the behaviour changing each time you changed the host OS.

The good news is that at this point, the original patents would have expired and trade law isn't really an issue -- so the only thing you really have to worry about is copyright. As long as you do a clean reverse job instead of decompiling the ROM (look at the software that calls the ROM hooks, not the ROM itself), things should be legal.

The tricky bit here is that in many cases, the System actually bootstraps a bunch of the ROM calls which originally reside in ROM. The good part about this is that it becomes easy to insert code in between the two to monitor all the call passing and drop support for the old ROM calls when they're not needed.

As such, it should be fairly easy to write an engine that allows you to run software on System 7.5.3, as many of the system calls are actually handled by the System memory and not the ROM. Doing this with older OSes however (especially pre-System 6), would be a lot trickier.
User avatar
sentient06
Mac Mechanic
Posts: 188
Joined: Tue Mar 29, 2011 8:57 pm
Location: London, UK

Re: Executor: Reverse engineering Macintosh ROMs?

Post by sentient06 »

That's an interesting subject!
I remember to read somewhere about Compaq and the ROMs from IBM. As far as I understood, they reverse-engineered the IBM ROM for real and created a very detailed documentation on how it should work and behave. After that, they hired a group of developers to assemble a new ROM from ground zero following those specifications. This resulted in a different ROM that could be used for making computers that would be perfectly compatible with IBM's and at the same time they were pretty much protected against legal threats from IBM.

I find it interesting nobody did the same with Apple's ROMs. I am completely ignorant about how IBM ROMs work, their complexity or if they are nearly similar to Apple's in any way, but I suppose that the same could be done if we had some really obsessed developers. :mrgreen:
User avatar
sentient06
Mac Mechanic
Posts: 188
Joined: Tue Mar 29, 2011 8:57 pm
Location: London, UK

Re: Executor: Reverse engineering Macintosh ROMs?

Post by sentient06 »

I just stumbled on this page by accident:

http://www.myoldmac.net/cgi-data/forum/ ... 3d5fc3b3ea
"At the same time, a software team reverse-engineered the ROM, based on the 'Inside Mac' specifications. I was a consultant for that team and eventually did most of the Toolbox managers . . . everything was coded in C, except for some critical device drivers and the QuickDraw emulator which were done in Assembly language. As a result, the resulting ROM was originally double the size of Apple's . . . in fact, in the final shipping version it was substituted by static RAM, which was loaded from a special pre-boot floppy."
They are talking about the Macintosh 512K here.

This was done in Brazil, which is interesting for me, since I was raised there. I went to law school for 2 years before moving to a computing faculty instead. Brazilian law indeed had a very harsh policy towards importing of "national similar". Meaning that the law won't differentiate a Brazilian-made IBM computer from an imported Macintosh. It happens today too, but now the only problem are the high taxes.

Indeed, the Brazilians also cloned a few PPC macintoshes back in 1997, I believe. I had the opportunity to see one. :mrgreen:
Jorpho
Master Emulator
Posts: 380
Joined: Fri Sep 17, 2004 4:22 am

Re: Executor: Reverse engineering Macintosh ROMs?

Post by Jorpho »

The VMACE guy was re-implementing parts of the ROM too, wasn't he?
http://pmace.sourceforge.net/vmace.html

Inside Macintosh sounds like quite the tome.
http://en.wikipedia.org/wiki/Inside_Macintosh
http://folklore.org/StoryView.py?story= ... intosh.txt
Adam P
Tinkerer
Posts: 67
Joined: Wed Mar 31, 2010 11:55 pm
Location: Maine, U.S.
Contact:

Re: Executor: Reverse engineering Macintosh ROMs?

Post by Adam P »

In order for emulation to be true, the ROM must be true.  Drifting too far would mean programs/OS’s that depend on— not just the code, but— raw data that exists all over in these "Old World" ROMs would mean that new ROMs —reversed engineered or not— would cause more programs to break.  It can be tricky in the case that even an OS recognizes the ROM version and expects certain data to just be at ROM address A, B, C.  Just the art of patching alone opens up this problem.

(The older the emulated system the more tricks the Apple programmers made for making things actually run fast on that system, the more dependencies that may exist.)

Accurate emulation isn’t free.  And reverse engineering the ROM probably doesn’t help that. :)

It’s always best for an emulator project to start with I/O simulation first, something where low-level emulators like [Mini] vMac triumph, having only minimal patches, making virtual floppies out of all the disk images.  HDD emulation would probably be pretty slow done with native I/O routines, not to mention messy, as with MESS with its complicated file format, while Fusion/SoftMac did a good job emulating SCSI I/O for realistic disk/disk image manipulation.

There are certainly speed advantages with optimizing routines in native code, making routines like CopyBits (graphics) run faster— something I think I remember being done, the low-level blitter routines, at least.  Sound output both accurate and fast (at least on older native systems) has always been difficult without some kind of patching or assembly-level code on the emulator’s part.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Executor: Reverse engineering Macintosh ROMs?

Post by adespoton »

While true, reference my previous post: a lot of the ROM routines are actually patched by the System (or the system enabler for System 7.1). Because of this, you don't have to faithfully emulate all those legacy ROM codes, because on any OS from system 7.1 onwards, they're already patched by the OS prior to being called. So you just need to duplicate the ones that kick off the bootstrap process, and any that aren't handled by the system for hardware I/O -- pretty much everything else has been patched over, reducing the dependency tree.

Of course, every time you leave an instruction to the OS, you're reducing the number of OSes you are compatible with -- such an emulator isn't really emulating the hardware system anymore, but is targeted at specific hardware + OS. Thus, running NetBSD will be more difficult (although not completely, as for these old systems, you had to boot the default OS first to bootstrap the system calls, because the NetBSD guys didn't have access to the full ROM details either).
Jorpho
Master Emulator
Posts: 380
Joined: Fri Sep 17, 2004 4:22 am

Re: Executor: Reverse engineering Macintosh ROMs?

Post by Jorpho »

Adam P wrote:Accurate emulation isn’t free.
Sure, it's a trade-off – but in some cases it seems reasonable to sacrifice accuracy for freedom.

I mentioned it in the other thread, but for completion's sake, I might as well reiterate that Amiga enthusiasts have successfully made a free open source Kickstart ROM alternative.
http://aros.sourceforge.net/
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Executor: Reverse engineering Macintosh ROMs?

Post by adespoton »

Yes, but the Amiga ROM was developed on the shoulders of Apple -- the ROM implementation is very nicely laid out, and you're only dealing with 7 ROMs for the entire Amiga line of computers. With both Classic and II-style ROMs (and then later, the Quadra and old-world PPC roms) you're dealing with multiple ROMs even within a single hardware set, as Apple did things old-school.

That said, there are definitely a few ROMs that would make excellent reference ROMs (Generic Classic, II and Quadra-style ROMs, for instance).
Adam P
Tinkerer
Posts: 67
Joined: Wed Mar 31, 2010 11:55 pm
Location: Maine, U.S.
Contact:

Re: Executor: Reverse engineering Macintosh ROMs?

Post by Adam P »

Looking at the Executor source code (released some time ago), the emulator does quite a lot at attempting to manage QuickDraw graphics among the nativized trap code, in so many C source files… however the implementation used in a number of the functions is quite different (ovals look weird, for one, glancing at the radio buttons).

There are too many holes though for this emulator, which used to cost as much as a couple hundred bucks, to run most software properly (or at all).  Seed filling alone (i.e., paint bucket tool) will crash.  Extensive review and limited program compatibility listing here.

So it looks like Inside Macintosh, many years from 1986-on, trial & error were used more than really taking anything from reverse engineering.  (After all, Apple legal doesn’t like that.)

The upside of native code vs. emulated ROM code, plus dynamic compilation (JIT) makes Executor pretty damn fast (Wolfenstein 3D at the highest resolution surprised me).  The virtual CPU (Syn68K) also appears to emulate some instructions more accurately than Basilisk II… some of the few advantages, unfortunately.
Post Reply