The Granny Smith emulator

[PappaDF]

I received a lot of valuable feedback and questions about my small emulator project in another thread (https://tinkerdifferent.com/threads/apple-network-server-macos-based-roms-found.4756/post-49737), but I'm creating a new thread here to comment and answer, as this might be a bit of a side track vs. the original thread. Hope that is ok.

But I had to move them manually from the upload folder to the rom folder. I think this should be automatic.

Yes, that should absolutely be automatic. It was probably in part due to the ROMs not being recognized (by checksum). I had only access to a couple of ROM varaints, and never implemented support for all the variants that you tried with. I will see if I can find them (in this thread/forum) and add proper support for the full set. Thanks for highlighting it!

It does not accept both 1.1.20.1 and 1.1.22. Is it just using the 3 MiB 32-bit checksum? The 4 MiB ROMs also have a 64-bit checksum that covers the entire ROM. See DingusPPC romidentity.cpp and MachineFactory::machine_name_from_rom.

I must admit that I didn't think about that problem (different roms <-> same checksum). Should absolutely be fixed. Good input!

If I upload a ROM named "962F6C13", then delete it, and upload one of the 3 ROMs above, then it shows the name as "962F6C13" instead of "1995-08-21 - 962F6C13 - 1.1.20.1 ANS 300 & 500 & 700.ROM". Are the ROMs cached? Can they be renamed?

Yes, roms are cached in opfs, under /opfs/images/rom. Again, based on 32-bit checksum which obviously isn't enough. You can see/browse them if you click on the "Filesystem" tab (or the "Images" tab), but renaming would work poorly, as it currently uses the checksum as canonical names for the rom. Need to sort this out.

Do you know how to skip POST tests during boot? Is it a NVRAM setting or a key switch setting? For example, the DRAM tests for 512 MB take a long time. The testing should appear on the LCD or serial port.

I haven't looked into it a lot, but my understanding was that the only way to completely skip the test is to patch the rom (or running machine) slighlty. (i.e. not nvram or key option to completely bypass). I might be wrong. I will add it to the todo list - nevertheless, there should be a function to bypass it (even if it means patching it a bit)

The Open Firmware console doesn't scroll correctly if I open the lcd device. " lcd" select-dev " hello" write drop. Probably a bug in Open Firmware?

Thanks! - will try to replicate. Most likely a bug in the emulator (that is always the case

A big thank you for taking the time - not only to try it out but to also formulate and write down valuable feedback!

---

Note: AI tools were used when creating this project. I know that it is a red flag for some people, and I want to be completely transparent.

 

[joevt]

Yes, that should absolutely be automatic. It was probably in part due to the ROMs not being recognized (by checksum). I had only access to a couple of ROM varaints, and never implemented support for all the variants that you tried with. I will see if I can find them (in this thread/forum) and add proper support for the full set. Thanks for highlighting it!

I must admit that I didn't think about that problem (different roms <-> same checksum). Should absolutely be fixed. Good input!

All the ROMs are in my fork of MacROMan.
See the doonerom command in the mac_rom_checksums.sh script. It reads and verifies all checksums of a ROM.
Use the script like this:

source mac_rom_checksums.sh
doonerom path_to_rom

Results are in romlist.txt which shows how checksums changed since the Macintosh 128K/512K ROMs up to the last ROMs from 2005.

I haven't looked into it a lot, but my understanding was that the only way to completely skip the test is to patch the rom (or running machine) slighlty. (i.e. not nvram or key option to completely bypass). I might be wrong. I will add it to the todo list - nevertheless, there should be a function to bypass it (even if it means patching it a bit)

My fork of DingusPPC has a command line option for patching the ROM or patching NVRAM.
For many Old World PCI Power Macs, this will bypass tests:
--setnvram "1040=00000000" --comment "disable all POST tests on Old World Macs"
But it doesn't work for ANS ROM (e.g. 1.1.20.1). I can log every NVRAM access that the ROM makes during boot - there may be a clue there.

I've added checksum fixing code to DingusPPC for New World ROMs (i.e. iMac, B&W G3) but not yet for Old World ROMs. I can patch the iMac ROM to support 2 GiB of RAM for example. For TNT machines, I can patch the ROM to support 3.25 GiB. Patches to Old World ROMs don't usually require checksum repair (I've only tested changes in the last 1 MiB of the ROM where ExceptionTables, HWInit, and Open Firmware are located.

I noticed some differences in behaviour for the Grand Central interrupt registers.

cr f3000020 10 bounds do i 8 u.r ." :" i rl@ 8 u.r cr 4 +loop

\ result on real 8600:
F3000020:00000000
F3000024:00100000
F3000028:00000000
F300002C:00000800

\ result with DingusPPC ANS 1.1.20.1:
F3000020:00000000
F3000024:00100000
F3000028:00000000
F300002C:00001000

\ result from Granny Smith ANS 1.1.22.1:
F3000020:00000000
F3000024:00100000
F3000028:00000000
F3000028:00000000

In all cases, the interrupt mask register has the NMI interrupt (bit 0x14) marked as enabled = 0x00100000 which is reasonable.

On my 8600, the interrupt levels register has DMA interrupt 0x0B always set = 0x00000800. I guess that's because it is reserved (unused) - according to the Grand Central ERS document. Both Granny Smith and DingusPPC are missing this (though someone needs to verify that it's the same for a real ANS).

DingusPPC has a bug related to the sc53c94 interrupt (bit 0x0C) being set = 0x00001000 by reset-scsi

DingusPPC and Granny Smith don't appear to support byte sized reads from the Grand Central registers. DingusPPC fixes this for Ohare and Heathrow registers.

F3000020 10 dump

\ result on real 8600:
F3000020: 00 00 00 00 00 00 10 00 00 00 00 00 00 08 00 00

\ result with DingusPPC ANS 1.1.20.1 and Granny Smith ANS 1.1.22.1:
F3000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\ everything is zero even though we know rl@ can read non-zero values.