LC475 Disassembled ROM

F

frontein1

Well-known member
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!!
 
J

joevt

Well-known member
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/
 

Attachments

  • Macintosh Quadra 605-LC 475-575-Performa 475-575.zip
    25.3 KB · Views: 6
SuperSVGA

SuperSVGA

Well-known member
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

adespoton

Well-known member
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.
 
N

nyef

Well-known member
joevt said:
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.
Click to expand...
This analysis (from some of my own notes on ROM resources) may be of help if you're inclined to write a new extractor:
Code: 
         - 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?
 
F

frontein1

Well-known member
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!
 
J

joevt

Well-known member
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?
 

Attachments

  • dumpromresources.zip
    4.6 KB · Views: 5
J

joevt

Well-known member
@elliotnunn 's supermario repository has some info in the source code. See my notes in #3 for the assembly routines to look for.

His tbxi command, when used on a 68K Mac ROM (that is not too old) or an Old World PowerPC Mac ROM or a New World ROM file (version $077d in any case), produces a ROM resource list text file named "Romfile" which always contains this comment:
Code: 
# Automated dump of Macintosh ROM resources

# The (optional) combo mask switches a resource based on the DefaultRSRCs
# field of the box's ProductInfo structure. (The low-memory variable at
# 0xDD8 points to ProductInfo, and the DefaultRSRCs byte is at offset
# 0x16.) The combo field is usually used for the Standard Apple Numeric
# Environment (SANE) PACKs 4 and 5.

# Summary of known combos:
# 0b01111000    AllCombos (DEFAULT)         Universal resource          
# 0b01000000    AppleTalk1                  Appletalk 1.0               
# 0b00100000    AppleTalk2                  Appletalk 2.0               
# 0b00110000    AppleTalk2_NetBoot_FPU      Has FPU and remote booting  
# 0b00001000    AppleTalk2_NetBoot_NoFPU    Has remote booting, no FPU  
# 0b00010000    NetBoot                     Has remote booting

I'm not sure why the rom list in that file doesn't indicate the combo bits for each resource like my dumpromresources script does.
Actually, looking at the PACK examples mentioned in the comment above, we see that the non-default combo option is specified in a combo column and the src column has the combo name appended to make the filename unique.

Code: 
type=PACK   id=4        name=Main               src=Rsrc/PACK_4_AT2_NetBoot_FPU     combo=AppleTalk2_NetBoot_FPU
type=PACK   id=5        name=Main               src=Rsrc/PACK_5_AT2_NetBoot_FPU     combo=AppleTalk2_NetBoot_FPU
type=PACK   id=4        name=Main               src=Rsrc/PACK_4_AT2_NetBoot_NoFPU   combo=AppleTalk2_NetBoot_NoFPU
type=PACK   id=5        name=Main               src=Rsrc/PACK_5_AT2_NetBoot_NoFPU   combo=AppleTalk2_NetBoot_NoFPU
type=PACK   id=7        name=Main               src=Rsrc/PACK_7
type=PACK   id=8        name=AevtMgr            src=Rsrc/PACK_8_AevtMgr

PACK 4 and 5 have two variants each so they have a combo specifier.
PACK 7 and 8 don't have alternate versions so there's no combo specifier for those.

The tbxi command is used to dump all the parts of the ROM. You can make modifications and use tbxi to build a new ROM.

I wonder how difficult it would be to make it work for the older 68K Mac ROMs (version $067c) or if there's a tool or script for that already?
 

Attachments

  • romlist.txt
    25.2 KB · Views: 2
F

frontein1

Well-known member
Thank you! I just downloaded that repository, so I'll take a look at all this. Seems like a ton of good information in there.

The little project I am working on is building my own variant of the netBOOT driver from scratch.
 
J

joevt

Well-known member
frontein1 said:
Thank you! I just downloaded that repository, so I'll take a look at all this. Seems like a ton of good information in there.

The little project I am working on is building my own variant of the netBOOT driver from scratch.
Click to expand...

The .netBOOT driver exists in the ROM resources list so it should be easy to replace it.
Code: 
ROM Resource Reference Entry @00051c80
    ComboBits             "00011"
    offsetToNext          0x000edc70
    offsetToData          0x00051cb0
    rsrcType              'DRVR'
    rsrcID                49
    rsrcAttr              0x58
    rsrcName              ".netBOOT"
    memHeader             0x00051ca4
    memTag                0xc0
    memSize               2164
    memMaster             0x00000304

ComboBits "00011" corresponds to 0b00110000 AppleTalk2_NetBoot_FPU Has FPU and remote booting

Only the 5 ComBFSz most significant bits of the first byte of the combo bytes is used.
The most significant bit is combo 0 which is not a real combo so this bit is never set.
The last combo is 4 MaxComInd

Code: 
combos 1 to 4 # 0b01111000    AllCombos (DEFAULT)         Universal resource          
combo 1       # 0b01000000    AppleTalk1                  Appletalk 1.0              
combo 2       # 0b00100000    AppleTalk2                  Appletalk 2.0              
combo 2 and 3 # 0b00110000    AppleTalk2_NetBoot_FPU      Has FPU and remote booting  
combo 3       # 0b00010000    NetBoot                     Has remote booting
combo 4       # 0b00001000    AppleTalk2_NetBoot_NoFPU    Has remote booting, no FPU

Looking at the ReDoMap code:
PRAM offset 0xAE has a combo number.
0 or > MaxComInd in PRAM means use the default in the (ProductInfo)UnivInfoPtr->DefaultRSRCs structure.
4 is optional FPU. This is changed to 3 if an FPU is present according to the hwCbFPU bit in HWCfgFlags

Here's a comment from RomResources.r (which is maybe the Rom.r file mentioned in ReDoMap?):
Code: 
#define AppleTalk1                  0x40            /*  Appletalk 1.0               01000000 */
#define AppleTalk2                  0x20            /*  Appletalk 2.0               00100000 */
#define AppleTalk2_NetBoot_FPU      0x30            /*  Has FPU and remote booting  00110000 */
#define AppleTalk2_NetBoot_NoFPU    0x08            /*  Has remote booting, no FPU  00001000 */
#define NetBoot                     0x10            /*  Has remote booting          00010000 */
#define AllCombos                   0x78            /*  Universal resource          01111000 */

If combo 4 is 0x08 AppleTalk2_NetBoot_NoFPU and ReDoMap can change that to 3 with FPU, then doesn't that make 0x10 NetBoot actually AppleTalk2_NetBoot_FPU, which conflicts with 0x30 AppleTalk2_NetBoot_FPU?
Then the meaning of 0x30 is logically "AppleTalk2 or AppleTalk2_NetBoot_FPU and not AppleTalk2_NetBoot_NoFPU" which doesn't make sense.
Well, you can look at the history of RomResources.r to see how they've changed some of the combos over time.
 

Attachments

  • XPRAM notes.txt
    8.3 KB · Views: 1
You must log in or register to reply here.

Similar threads

F
Happy MARCHintosh - My LC475
Replies
4
Views
606
frontein1
F
Retronaut
LC475 vertical lines in display issue
Replies
18
Views
2K
Retronaut
Retronaut
S
LC475 with no sound output
Replies
1
Views
417
shirsch
S
D
New LC475
Replies
19
Views
3K
Jockelill
Jockelill
D
LC475 DynaComp PSU fireworks!
Replies
17
Views
1K
displaced
D
Top