[BUG] Rhapsody DR1/DR2 installation does not work

[calmsacibis995]

Describe the bug
When the emulated computer restarts to load the Rhapsody installer, it plays the boot chime, but the screen stays black, with no visible sign that anything is loading.

To Reproduce
Steps to reproduce the behavior:

1. Start the emulator with the Rhapsody DR1 ISO attached. Ensure that the computer boots from the CD.
2. Press the Caps Lock key when the "Welcome to Mac OS" message appears.
3. Computer reboots after about 2 seconds.
4. Black screen, boot chime plays normally.

Expected behavior
The Rhapsody kernel loading and the installer showing up.

Screenshots
If applicable, add screenshots to help explain your problem.
Device Information (please complete the following information):

• Device Type: Desktop
• Host OS: Fedora 43 Workstation Edition (Linux 6.19.11)
• Host Processor: AMD Ryzen 7 5700X
• Host RAM: 16 GB
• Guest OS: Apple Rhapsody DR1
• Guest Processor: PowerPC 604 (depends on the machine models below)
• Guest ROM: Power Macintosh 8500, 8600, 9500, 9600
• Guest RAM: 128 MB
• Build Date: 15/04/2026
• Version: Alpha 1.04a (4/1/2026)

Additional context
Add any other context about the problem here.

[calmsacibis995]

This also occurs with DR2. Only instead, after running the installer from the Mac OS 8 side of the CD, the emulator freezes on a black screen after clicking the installer's "Restart" button. The boot chime does play though. My guess is that the emulator currently doesn't support the method used by Rhapsody to boot itself.

[maximumspatium]

This also occurs with DR2. Only instead, after running the installer from the Mac OS 8 side of the CD, the emulator freezes on a black screen after clicking the installer's "Restart" button. The boot chime does play though. My guess is that the emulator currently doesn't support the method used by Rhapsody to boot itself.

My bet is that the above described issue may be related to SCSI, in paticular the MESH controller emulation.
BTW, the original installer in Rhapsody DR1/DR2 has been recently fixed for Beige G3 in 290d8d3
Rhapsody boots up to the kernel but freezes on a halfway before the installer is reached.
That's how it goes so far:

That makes me think that not the booting method but rather disk related issues are currently preventing Rhapsody from working...

[calmsacibis995]

But what about the black screen that occurs after the restart? As far as I can understand, the installer from the Mac OS side simply modifies the NVRAM to boot from the Rhapsody side of the CD. But shouldn't a Happy Mac appear on the screen before booting, or some other indication that the computer successfully restarted? Even if I manually restart the emulator, the screen still appears black, with the boot chime still playing as normal.

