This is where I am currently at:
- New HAL: HALSHINR-0.1-MARKER.
- Both SCSI controllers receive the expected memory addresses and IRQs.
- Interrupts occur on both controllers.
- Final result remains STOP 0x7B — INACCESSIBLE_BOOT_DEVICE, with 0xC0000034.
I'm just the middle-man here as most of my work was carried out by ai, but nevertheless:
This sounds exactly like what my agent hit around wall 18-22 in
https://github.com/pappadf/powermac-nt-hal/blob/main/STORY.md:
"Both controllers get correct memory addresses and IRQs, and interrupts occur, yet the boot device is inaccessible" sounds like you have passed what it called wall 18-21, and that you are now at wall 22 in its list. I'm of course guessing here, but if it's correct, the fix isn't a driver at all - it's four bytes in VENEER.EXE.
What wall 22 is. Before NT will name the boot device, it checks that it's still the same disc the loader booted from. It reads one known sector - 2048 bytes at offset 0x8000, where every ISO 9660 disc keeps its volume header - checksums it, and compares that against the checksum the loader recorded earlier. If the two don't agree, \ArcName\multi(0)scsi(0)cdrom(0)fdisk(0) never gets created, the boot device has no name, and you get OBJECT_NAME_NOT_FOUND.
The catch is that the veneer never read that sector. VrOpen appends ":" + partition digits to the Open Firmware path, and OF answers that on a CD by opening the disc's root directory as a file instead of the raw device - so the read came from inside a 428-byte directory listing. Look for a 2048-byte read at 0x8000 coming back short (428 on the copy my agent used) - on a raw device it could only ever return 2048.
How to confirm this on real hardware, no debugger needed. My agent claims that veneer has an undocumented debug mask, and it's settable from Open Firmware. Pass it on the boot line:
> boot <your-boot-device> -vrdebug 0x1200
0x1000 traces VrRead/VrSeek, 0x0200 traces VrOpen; output lands on ttya, which you'll already have on an ANS. Look for a 2048-byte read at 0x8000 coming back as 428. That's conclusive either way, and costs one boot. (0x2000 additionally prints the argv handed to the loader, which is handy later.)
The fix. Turn the branch at veneer image VA 0x54748 into a nop - file offset 0x4948 in VENEER.EXE, currently 0x4086003C (bne cr1,+0x3c), write 0x60000000. A straight four-byte patch on the copy in \PPC.
Important caveat: that patch is CD-only. It later turned out to make an installed disk unbootable - partition(N) then opens the whole device, offset 0 is the MBR, every filesystem recogniser rejects it, and OSLOADER dies with "Could not access disk partition tables". So take it back out for the disk boot.
You may also need wall 16. The veneer's convert_SCSI_device maps NCR,53C810 -> NCRC810, but the ANS reports NCR,825A, which falls through to UNKNOWN SCSI and Setup's mass-storage screen shows <none>. Eleven bytes at image VA 0x5F420 (file offset 0xF620); Setup then announces Symbios Logic C810 PCI SCSI Host Adapter.
All these offsets are from the OEM 000-48303 CD's VENEER.EXE. If yours differs, note that the veneer ships with its COFF symbol table intact (1512 symbols), so you can locate them by name instead