The "820-0961-A" mystery G3 3.3V FlashRom

croissantking

Well-known member
I haven't put a developer note archive up yet but that's a good idea. I'm in the midst of a big new project on the Laptop Portal at the moment (php + sql database backend), but after that's done I'll probably look to do that next.
Sounds good. Those dev notes are really useful resources and it would be nice to have them in one place.

@stynx has sent me a mystery BootROM and I’ll be trying it out in my Beige G3 and reporting back this weekend.
 

croissantking

Well-known member
So this thing boots up my Beige G3, and reports as 45F3 as we suspected.

IMG_1476.jpeg

IMG_1477.jpeg

Can’t see any functional differences…
 
Last edited:

joevt

Well-known member
How do I dump the ROM?
Can you run Mac OS X? Then you can use my flashrom program. Click on the get-old-world-rom.command file.

Do you have a serial port and another computer? Then you can dump the ROM in Open Firmware. Search for "rom dump" in the first post of the thread at
https://forums.macrumors.com/thread...l-work-in-a-beige-power-macintosh-g3.2303689/
and follow the links.

What I've found so far is that this ROM fails the first test T0 in the Serial Test Manager. A crash sound happens after the boot chime and before Open Firmware begins. Then you end up in the Serial Test Manager.

To get into the Serial Test Manager, you need a serial port connection to the modem port. Then you power on with some button pressed (I'm not sure what button - it might be a jumper on the motherboard or something).
Code:
>
***************************************
*                                     *
*         Serial Test Manager         *
*                                     *
***************************************

T)  Execute a test, single test number follows command
T0) Run ROM Checksum Test
T1) Run Address Line Test
T2) Run Data Line Test
T3) Run Simple RAM Test
T4) Run Mod3 Forward Test
T5) Run Mod3 Reverse Test
T6) Run NVRAM Test
T8) Run AddrPattern Test
T9) Run NTAWord Test
A)  Execute all ROM-based tests
Q)  Quick test
X)  Exit STM (Continue booting)
?)  Print this menu

The ROM Checksum fails. It appears to checksum the entire 4 MB so it is different than the 3 MB ROM Checksum that you see in your screenshot.
 

Attachments

  • flashrom-joevt-10.3 and 10.4-ppc 2024-11-03.zip
    1 MB · Views: 1

croissantking

Well-known member
Can you run Mac OS X? Then you can use my flashrom program. Click on the get-old-world-rom.command file.
Yes, I have a partition with Tiger 10.4.11. I will try this.

What is your doubt? That the previously dumped ROM files might be corrupt?
 

croissantking

Well-known member
@joevt Here you go (attached), I used your flashrom program.

Rom Info: 077d.45f3 "Boot Gossamer 0." 4096 78e842a8 ffffffff x 17d4f2a6023a19f35579d5a87b119a46 "macrom.bin"

Both uploads by @stynx and @dougg3 have MD5 results of da81cd01c7c743f9eb2637465182f591

If I compare the my bin file with those two others, Hex Fiend finds 2104 differences, all 1 or 2 bytes long. Curious! Does this new dump now boot your emulator?
 

Attachments

  • 45f3-croissantking.bin
    4 MB · Views: 8
Last edited:

dougg3

Well-known member
If I compare the my bin file with those two others, Hex Fiend finds 2104 differences, all 1 or 2 bytes long.

Very interesting! Now I'm confused -- I was assuming that since the first 3 MB of the ROM had a good checksum that the chip dumps were probably good, but I guess something is wrong in the last 1 MB? The first difference at 0x38F21C is 0xBB in @stynx's dump but a 0x4B in your dump, and 0x4B is clearly correct based on all of the surrounding repetitive data.

I actually also bought one of these ROM DIMMs from the same eBay seller after this thread was posted, so I can probably add a third data point into the mix as soon as I find some time to boot up my Beige G3 and dump it.
 

joevt

Well-known member
@joevt Here you go (attached), I used your flashrom program.

Rom Info: 077d.45f3 "Boot Gossamer 0." 4096 78e842a8 ffffffff x 17d4f2a6023a19f35579d5a87b119a46 "macrom.bin"

Both uploads by @stynx and @dougg3 have MD5 results of da81cd01c7c743f9eb2637465182f591

If I compare the my bin file with those two others, Hex Fiend finds 2104 differences, all 1 or 2 bytes long. Curious! Does this new dump now boot your emulator?

The first difference at offset 0x38F21C would be at rom address 0xfff8f210. The differences extended to the end of the ROM 0xffffffff.
The tbxi command says BASE+0x380000 with length 0x80000) is the OpcodeTable for the 68K emulator which extends to the end of the ROM.

The @croissantking rom does pass all the Serial Test Manager tests and does boot DingusPPC.
 

stynx

