Recent content by gm_stack

As far as I understand it, FDisAsm should just be reading the ROM directly, so you should get the original versions of the functions. Pretty sure Mini vMac doesn't do any patching of the ROM itself like BasiliskII does (IIRC). When the OS "patches" ROM routines, the ROM itself is not modified...

Yep, you certainly can do that. You'll need to write a script to parse those files, and determine the address and the comment. Then you'd simply use a function to set the comment at that address and/or create a function at that address. Most of what you need is in the FlatProgramAPI...

So that 4 wire ribbon cable extending upwards from the centre of the PCB might just be stock standard ADB?

IIRC it was only the very last Aluminium PowerBook G4 (12" 1.5Ghz / 15"/17" ) that had a USB keyboard/trackpad - the one that introduced "two finger scrolling". iScroll2 added support for it in a number of ADB ones previous to that: https://iscroll2.sourceforge.net/#checksupport

I've ended up moving the repo to https://github.com/gm-stack/classic-mac-rom-ghidra-tools - as I don't think the original name fit it. Appears Github is handling the redirect properly. Work continues...

I've pushed a few little updates - FixupBSR6.py now handles BSR5 and BigBSR5/6. AnnotateRomTables.py has had a major overhaul, and I've now implemented wrapper classes for the ability to use Ghidra's parsing of the struct back in my code! # Create the MachineInfo table at the right address m...

Hmm, funny you should say that... You're also right about the System ROM tables... I don't think I've found a way to pin them down other than "they're two of the three constant memory references in Ghidra's decompiler view of GetHardwareInfo". I don't think either will be likely to be loaded...

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.

https://github.com/gm-stack/q800-rom-hacking I've posted some scripts to load into Ghidra to play with ROM images. There's full info in the README.md in the Git repository, but in short: AnnotateRomTables.py: Initially based on rb6502's unirom, this one creates a bunch of structs to let you...

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...

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...