• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

G4 Cube Internal Speaker Functionality Dilema

joevt

Well-known member
I've updated my DirectHW, pciutils, and flashrom forks on GitHub.

flashrom has a new anypci programmer that can read the ROM of any PCI card (as long as the ROM exists and isn't being hidden - my B&W G3 has a FireWire PCI device that says it has an option ROM but it reads as all garbage and the ATI Radeon 9200 seems to have fcode in its Option ROM that does something to make the ROM mostly unreadable later; the Radeon Pro W5700 doesn't have that problem in my Hackintosh; I could use flashrom on an Intel Mac to read the ROM of the 9200 since the Intel Mac won't execute the option ROM).

flashrom has a new anymem programmer that can read any physical range of memory. It can be used to read the Mac's ROM.

Both of those options require DirectHW. Both of those just map memory - they don't do anything with the flash chips.

The attachment has a command "get-new-world-rom.command" that you can double-click to save a copy of the Mac's ROM. It automatically loads the DirectHW.kext, executes flashrom, and unloads DirectHW.kext. The macrom.bin file is saved to the same folder.

The versions in the attachment are meant for PowerPC Mac OS X 10.4 (and probably 10.5). They have to be recompiled for later macOS versions.
 

Attachments

  • flashrom-joevt-10.4-ppc.zip
    442.9 KB · Views: 2

joevt

Well-known member
The previous version had an error in the script. I also replaced the executable with one that hopefully doesn't require installing extra libraries from Homebrew or whatever.
 

Attachments

  • flashrom-joevt-10.4-ppc.zip
    490 KB · Views: 5

herd

Well-known member
Thank you joevt, great work! Here is the ROM from my Cube obtained using your build of flashrom:
 

Attachments

  • Cube4.1.9f1.rom.zip
    791.3 KB · Views: 2

joevt

Well-known member
Thank you joevt, great work! Here is the ROM from my Cube obtained using your build of flashrom:
The ROM appears to be identical to that of an iMac G3 (Slot Loading) except for some NVRAM stuff.

4.19f1 is the earliest ROM with version 4.x.x. Maybe it's the first to support USB and FireWire booting.
https://68kmla.org/bb/index.php?thr...-imac-g3-from-usb-challenge.46660/post-521937

I see there was a G4 Cube with 3.2f1 but I don't have that ROM.
4.1.9f1 is a firmware update for multiple G4 computers and the iMac G3 (Slot Loading).
https://www.macintoshrepository.org/28557-g4-cube-firmware-update-4-1-9
https://www.macintoshrepository.org/24108-imac-g3-firmware-update-4-1-9

What does the G4 Cube say for the model number? The output from the following would be useful:
dev / ls unselect-dev " devalias" evaluate " printenv" evaluate dump-device-tree words
See #37

I've attached dumps of both of them. It seems there's a regression in capstone PPC disassembly producing inferior results in the G4 Cube Part1.txt dump compared to my earlier dump of the iMac's ROM.
 

Attachments

  • 4.1.9f1.zip
    2.6 MB · Views: 0

joevt

Well-known member
Correction: There's some differences at 0xfff030a0, 0xfff03ef0 in the Start part and 0xfff84740 in the Recovery part (outside the NVRAM parts) between iMac and Cube.
 

joevt

Well-known member
And of course the differences describe the differences in hardware including audio.

0xfff03efc is probably a checksum for the bytes in the Start part.
The 0x100 bytes at 0xfff03f00 (the end of the Start part) is copied to config-block.

0xfff03f0e is a byte in the config-block where the upper 3 bits when set to 0 cause probe-usb-audio to be executed. In the iMac, the bye is 0x7a. In the Cube, the byte is 0x06.

The config-block contains the info for product-id, product-family, product-platform, product-version, sys-config-rev, product-code. I guess these end up providing the info for the PowerMac2,1 or PowerMac5,1 model names (for iMac and Cube respectively).

Also these bits:
reg-cke?
ultra66?
ivad?
on-board-processor?
sound-architecture
max-aux-power
prod-sys-rev
bus-clock
usb-current-avail
has-v-step?
has-tv-on-audio?
pci-clocks
platform-mac-address
product-group
firewire-clock-off?
platform-name
product-family
product-platform

sound-architecture can be one of many values:
00: i2s; i2s-a, i2sbus; i2s-b;
01: extint-gpio12, keywest-gpio12; i2s; i2s-a, i2sbus; sound, daca, 353S0228;
02,03,04,05: Screamer; davbus; screamer, awacs 343S0184;
08: (tangent-sound) gpio5, keywest-5;
09: (tessera-sound) same as 0a but adds extint-gpio3, keywest-gpio3 .DallasDriver
0a: (marble-sound) gpio1, keywest-1; gpio9, keywest-9; extint-gpio4, keywest-gpio4; extint-gpio12, keywest-gpio12
 

joevt

Well-known member
The differences at 0xfff030a0 are CPU PVR related - they look like the differences between a Mac Mini G4 ROM and @dosdude1's patched Mac Mini G4 ROM. It's PowerPC code that checks the CPU PVR before Open Firmware is loaded.

The iMac firmware looks for CPU:
0x0008 = G3 740, 750, 750CX, 750CXe, 740P, 750P, 745, 755
0x000C = G4 7400
0x800c = G4 7410
0x8000 = G4 7550, 7451, 7441
0x8001 = G4 7445, 7455
0x0003 = 603
0x0006 = 603e
0x0007 = 603ev, 603r

The G4 Cube replaces the last three with these:
0x8002 = G4 7447, 7457
0x8003 = G4 7447A

Code:
#                iMac                               G4 Cube

 0  7c 7f 42 a6  mfpvr  r3             7c 7f 42 a6  mfpvr   r3
 4  54 63 84 3e  srwi   r3, r3, 0x10   54 63 84 3e  srwi    r3, r3, 0x10
 8  28 03 00 08  cmplwi r3, 8          28 03 00 08  cmplwi  r3, 8
 c  40 82 00 0c  bne    0x18           40 82 00 0c  bne 0x18
10  4d 6b 5a 42  crset  cr2un          4d 6b 5a 42  crset   cr2un
14  48 00 00 70  b  0x84               48 00 00 70  b   0x84
18  28 03 00 0c  cmplwi r3, 0xc        28 03 00 0c  cmplwi  r3, 0xc
1c  40 82 00 0c  bne    0x28           40 82 00 0c  bne 0x28
20  4d 08 42 42  crset  cr2lt          4d 08 42 42  crset   cr2lt
24  48 00 00 60  b  0x84               48 00 00 60  b   0x84
28  28 03 80 0c  cmplwi r3, 0x800c     28 03 80 0c  cmplwi  r3, 0x800c
2c  40 82 00 0c  bne    0x38           40 82 00 0c  bne 0x38
30  4d 08 42 42  crset  cr2lt          4d 08 42 42  crset   cr2lt
34  48 00 00 50  b  0x84               48 00 00 50  b   0x84
38  28 03 80 00  cmplwi r3, 0x8000     28 03 80 00  cmplwi  r3, 0x8000
3c  40 82 00 0c  bne    0x48           40 82 00 0c  bne 0x48
40  4d 4a 52 42  crset  cr2eq          4d 4a 52 42  crset   cr2eq
44  48 00 00 40  b  0x84               48 00 00 40  b   0x84
48  28 03 80 01  cmplwi r3, 0x8001     28 03 80 01  cmplwi  r3, 0x8001
4c  40 82 00 0c  bne    0x58           40 82 00 0c  bne 0x58
50  4d 4a 52 42  crset  cr2eq          4d 4a 52 42  crset   cr2eq
54  48 00 00 30  b  0x84               48 00 00 30  b   0x84
58  28 03 00 03  cmplwi r3, 3          28 03 80 02  cmplwi  r3, 0x8002
5c  40 82 00 0c  bne    0x68           40 82 00 0c  bne 0x68
60  4d 29 4a 42  crset  cr2gt          4d 4a 52 42  crset   cr2eq
64  48 00 00 20  b  0x84               48 00 00 20  b   0x84
68  28 03 00 06  cmplwi r3, 6          28 03 80 03  cmplwi  r3, 0x8003
6c  40 82 00 0c  bne    0x78           40 82 00 0c  bne 0x78
70  4d 29 4a 42  crset  cr2gt          4d 4a 52 42  crset   cr2eq
74  48 00 00 10  b  0x84               48 00 00 10  b   0x84
78  28 03 00 07  cmplwi r3, 7          60 00 00 00  nop 
7c  40 82 00 08  bne    0x84           60 00 00 00  nop 
80  4d 29 4a 42  crset  cr2gt          4d 4a 52 42  crset   cr2eq
 
Last edited:

GRudolf94

Well-known member
Interesting to see the sound-architecture byte includes a value for AWACs. Anyway, there's our answer - it's probably 00 on the Cube, whereas for sound to be enabled it should be 01? (Given 'daca' is what it'd need to work)
 

joevt

Well-known member
The G4 Cube at #24 has an older firmware. I don't know if firmware 3.2f1 has a config-block. The firmware should probably be updated.

G4 Cube with 4.1.9f1 firmware has sound architecture 0.
The iBook at #19 is sound architecture 1.
Sawtooth has screamer (sound architecture 2).
iMac G3 has screamer (sound architecture 3).

It appears that setting up the sound device happens before nvramrc can be executed. Check .time-stamps output. sound happens after the gpio item and before the escc item. Some sound items happen after that before via-pmu. device-tree is finished at device-tree done. nvramrc happens after start COLD-INIT.

The sound setup code is not in a colon word (not compiled fcode) - it is in the interpreted fcode. Therefore, you would need your own code (in nvramrc or in a file) to add all the properties yourself or modify the config-block in the ROM.
 

Arbee

Well-known member
Correction: There's some differences at 0xfff030a0, 0xfff03ef0 in the Start part and 0xfff84740 in the Recovery part (outside the NVRAM parts) between iMac and Cube.
So the 4.1.9f1 iMac isn't the same as the 4.1.9f1 Cube? Oh, Apple.
 

joevt

Well-known member
So the 4.1.9f1 iMac isn't the same as the 4.1.9f1 Cube? Oh, Apple.
The config-block contains most of the differences. The System Configuration Block Format is documented in the Yosemite ERS even though the the original iMac and B&W G3 did not include a System Configuration Block. The format of the System Configuration Block has changed since that ERS. The byte containing the sound-architecture was at offset 0x0c but in 4.1.8f5 (and possibly earlier?) it is now at offset 0x0e with extra values stored at 0x12 when the 3 most significant bits of 0x0e is 7. The Quad G5 ROM 5.2.7f1 uses only the byte from 0x12 for the sound-architecture, though the firmware does support the sound architecture from 0x0e+0x12 when the first 2 bytes of config-block (version?) is c99c (which is used by all the Power Macs prior to the Quad G5?).
 

Arbee

Well-known member
The config-block contains most of the differences.
That makes sense. Are there differences other than the config-block and NVRAM regions? If so, it might be possible to use newer firmware with more capabilities on machines that didn't actually have it in some cases, similar to how the IIsi ROM can make the II/IIx/IIcx/SE30 32-bit clean.
 

joevt

Well-known member
That makes sense. Are there differences other than the config-block and NVRAM regions? If so, it might be possible to use newer firmware with more capabilities on machines that didn't actually have it in some cases, similar to how the IIsi ROM can make the II/IIx/IIcx/SE30 32-bit clean.
Just the list of CPUs in #47
A newer firmware will have many differences but they might work with older Macs if nothing was removed from the older firmware. All you would have to do is copy the config-block. If something was removed, it could be restored if you know how to put the piece back together again.
 
Top