Well-known member
I had unsoldered the chips and scanned them in by using a chip-programmer. I had to clean the chip-legs to get a good contact. Maybe something went wrong at some point?
 

joevt

Well-known member
I had unsoldered the chips and scanned them in by using a chip-programmer. I had to clean the chip-legs to get a good contact. Maybe something went wrong at some point?
Code:
cd "/Volumes/Work/Open Firmware and Name Registry/ROM PowerPC Mac"

xxd "ROM Beige G3 rev D/ROMs/@FFC00000 len-400000.rom" > /tmp/revD_.txt
xxd "ROM Beige G3 rev D2/ROMs/@FFC00000 len-400000.rom" > /tmp/revD2_.txt

xxd -b -c 1 "ROM Beige G3 rev D/ROMs/@FFC00000 len-400000.rom"  | sed -E 's/  .$//' > /tmp/revD.txt
xxd -b -c 1 "ROM Beige G3 rev D2/ROMs/@FFC00000 len-400000.rom" | sed -E 's/  .$//' > /tmp/revD2.txt

diff -y --suppress-common-lines /tmp/revD.txt /tmp/revD2.txt > /tmp/diff.txt

perl -pE 's/\w{7}(.).*/$1/' /tmp/diff.txt | sort | uniq -c
   1 4
 434 5
   2 c
1580 d

0038f21c: 10111011					      |	0038f21c: 01001011
003fe07c: 00111000					      |	003fe07c: 01001011
003fe084: 01001011					      |	003fe084: 00111000

4 = 0100
C = 1100

5 = 0101
D = 1101

fputc(hhdata[offset + 1], outfile); fputc(hhdata[offset + 0], outfile); 000 001
fputc(hldata[offset + 1], outfile); fputc(hldata[offset + 0], outfile); 010 011
fputc(lhdata[offset + 1], outfile); fputc(lhdata[offset + 0], outfile); 100 101 <-- problems
fputc(lldata[offset + 1], outfile); fputc(lldata[offset + 0], outfile); 110 111
The four chips are interleaved. Looks like all the differences are in the LH chip?

Not sure how to explain that the differences exist only when the 3 most significant address bits are 111 = 0x00380000
but actually the differences don't occur until 0038f21c (or 71e43 if you divide by 8) so how did the first 71e43 bytes come through ok?

Maybe it was a timing thing - maybe it worked until it didn't.

Did you read the chips more than once to verify consistent results?

I haven't actually looked at the code to see if it is valid or not.
 

stynx

Well-known member
Did you read the chips more than once to verify consistent results?

I haven't actually looked at the code to see if it is valid or not.
Yes, i did 2 runs and checked the resulting files against each other by the checksum. In between the runs, i removed the chips and reinserted them into the textool-socket. I was quite happy with the results but one chip did most likely not have a perfect contact or maybe it was defective.
 

Dandu

Well-known member
There is a JPEG inside the ROM, like the other ROM. I do not know the method to see this Easter Egg
 

Attachments

  • 45f3-croissantking.jpg
    45f3-croissantking.jpg
    85 KB · Views: 36

CC_333

Well-known member
This is interesting!

So, is this newly discovered ROM effectively for an as yet unknown Rev. D Beige G3? Based on the latest info posted here, it would seem to be little more than a re-versioning of the Rev. C ROM.

Has anyone yet figured out if there are any other differences?

c
 

croissantking

Well-known member
This is interesting!

So, is this newly discovered ROM effectively for an as yet unknown Rev. D Beige G3? Based on the latest info posted here, it would seem to be little more than a re-versioning of the Rev. C ROM.

Has anyone yet figured out if there are any other differences?

c
It looks like it is, but I can’t see any new features or behaviour having run it for a little while in my G3.

rev D adds this line of code for PCI-PCI bridges:
Code:
2008 my_space >pci.cachelinesize config-l!
ChatGPT says:

This line sets the cache line size for PCI-PCI bridges during configuration. It was likely added in Rev D to ensure proper initialization, enhance performance, or fix compatibility issues with specific devices.

Could it have possibly been a fix for the Rev C incompatibility with the Sonnet Tango Trio?

The tbxi parts have more changes (use tbxi to extract). Many ndrvs only have their build date updated.
I wonder if @joevt could expand on the changes to the toolbox?

If we could understand the changes better, maybe it would give us some clues as to what Apple had planned for an unreleased Rev D model.
 
Last edited:

joevt

Well-known member
I wonder if @joevt could expand on the changes to the toolbox?
Timestamp difference ranges:
Rev C: Wed Jun 17 12:54:43 ... 13:54:52 1998
Rev D: Mon Aug 17 06:04:29 ... 07:04:52 1998

Changed resources:
nlib_-16406_InterruptTreeHeathrow.pef has some extra code or something.

That's all I can find other than the Open Firmware change.
 
Top