This wonderful site has a subversion repository available to us, and I've started putting some of the ROM disassembly I've been doing into it, located here: https://mac68k.info/repo/rom_disasm/. Anyone with a forum account should be able to access it, and you can check it out with subversion using:
svn co --username <forumusername> https://mac68k.info/repo/rom_disasm/
So far, I've added the IIsi disassembly I've done, and some AV ROM disassembly.
My initial goal with the AV ROM disassembly was to match up the source that we found with the disassembly, ultimately having a symboled, commented AV ROM disassembly. The task is practically monumental with hundreds of thousands of lines, but you have to start somewhere, right?
One interesting thing I've found is the source doesn't match the ROM I read from my Q660av. There are many similarities, with the occasional difference, but some things like the BootRetry code is dramatically different.
I'm using fdisasm for the disassembly. I've found fdisasm to be pretty great, but I did find one bug in it. There's a problem when handling BRA/BSR with a 32bit displacement, which unfortunately is used frequently. A common convention in the ROM is to load the address of the following instruction into register A6, then BSR with a 32bit PC relative displacement. The called code then returns by jumping to the address in A6 (this is the BSR6 macro in the source). This not only triggers the 32bit displacement bug in fdisasm, but it also defeats FindCode because it sees the BSR and can't follow the return, so disassembly stops with the BSR, and you need to manually tell FindCode to look for more code afterward.
I've put a modified version of fdisasm-1.1.1 into the repo with a fix. I've also submitted feedback to fdisasm, so hopefully a fix will be included upstream as well and my modified version won't be necessary.
I've been focusing on the IIsi ROM this weekend. New disassembly additions with symbols, although minimal annotations:
Most of StartInit1, pretty much all of GetHardwareInfo, most of the boot code, all of MicroBug, ADB Manager, Slot Manager, Vertical Retrace Manager, Deferred Task Manager, and Queues.
I've also started on trying to annotate the Product Info tables. There's some interesting information in there, although it is a bit confusing as to what does and doesn't refer to it. For instance, the product info table has information about FPU, available slots, RAM banks, etc. Although at the same time, the MMU code maintains its own tables for slot mappings on a per machine basis, and separate code to test for the presence of an FPU. The IIsi's product info entry reports the presence of an FPU, when it doesn't have one by default.
I've been continuing to work on the IIsi disassembly. It should have fully commented product information tables, including information on their ram, video, nubus slots, and address decoder. Also IOPMgr, SlotMgr, and now SCSIMgr.
From the product tables, the IIsi ROM knows about: II, IIx, SE/30, IIcx, IIci (with and without the parity generator chip), IIfx, IIsi, LC, and 3 apparently unreleased products.
I've also added support to fdisasm to support the pmove, pflush, and pload family of instructions, so the 030 and 68851 cache invalidation, 24/32bit addressing toggle, and the MMU setup for slot information including not just mappings but what address ranges can be cached, etc. should now be properly disassembled. The changes have been submitted upstream, and will hopefully be accepted.
Disassembly is tedious. I've got maybe 45K of the 512K ROM disassembled at this point.
Very nice work! This is going to be a really useful reference for future ROM hacking.
I have some of the startup chime code from the IIci ROM commented from when I was doing the startup chime hacking. If I can find the equivalent code in the IIsi ROM I might be able to help with some of that.
Well, I'm not entirely sure how to answer that, but I'll take a stab.
Disassembly of the system rom (what we're doing in this thread) is a little different than disassembly of a declrom. The system rom disassembly is mostly around finding code, disassembling it, and figuring out what it does. Declroms are structured data, not code. Although declroms can contain code, that is stored as data in a structured manner. It's more like a hard-coded filesystem.
For system rom disassembly that we're doing here, I'm using FDisasm, which runs on macos, and takes a number of input files. The input files we've been using are, as mentioned above, stored in subversion at the repository mentioned above. The repository is hosted by the forum, and uses your forum username/password for access. For command line access, which is what most of us are comfortable with I think, you can use the above command to check out the latest version. I'm sure there are graphical clients available, but I'm not familiar with them.
Once you've got the disassembly files, you need to get them to FDisasm. On page 4 of the ROM booting thread, there's an exchange between dougg3 and I about setting up minivmac and using ImportFl and ExportFl to exchange files between the host system and minivmac.
For declrom disassembly, the tools are much less refined. I've got a C library and some command line tools that I use for inspecting and creating declroms, but it's pretty rough at the moment. I'm in the process of adding support for video card specific resources. I've got a brief description and links to my tools here. I'll update the links to newer versions of the tools as I work on them (like when I add the video specific bits).
The best I can recommend at the moment for declroms are: Know and love Designing Cards and Drivers for the Macintosh Family Chapter 8 "NuBus Card Firmware". Chapter 9 has some more video specific bits. Then get comfortable with a hex editor.
FWIW, ethernet cards, like the Asantes or even the Rockets have pretty much the simplest declroms you'll find. You can use the SlotRom utility to dump the declrom from a running system, then use Designing Cards and Drivers as a reference while browsing in the hex editor...
Thanks, buddy, that's a great start for me toward disassembling the jargon and tools used in this process. There seems to be a lot that anyone involved in this sort of hacking takes for granted as being self-evident. Sort of the way I look at using physical tools in making hardware mods as being obvious, when to the uninitiated, it's certainly not.
I'm a bit overwhelmed by the thought of taking on even DeclROM spelunking, but I'm game to learn something new. I'll re-read DCaDftMFH from this new perspective.
Is there a Hex editor that presents data in a visual way, like a spreadsheet, allowing for commenting, equating and searching code/data groups?
If not, what's a good one for this procedure that'll run under OS9 on a PDQ or OSX on a Pismo?
AFAIK, nothing so fancy as the visual system you're looking for.
I'm a command line guy, so I use "hexdump" with the -C option in a terminal for read-only viewing. For GUI hex editors, I'm aware of but haven't actually used Hex Fiend and one of the older versions might run on OSX on a Pismo. Commercially Resorcerer is like resedit on steroids, and runs on OSX. It will even do code disassembly of code resources, although it isn't necessarily aware of the structure of all code resources, so it's not perfect.
Beyond that, I'm not entirely certain. Maybe others can chime in if there are other suggestions.
I haven't been a command line guy since the release of Windows 3.0 and have never yet delved into the bowels of Linux. I've just skated across the surface of ubuntu lately after one failed attempt at getting Debian/BASH to cooperate with my SCSI Card back in '98.
That probably puts me in the class of dinosaurs that flat-out refuse to admit that they're extinct already. =8-/
I think I'll ask for recommendations over at the barracks as well.
FWIW, I've updated my declrom tools to parse out video mode names, video resources, video modes, and video parameter fields. It doesn't parse out CLUTs, but those are only relevant to indexed mode video cards, which apparently (according to Designing Cards and Drivers) is discouraged. The tools are still a bit rough, and command line only.
The catdecl tool parses a DeclROM file and spews out a list of entries it found to stdout.
As an example, I used SlotROM to dump my Radius 24XK video card's ROM, and ran catdecl over it. Video cards are, well, verbose so I won't paste in the whole output. I've attached the output from this ROM as an example. It's ~187KB of output for a 32KB ROM.
Great, I'll take a look when I get home from work tonight. I'm in the middle of building a spreadsheet to change the resolution of my SuperMac Spectrum/24 to a widescreen output. I don't know if there's EEPROM on the Card as well as the standard EPROM or if the resolutions are stored entirely by the driver software. The former would be very handy, the latter wouldn't lend itself to checking for changes at the EEPROM DeclROM level with SlotROM.
Just building the formulas to convert timing tables into inputs for the driver software is teaching me a lot.
As best I can gather from what I've read in Designing Cards and Drivers, and IM: Quickdraw, QD doesn't care about timing. That's left to the card to figure out however it wants. At least, I haven't seen anything in the declrom about timing, only sizes. Vertical blanking interrupts are left to the driver (discovered via declrom) to install programmatically.
Then I guess it's nice that I have at least one NuBus Video Card that has a control panel with a generic driver that'll punch 3MB VRAM worth of pixels out via any way the timings are input. It computes the oscillator freq. and tell you what to plug in to get any given resolution to work.