From: Stuart Bell <[EMAIL PROTECTED]> Date: Fri, 6 Feb 2004 21:40:46 +0000
On 6 Feb 2004, at 21:38, Tom Lee wrote:
Reverse-engineering the PALs is simple, but the ROMs are another story! The Apple team used some very clever, and complex hacks for compressing and encrypting.
Interesting change in Apple policy - from putting Apple II ROM listings in the manual.
Do you mean that the ROMs aren't pure M68000 code, but are decrypted on the fly (or, on boot, into RAM) before execution?
I'm surprised if no-one has dis-assembled the early Mac ROMs. I had a great time doing that to the p-code interpreter and BIOS in Apple Pascal on the AII, rewriting it for my own peripherals, and then assembling it again!
I don't know about encryption and compression, but a book I read about 10 - 15 years ago said that the original Macintosh ROM was pretty much completely written in hand tweaked assembly and/or machine code. It was one of those History of Apple or History of Macintosh type books, a big six or seven years after the Macintosh came out. :-) Actually, the vague memory is coming back that the book ended with Jobs at NeXT, so it must have come out after Jobs founded NeXT, I think, unless I'm combining two books in my memory.
Anyway, there wouldn't be any point in disassembling the code, as there is nothing to disassemble it to, although I guess a really good disassembler might be able to translate what is there into a very clunky rendition in a higher level language for somewhat easier readability.
All that said, I think there might be some potential there, for a clinically obsessive compulsive person (i.e. assembly programmer) with a lot of time on his hands. Much of the ROM must be the tool box. And the tool box calls aren't going to have much to do with the address/memory map. So it seems to me that if one could separate out the toolbox routines from the hardware support code, it should be possible to greatly reduce the amount of code that needs looking at.
It should be possible to find all of the toolbox calls by following the calling addresses for them. I think that's covered in Inside Macintosh or Macintosh Revealed. There's a vector table to work through, but that just adds one step to the process. Ultimately, it shouldn't be too hard to find the beginning address for each toolbox call in the ROM, and then follow each routine to the end and eliminate it as a non-hardware related chunk of code.
A more fruitful experiment might be to get one's hands on a PowerBook 100 and see what happens when the ROMs are installed in the Mac Plus. If they kept the hardware addresses the same between the two, one might get pretty good functionality.
However, even if one can bump the memory map up to support 8 or 12 MB of RAM, I'm not sure how one would get the physical RAM installed and recognized. You'd need to mess with the circuitry handling refresh and control of the RAM, I think. Are there even enough address lines in that control circuitry to support more than 4 MB of RAM? Anyone know if the Plus supports 9 X 11 multiplexing or just 10 X 10?
At that point, it starts to look like you're designing and building a Mac Plus board from scratch but stealing most of the ROM code. And if you're going to do that, you may as well start with the PB 100 ROM as it will support 8 MB out of the gate.
Jeff Walther
-- Compact Macs is sponsored by <http://lowendmac.com/>.
Support Low End Mac <http://lowendmac.com/lists/support.html>
Compact Macs list info: <http://lowendmac.com/lists/compact.shtml> --> AOL users, remove "mailto:"; Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive:<http://www.mail-archive.com/compact.macs%40mail.maclaunch.com/>
---------------------------------------------------------------
The Think Different Store
http://www.ThinkDifferentStore.com ---------------------------------------------------------------
