-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
unirom: an Old World ROM info dumper
- Thread starter Arbee
- Start date
Phipli
Well-known member
Just to be clear, I'm meaning how much addressible space there is in the hardware address range, rather than how big the stock ROMs are. Generally Apple left some overhead for each era. Sadly its a little tricky to find out on the spot and not something I have committed to memory, but for example, the 650 can physically address an 8MB ROM, with some caveats. The use of the MMU means that even if it isn't directly mapped into the address space by default, you could work it in somewhere. I mean, once the code starts running you could put the ROM base address anywhere where there is a nice big gap... but, you still physically need sufficient address pins on the ROM itself.
Nixontheknight
Well-known member
Hmm, I wonder what differences between the two LC III ROMs exist. Does anyone have any ROM dumps (and a knowledge of 68030 assembly) to compare the two to see what's different, if anything?
Of course since you mentioned this, I had to try it in my IIci
It actually plays the startup chime, but the screen stays black. The same behavior I saw when I tried the LC 475 ROM in my IIci too.This might not be too surprising though. Unless it's hiding from me, I don't see the Display_Video_Apple_RBV1 driver in those ROMs even though it is in other compatible ROMs like the IIsi, 610/650/800, and Color Classic ROMs.
That might be a fun project to try sometime -- hack the RBV driver into the 580 or 475 ROM and see if that allows the IIci to get further in the boot process...or maybe try it in another machine like the IIx that doesn't depend on that driver. Or put a NuBus video card into my IIci.
Agreed. At the very least, it does have the Display_Video_Apple_RBV1 driver so it has that going for it. If I had a IIsi, I would totally test that (and the 660av/840av ROM) for fun. I definitely wouldn't bet on it working though.
That's very possible. I should point out that the leaked sources' MMU tables seem to have a ROMMaxSize of 2 MB so at some point Apple upped it from 1 MB. That ROMMaxSize equate is used by several machines, including the Orwell stuff which I believe would apply to the djMEMC and MEMCjr machines. I'd have to inspect the MMU tables in the actual final 660av/840av ROM more closely to confirm. The interesting names from the source that would apply to the 610/650/800 are Template32Orwell and physOrwell, for anyone playing along at home with the SuperMario sources.
They even opened it up to 4 MB (FFRomMax) in TemplateFF32. FF stands for Foster Farms and based on the source it looks like it goes with the V8/VISA/Spice/etc. type machines.
I can't speak for all of these supported ROMs (maybe we could add MMU table parsing
) but in the Color Classic ROM, the Orwell stuff was still only mapping 1 MB of ROM space in the MMU.I'd be curious to know now if it does work with a NuBus video card.
Ha! With a NuBus video card, my IIci successfully boots from the 605/475 ROM (FF7439EE). So in theory, I could add the RBV driver back into it and use the internal video.
The 580 ROM (064DC91D) seems to have deeper incompatibilities though. It chimes, but I never hear the speaker pop after several seconds like I do with working ROMs, so it's probably getting hung up somewhere earlier.
Nixontheknight
Well-known member
I imagine it would because the chime is in the ROM
But there can be more than one chime in the ROM
It plays the standard IIci synthesized startup chime. So I think the startup code still decides which chime to play based on which machine it finds.
eharmon
Well-known member
How did you search for the tables? Is there a documented ROM structure anywhere?
Currently I can read and understand the DeclROM parts with my own code, and I see the ROM header with the checksum and version info, but I presume there's a list structure of some sort with the ROM data?
Currently I can read and understand the DeclROM parts with my own code, and I see the ROM header with the checksum and version info, but I presume there's a list structure of some sort with the ROM data?
I searched for the tables mostly by disassembling the machine ID routine in each ROM. The structure is in the SuperMario tree in the file OS/UniversalTables.a. There are multiple versions of the tables, but the newer ones thankfully mostly just add fields rather than changing what existing ones mean.
I ended up "borrowing" some of this code to make a Ghidra plugin that uses this info to mark up a ROM file you have loaded into it with symbols, references, labels and comments. It's by no means finished though...
(I'll start a new thread when I've got something decent in Ghidra , not trying to hijack this one!)
github.com
(I'll start a new thread when I've got something decent in Ghidra , not trying to hijack this one!)
q800-rom-hacking/scripts/AnnotateROMTables.py at main · gm-stack/q800-rom-hacking
Disassembling and annotating the Q800 ROM in Ghidra (Quadra/Centris 610,650,800 checksum F1ACDA13) - gm-stack/q800-rom-hacking
github.com
That’s cool. Ghidra is rough for 68k Mac stuff with it not knowing traps aren’t illegal instructions and stuff like that. Plug-ins definitely help a lot though.
Take a look in the machine-specific info table - read the 32 bit value at 0x18 offset into the table (decimal 24). (and remember which end of the bits is 0 and which is 31... I got that wrong the first time.)
It's a 32 bit field of which addresses in the decoder's base address table are actually valid for that particular machine.
In the ROM which you've called "Quadra 800 and friends (later)" - both the IIci (which has two entries in the list anyway, 0x3718 and 0x3758) and IIsi (0x37d8) point to the same MDU table at 0x3348.
This table defines SWIMIOP at 0x50f1e020 and SCCIOP at 0x50f0c020.
However all of those machines have the bit for that address in that field at 0x18 set to 0.
(There is an entry for the IIfx in this ROM which would have them, and it has addreses defined in the FMC address decoder info table, but it has all the bits in the 0x18 field set to 0 - however I think this ROM probably can't boot that machine anyway. )
And with a bit of a further look into what's going on in GetHardwareInfo, there's also a number of functions that determine whether certain bits of hardware are there or not - at the defined addresses, and turn them off if not. So even having the address defined and the bit set is no guarantee.
I recently came across a trove of interesting documents on Internet Archive. One of the documents seems very relevant to this thread. It is an internal document from Apple, published in 1989, documenting an effort to clean up and consolidate the ROM codebase into a single Universal ROM. It's a nice little discussion of what they were working to improve and a nice rundown of issues with prior releases:
Given the date of the document, and the fact that those machines are not mentioned, I suspect the document is talking about work that was being done for the IIci and IIfx.
