Hmmmmm.
Using ATI ROM Xtender 1.2 with OS 9 and the ATY,Rage128v ‘NDRV’ i.e. dev /pci/@f “ ATY,Rage128v” encode-string “ name” property boot
ATY,Rage128ns ATY,Rage128n ATY,Rage128o ATY,Rage128v
qemu-system-ppc -M mac99 -m 512 -hda '/home/jam/os9/os9.img' -device ati-vga -prom-env 'vga-ndrv?=false' -display sdl -prom-env 'boot-args=-v romndrv=1' -prom-env 'auto-boot?=false' -bios '/home/jam/openbios-qemu.elf' -prom-env "aapl,debug=3013FFF" -trace enable="ati" -trace enable="pci" -serial stdio qemu-system-ppc: -trace enable=ati: warning: trace event 'ati' does not exist qemu-system-ppc: -trace enable=pci: warning: trace event 'pci' does not exist
============================================================= OpenBIOS 1.1 [Jul 14 2019 16:58] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 512M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique.
switching to new context:
Nanodebugger activated. Init ready queue 00000000 00000000 00019603 Init ready queue 00000001 00000000 000cb018 Init ready queue 00000002 00000000 006580c0 Init ready queue 00000003 00000000 032c0600 System context at 0x1f7ff100 Vector save area at 0x1f7fb880 SDR1 0x1f80003f Adding blue task 00050001 to the ready queue Starting timeslicing Adding idle task 00070001 to the ready queue NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Priming the system free list with 81 pages. VMMaxVirtualPages: 0005fffe VMLogicalPages: 00000000 Interrupt handler kind: 06 Converting PMDTs to areas CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created CreateArea [ 64000000 6417ffff ] ID 000c0001 placed ... created CreateArea [ 68fef000 68feffff ] ID 000d0001 placed ... created CreateArea [ 68ff5000 68ffefff ] ID 000e0001 placed ... created CreateArea [ 68fff000 68ffffff ] ID 000f0001 placed ... created CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created CreateArea [ f0000000 ffffffff ] ID 00110001 placed ... created CreateArea [ 68f16000 68f16fff ] ID 00120001 placed ... created CreateArea [ deadb000 deadbfff ] ID 00130001 placed ... created Reset system - Into the 68K fire: 0000d032 6806e8c0 ResetSystem trap entered Kernel code base at 0x00f10000 Physical RAM size 0x1fffc000 bytes Created motherboard coherence group. ID 00010001 NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Created system address space. ID 00030001 BATs ffc0007f 00c00043 6800001f 00f00043 00000000 00000000 00000000 00000000 Nanodebugger activated. Init ready queue 00000000 00000000 00019603 Init ready queue 00000001 00000000 000cb018 Init ready queue 00000002 00000000 006580c0 Init ready queue 00000003 00000000 032c0600 System context at 0x1f7ff100 Vector save area at 0x1f7fb880 SDR1 0x1f80003f Adding blue task 00050001 to the ready queue Starting timeslicing Adding idle task 00070001 to the ready queue NKCreateAddressSpaceSub - group at 0x1f7fc1c0 00010001 Priming the system free list with 81 pages. VMMaxVirtualPages: 0005fffe VMLogicalPages: 0001f7c3 Interrupt handler kind: 06 Converting PMDTs to areas CreateArea [ 00000000 1f7c2fff ] ID 000a0001 placed ... created CreateArea [ 5fffe000 5fffefff ] ID 000b0001 placed ... created CreateArea [ 64000000 6417ffff ] ID 000c0001 placed ... created CreateArea [ 68fef000 68feffff ] ID 000d0001 placed ... created CreateArea [ 68ff5000 68ffefff ] ID 000e0001 placed ... created CreateArea [ 68fff000 68ffffff ] ID 000f0001 placed ... created CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created CreateArea [ f0000000 ffffffff ] ID 00110001 placed ... created CreateArea [ 68f16000 68f16fff ] ID 00120001 placed ... created CreateArea [ deadb000 deadbfff ] ID 00130001 placed ... created Reset system - Into the 68K fire: 0002d032 6806c9e8 CPU plugin registered ati_vga_switch_mode: 0 -> 1 ati_mm_write: Display enabled ati_vga_switch_mode: 1 -> 1 ati_mm_write: Display enabled ati_vga_switch_mode: 1 -> 1 ati_vga_switch_mode: 1 -> 0 ati_vga_switch_mode: 0 -> 0 ati_vga_switch_mode: 0 -> 1 qemu-system-ppc: /home/jam/aty/qemu/hw/display/ati.c:88: ati_vga_switch_mode: Assertion `bpp != 0' failed. Aborted
On Jul 20, 2019, at 6:57 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Fri, 19 Jul 2019, Jd Lyons wrote:
Ok I enabled ati debuging and with an ‘NDRV’ loaded I get:
ATI_vga_switch_mode 0 > 1
This just means the driver has enabled extended mode as opposed to VGA mode but this could also happen through OpenBIOS using VBE extension so only those are really the driver that happen after the Swtiching to new context message from OpenBIOS (maybe use -serial stdio to see these in your log). More interesting are the Switching to mode messages that tells what the emulation thinks what mode the driver has programmed the CRTC. This can be cross checked by seeing the register writes before that and decoding it from the docs. Those I've checked so far looked good but I don't think I've verified MacOS yet.
I noted this is in the ati.c but I only understand some of it( 15bit mode???, never saw that before;-)
15 bpp is just RGB555, it's stored in 16 bits but one bit is unused as opposed to RGB565 where the G component gets the additional bit. Maybe MacOS does not tell this difference and just says 16 bit mode but uses RBG555 internally?
Under OS 9 I get the error just after we jump into the 68k fire( right about the point it would draw the Happy Mac to the screen, booting continues, the CPU Plugin is registered and we get to count 9, and booting halts, normally to get to the desktop we would get to count 14 in the Nano Kernel log.
Under OS X I see:
ATI_vga_switch_mode 0 > 1
Just before
ATY: not usable
This is interesting, maybe we can try to find the condition where it decides it's not usable and see why it thinks so. Is this from an open source part of the kernel or from closed source driver?
I see that where we would see: ATY: vram [8100000:0100000]
So something we are doing in ATI_vga_switch_mode isn’t working the way we need it to for the Mac OS, I’m just not sure what that would be?
I'm not sure it's the mode switching part which is wrong here (although could be). But if the driver decides it does not like the card before it tries to switch mode or it expects the FCode to already set up the mode then it's not a problem in ati_vga_switch_mode but that the emulated card is not in a state expected by the driver. I think that's more likely, that's why I'm trying to get the FCode run to have it work the same way as on real hardware and see if that makes it any better. But there are still some work on OpenBIOS to get to that point.
Regards, BALATON Zoltan