This is a log from a Power Macintosh 8500, attempting to install DR1, after the machine reboots:
( 196.094s) hammerhead.cpp:104 INFO| Hammerhead: bank base #25 set to 0x90
( 196.097s) hammerhead.cpp:104 INFO| Hammerhead: bank base #25 set to 0x10
( 196.208s) viacuda.cpp:682 INFO| Cuda: autopoll started, rate: 11 ms
( 196.214s) hostevents_sdl.cpp:318 INFO| Current keyboard state:
( 196.217s) hostevents_sdl.cpp:323 INFO| mod:CapsLock
( 196.842s) bandit.cpp:125 INFO| Bandit-PCI1 address spaces:
( 196.846s) bandit.cpp:131 INFO| - 0x80000000 ... 0x8FFFFFFF
( 196.849s) bandit.cpp:139 INFO| - 0xF2000000 ... 0xF2FFFFFF
( 196.852s) bandit.cpp:139 INFO| - 0xF3000000 ... 0xF3FFFFFF
( 196.855s) bandit.cpp:173 ERR| Bandit-PCI1 err: read attempt from non-existent PCI device 00:0d.0 @00.l
( 196.860s) bandit.cpp:173 ERR| Bandit-PCI1 err: read attempt from non-existent PCI device 00:0e.0 @00.l
( 196.864s) bandit.cpp:173 ERR| Bandit-PCI1 err: read attempt from non-existent PCI device 00:0f.0 @00.l
( 196.868s) memctrlbase.cpp:167 WARN| 0x2000000..0x2000003 already exists in memory region 0x0..0x3FFFFFF
( 196.872s) control.cpp:151 INFO| Control-Video: aperture[0] set to 0x02000000
( 196.879s) bandit.cpp:173 ERR| VCI0 err: read attempt from non-existent PCI device 00:0d.0 @00.l
( 196.883s) bandit.cpp:173 ERR| VCI0 err: read attempt from non-existent PCI device 00:0e.0 @00.l
( 196.887s) memctrlbase.cpp:353 INFO| Added mmio region 0x90000000..0x90000FFF (Control-Video)
( 196.891s) control.cpp:151 INFO| Control-Video: aperture[1] set to 0x90000000
( 196.895s) memctrlbase.cpp:353 INFO| Added mmio region 0x94000000..0x97FFFFFF (Control-Video)
( 196.898s) control.cpp:151 INFO| Control-Video: aperture[2] set to 0x94000000
( 196.907s) sc53c94.cpp:102 WARN| SC53C94: phase latch not implemented
( 198.409s) sc53c94.cpp:300 INFO| SC53C94: resetting SCSI bus...
( 198.413s) sc53c94.cpp:315 INFO| SC53C94: reset interrupt issued
( 198.560s) sc53c94.cpp:238 WARN| SC53C94: command register blocked after RESET!
( 198.563s) sc53c94.cpp:445 ERR| SC53C94: data FIFO underflow!
( 198.567s) sc53c94.cpp:445 ERR| SC53C94: data FIFO underflow!
( 199.041s) ppcmmu.cpp:754 WARN| ... phys_addr=0x640FFFFC
( 199.046s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x6666666E
( 199.050s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666666

Then it seems to hang here:
( 360.255s) ppcmmu.cpp:754 WARN|
... phys_addr=0x666666EA
( 360.259s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x6666666E
( 360.263s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666666
( 360.267s) ppcmmu.cpp:754 WARN|
... phys_addr=0x6666666A
( 360.271s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x666666F6
( 360.275s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x666666E6
( 360.278s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666672
( 360.281s) ppcmmu.cpp:754 WARN|
... phys_addr=0x666666E2
( 360.286s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x666666FA
( 360.289s) ppcmmu.cpp:754 WARN|
... phys_addr=0x66666702
( 360.293s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x666666EE
( 360.297s) ppcmmu.cpp:754 WARN|
... phys_addr=0x666666F2
( 360.301s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666706
( 360.305s) ppcmmu.cpp:754 WARN|
... phys_addr=0x6666670A
( 360.309s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666716
( 360.313s) ppcmmu.cpp:754 WARN|
... phys_addr=0x66666722
( 360.317s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666766
( 360.320s) ppcmmu.cpp:754 WARN|
... phys_addr=0x666667E2
( 360.324s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x66666726
( 360.329s) ppcmmu.cpp:757 WARN| Access to unmapped physical memory, phys_addr=0x666666E6
( 360.332s) ppcmmu.cpp:754 WARN|

[maximumspatium]

But what about the black screen that occurs after the restart? As far as I can understand, the installer from the Mac OS side simply modifies the NVRAM to boot from the Rhapsody side of the CD.

That's true - the installer puts a Forth script into the NVRAM that patches the particular Open Firmware to work with the Mach kernel.

But shouldn't a Happy Mac appear on the screen before booting

No. Happy Mac is displayed after a bootable Mac OS partition was sucessfully located. That happens AFTER Open Firmware passes control to the Mac OS boot loader.
Rhapsody and Mac OS X go another route - those use Open Firmware for loading the Mach kernel from some predefined location. Mac OS loader won't be reached in this case.

or some other indication that the computer successfully restarted?

The startup bong, of course!

Even if I manually restart the emulator, the screen still appears black, with the boot chime still playing as normal.

I see a couple of SCSI related errors like phase latch not implemented or data FIFO underflow! in your log.
Those basically tell us that the SCSI state machine is messed up because the driver attempts to use an unimplemented feature of the Curio controller - the phase latch.
This case needs to be analyzed and implemented for Rhapsody to boot off a SCSI CD-ROM...

[calmsacibis995]

OK, understood. So the entire problem is SCSI related.