G4 Cube Internal Speaker Functionality Dilema

[joevt]

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.

 

[joevt]

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.

 

[herd]

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

 

[joevt]

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.

 

[joevt]

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]

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]

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

#                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

 

[GRudolf94]

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]

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]

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]

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]

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]

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.

 

[zefrenchtoon]

Can I share you this post from @Dandu ’s blog ?

A prototype of a Power Mac G4 Cube | Le journal du lapin

www.journaldulapin.com

And on another post we can find a reference to this one:

haplain's never-ending quest

At the request of many from this site here's the transparent prototypes hanging out...

68kmla.org

 

[Nebular]

I've been looking into this since 2020 when I discovered the DAC and the amp chip on the board when doing a repair to it. Even spoke with Hap who has the prototype with the speaker. I got high res photos of the board from him and he started it up to find that there was no sound. My understanding from various rumors I found across the net is that the DAC is there purely for the initial startup chime and that's it. That's why you can only get the chime from the official mac dongle and a very select few 3rd party ones.

This site goes over the 68k and PPC boot process: http://educ.jmu.edu/~jarvislb/utils/macintosh/boot2.htm and the startup chime happens before anything is loaded (most notably the ROM) or any major diagnostics are done. So it would make sense that only the apple dongle would chime as the chime happens even before the USB hardware is initialized.

So what I think is happening, is that the board powers on, turns on the DAC, plays the chime over the USB ports, then shuts it back down. I think the change to external speakers from an internal one was far enough into production that it would have cost more to remove the amp and the speaker connector than to keep them. If it had ever got to a 2nd revision of the motherboard I suspect they would have disappeared.

But the main thing here is that all the communication with the DAC is done at the very beginning before any hardware diagnostics (beyond the most basic) are done or Open Firmware is loaded. So when dealing with dumps from the motherboard firmware, we'd need to be looking into the absolute initial bootstrapping code to find anything that is talking with the DAC. I don't know if any of the firmware updates for the Cube go that deep.

The DAC's i2c and i2s lines are still connected, so in theory we could talk with the chip through those buses in Open Firmware to turn it back on. One would hope that it would just show up as a sound device in OS 9 after that if removing the internal speaker close enough to final production that they left the drivers in. Unfortunetly I'm not much of a programmer and I definitely don't know much about low level programming, even more so in Open Firmware. Over the last 4 years I haven't found much in resources on low level programming on the PPC Macs so I haven't been able to get farther than that.

At this point if we're going to be looking at the Cube firmware, we may need to get dumps directly from the chips on the board as the utilities to dump through the OS may not be able to get to the earliest run code as the various buses haven't been setup yet at that point and it wouldn't be contained on the ROM. The better option might be to focus on communicating on the i2c bus in Open Firmware and see if we can talk to the DAC at all. If anyone has resources on programming for Open Firmware on PPC Macs, I would love to get them as I'm at the end of my skills at this point.