LC475 Disassembled ROM

[frontein1]

I know there have been posts similar to this. But I've worked with some tools such as FDisasm. I can't seem to really get a reliable or full disassembly of the LC475 ROM. I would like to get to this point, so I can dabble with ROM programming using some SIMMs I purchased from CayMac.

Can anyone give me a jump start to help? I think with the right help I can probably take it from there. I would like to learn how to get this done, as I think it will help me on my journey. But if you already have a disassembled LC475 ROM I'll take that too

FYI, I did pull MPW from MacintoshGarden. So I do have the ROM map for the LC475.

Thanks for the pointers!!

 

[frontein1]

Also if anyone has a bin_map and bin_names for the LC475 / Quadra605, that would be very helpful...

 

[joevt]

The ROM map (I think its Quadra605ROM.lst) appears to indicate that the ROM code is probably the first 0xD3C00 (867328) bytes of the ROM but not all of it is code.

The LC475 ROM is too old for tbxi since it is pre-supermario.
https://github.com/elliotnunn/tbxi
Maybe some other elliotnunn GitHub repositories are useful.

Although the ROM is older than supermario, much of the supermario source code is applicable.
StartInit.a declares the ROM header ($7D is for supermario, while LC 475 uses $7C). The ROM header is defined in HardwarePrivateEqu.a.

There's probably a way to extract resources from the ROM (I've never done it - maybe tbxi has a clue). The supermario InitResources code might show how to do that: RomRsrc in the ROM header is referenced using RomBase (low memory global) + 0x1A in the ReDoMap code. It points to 0x7EC10. Each resource seems to point to earlier in the ROM for the next resource.

My SlotsParse utility can dump the Slot Manager declaration rom part of the ROM (the last 62358 bytes starting at 0xF0C60) but only that one at the end of the ROM. There's another declrom that ends at 0xA0000 (VSCDECLROM). To dump that, you need to copy the first 0xA0000 of the ROM to another file and use the SlotsParse command on that.

Found this note. Maybe it's applicable:
Re: Is a disassembly of the 128kb Mac ROM available anywhere
There is a split in the ROM at 512K (0x80000)

For disassembling, I would try Jasik's MacNosy (just because I don't know any better classic Mac OS disassembling tools that don't require extra setup). It uses the ROM map file.
https://www.jasik.com/

 

[SuperSVGA]

I usually just use Ghidra to do all my disassembly. Ghidra has a built in script to load labels quickly, so I format the ROM maps and load those in, as well as loading in labels for low memory globals and hardware addresses.
Ghidra isn't perfect though (at least for this use case), I often think about just writing a simple program that disassembles the ROM to a reassemble friendly text file.

The dispatch table in the LC475 ROM is the more annoying ones that uses multiple size offsets, rather than the later ones which are just memory addresses.

 

[adespoton]

If you've got access to it, HexRays/IDAPro is going to give you better output than Ghidra for 68k Mac symbols and labels, as it has a better understanding of the low memory globals and hardware addresses.

LC475 is in that uncomfortable place where it's been patched a bunch since the simpler 030 ROMs, but being pre-SuperMario / tbxi, it's not modified as much as the disassembly we've already got.

As I mentioned in that thread joevt linked, the place to start is with the 64k ROM disassembly, as 128k ROMs are all patched off of those. Comparing some of the earlier ROMs as well as the SuperMario disassembly should help you fill in all of the first 64k, and then you'll need to trace the 64k patches to the higher memory to fill in all the patches. The ones that are at the same location as SuperMario should be roughly the same code; some will be pushed higher but still be the same code to make room for patches that were later removed.

 

[nyef]

There's probably a way to extract resources from the ROM (I've never done it - maybe tbxi has a clue). The supermario InitResources code might show how to do that: RomRsrc in the ROM header is referenced using RomBase (low memory global) + 0x1A in the ReDoMap code. It points to 0x7EC10. Each resource seems to point to earlier in the ROM for the next resource.

This analysis (from some of my own notes on ROM resources) may be of help if you're inclined to write a new extractor:

         - Starting with the 512k ROMs (Classic, Classic II, LC, LCII,
           IIci, IIsi, IIfx), there is still an offset at offset $1a,
           but the format of the data is different.
           - This is possibly the first generation of "32-bit clean"
             ROMs.
           - $1a points to a structure of unknown length ($0a bytes?)
             that starts with an offset... to what might be a ROM heap
             arena for a resource header?  Seems to be a $30-byte
             structure, at least.
             - 8 bytes into that target is a link to the next such
               maybe-arena (or zeros, at the end of the list).
             - $0c bytes into the target appears to be the offset of
               some resource data.
             - $10 is the resource type (four bytes),
             - $14 is the resource ID (two bytes),
             - $16 is unknown (one byte), maybe resource flags?
             - $17 is the count byte for the resource name string (up
               to twelve characters),
             - $24 is unknown (four bytes)
             - $28 seems as though it might be related to the resource
               data length somehow, but not directly?
               - Seems like the length, rounded up to a multiple of
                 sixteen ($10) bytes, with a minimum value of $10 for
                 zero-length resources (the FONT resources that are
                 used to store font names, in particular).
                 - KCHR 0 in the Quadra 950 ROM appears to have this
                   value $10 higher than the actual length of data.
                 - This might be an attempt at the usual "add one less
                   than the allocation granularity, then mask off the
                   low bits to the granularity", except missing the
                   "one less" part.  The end result would be that
                   everything that isn't already aligned gets rounded
                   up, and everything that /is/ aligned gets bumped to
                   the next boundary anyway.
               - The practical upshot here is that it seems unlikely
                 to be able to easily get accurate length information
                 for ROM resources.
             - $2c is unknown (four bytes), seems to increase by 8
               each subsequent entry in the list?

 

[frontein1]

Thanks for the pointers! I'm reading through right now and learning a lot. Just bought an old book on 68000 assembly to get up to speed. Although my degree is in computer science, it has probably been 20 years since I've done day-to-day programming. Told my wife, 68K was the perfect mid-life crisis to get into!

 

[joevt]

Attached a script to dump a list of the resources. It probably works the same way the tbxi script does (I haven't looked).
Run it like this:
perl dumpromresources pathtorom
It just dumps some info about each resource. You can modify the code to create a file for each resource or create a .r file that can be used by the Rez command to create resources.

If there's more than one resource with the same name and type, then you need to check the combo bits to determine which variant is used by your Mac (FPU or no FPU, 24bit or 32bit, etc.)

The function for getting a handle or pointer size is a24GetSize or a32GetSize depending on the memory header size (8 bytes for 24-bit addressing and 12 bytes for 32-bit addressing). There's a size correction field in the memory header of each resource but this isn't setup for rom resources according to Hiram.c

Some of the resources have a size that is not aligned to a 4 byte boundary - these weren't built by [/icode]Hiram.c?

 

[frontein1]

So cool joevt! Just looking into your script now. Thank you

 

[joevt]

Updated my dumpromresources script at https://68kmla.org/bb/index.php?threads/pict-data-format.49561/post-557931

 

[frontein1]

This is just awesome! You rock!