The DiiMO Mac II adapter actually is similar and also contains a small patchrom. Maybe someone can make sense of what they might be doing...
I know we had a chat about this but I'm going to dump what I think is going on here so I don't forget it. Bear in mind please that I do not know the Mac II ROM well, and I do not have the time, energy or inclination to disassemble it. However. Let's have a look. Looking at the hex dump, one thing stands out as a flag word: $55AAAA55, in the same location in both ROMs:
$55AAAA55 is a flag value for a diagnostic ROM (thanks
@demik for reminding me where I'd seen it before!). At least on the Mac Plus ROM, this is checked for at a fixed location very early in the boot sequence (see address $4A here):
http://www.toughdev.com/public/plus-rom-listing.asm.txt. If the flag value is found, the following 32 bits are used as an address to JMP to.
The address in this case, on the DiiMo one, is $50F80088. Let's assume that the base of this ROM is at $50F80000, and see whether we get anything sensible disassembling from offset $88 within the ROM. Spoiler: we do (I've added some comments).
I'm not really au fait enough with Motorola MMUs to know exactly what's being done here, but it's fairly obviously setting it up. Let's have a look at the Daystar one. The address after the flag word points at offset $AA, where we find the following similar things happening:
So what these ROMs
mostly seem to be doing is using a diagnostic ROM hook to hook into the boot sequence to set up the MMU nice and early. Presumably, the 800k ROM didn't do this, and so broke, where the FDHD ROM did. (Note that the Daystar ROM is a bit less brute-force than the DiiMo and actually checks whether the OS thinks it has set up the MMU by examining the MMUType low memory global).
This isn't the whole story, though. Both of these also have an obvious flag word at the very start, $AAAA5555. The fact that this is obviously of a piece with the $55AAAA55 flag word, and the fact that it's also in the same place in each ROM, looks suspicious. Looking at the Daystar ROM for a moment, we'll assume that, as with the $55AAAA55 entry point, the following 32 bits are an address. Let's ignore the fact that the first three bytes of the address are different—who has time for that kind of pedantry—and note that offset $2E is the first character after the terminating null of the Daystar copyright string. What's there? Well, it's code, and it makes logical sense:
Putting $808 in cacr seems to correspond to clearing both the data and instruction caches, if I'm reading the manual right. So, while I don't know when this code is being called, it's clearing the processor caches and resetting the MMU's translation control register to a known state. The DiiMo has exactly the same code here, doing the same thing - the only difference being that the offset of the data to be pointed to by the TC register is different.
Why the first three bytes of the address are different in the first hook and the second hook, I don't know, but it obviously isn't totally arbitrary—both the DiiMo and the Daystar have the same discrepancy. I get a vague whiff of 24-bit vs. 32-bit addressing in that the MMU setup hook is somewhere nice and high in 24-bit mode, whereas the cache control one is not - but honestly here someone more familiar with the Mac II needs to weigh in.
