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
On Sat, 20 Jul 2019, Jd Lyons wrote:
Using ATI ROM Xtender 1.2 with OS 9 and the ATY,Rage128v ‘NDRV’ i.e.
Where did you get Rage128v ROM and is it for Rage 128 instead of Rage128P i.e. Pro? If so it probably not supposed to work.
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
Your trace options are wrong, should have a * at end to enable all ati logs such as:
-trace enable="ati*" -trace enable="pci*"
Then you should see actual traces of what registers were written and what values they got. Then you can look up in register reference docs (can be found on vgamuseum.info, see links to appropriate cards on my qmiga.odsn.io page). But if the ROM is for a Rage 128 and we're emulating a Rage 128 Pro then it's possible the registers of these cards don't match so it shouldn't work. (It would not work with the real card either if you mismatch ROM.)
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
It does seem to program some registers but without correct trace we can't see which.
qemu-system-ppc: /home/jam/aty/qemu/hw/display/ati.c:88: ati_vga_switch_mode: Assertion `bpp != 0' failed. Aborted
However it looks like the values it put in regs are wrong. First question to answer is if the ROM is right for the card and it's supposed to work. If it's for Rage 128 then you can check regs docs of that card (if available) and compare with the Rage128Pro.
But you should probably try with a known correct ROM such as that from Howard. (You can extract the driver from it by cutting from the text Joy! but you probably know that already.)
Regards, BALATON Zoltan
On Jul 20, 2019, at 11:30 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 20 Jul 2019, Jd Lyons wrote:
Using ATI ROM Xtender 1.2 with OS 9 and the ATY,Rage128v ‘NDRV’ i.e.
Where did you get Rage128v ROM and is it for Rage 128 instead of Rage128P i.e. Pro? If so it probably not supposed to work.
The ATI ROM Xtender is a bunch of disk based ‘NDRV’, for the Rage128 they match the “ name” property in the IOreg for our card. Changing the “ name” property you can test each one.
dev /pci/@f “ ATY,Rage128v” encode-string “ name” property boot
ATY,Rage128ns ATY,Rage128n ATY,Rage128o ATY,Rage128v
v1.2 contains these ns is a 32MB gram card, so is n, and o is a 16MB Vram card.
I’m able to get to the Mac OS 9 desktop with all but v albeit only 256 colors or grays, and it doesn’t seem right at 256 colors, really looks like 4bbp color.
These may not be complete ‘NDRV’s or they also rely on needing the full Code ROM, no resolution switching, but it’s progress.
You can also place the ATI ROM Extender in /System/Library/Extensions/AppleNDRV and load it the same as we do for OS 9 i.e. the name property.
They don’t work for OS X, still getting the console message ATY: not usable with all but v, v aborts with the same message as OS 9.
There is a later version of the ATI ROM Extender, I’ll have to see if I can dig it back up.
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
Your trace options are wrong, should have a * at end to enable all ati logs such as:
-trace enable="ati*" -trace enable="pci*”
Thanks I’ll try that.
Then you should see actual traces of what registers were written and what values they got. Then you can look up in register reference docs (can be found on vgamuseum.info, see links to appropriate cards on my qmiga.odsn.io page). But if the ROM is for a Rage 128 and we're emulating a Rage 128 Pro then it's possible the registers of these cards don't match so it shouldn't work. (It would not work with the real card either if you mismatch ROM.)
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
It does seem to program some registers but without correct trace we can't see which.
qemu-system-ppc: /home/jam/aty/qemu/hw/display/ati.c:88: ati_vga_switch_mode: Assertion `bpp != 0' failed. Aborted
However it looks like the values it put in regs are wrong. First question to answer is if the ROM is right for the card and it's supposed to work. If it's for Rage 128 then you can check regs docs of that card (if available) and compare with the Rage128Pro.
But you should probably try with a known correct ROM such as that from Howard. (You can extract the driver from it by cutting from the text Joy! but you probably know that already.)
Regards, BALATON Zoltan
On Sat, 20 Jul 2019, Jd Lyons wrote:
On Jul 20, 2019, at 11:30 AM, BALATON Zoltan balaton@eik.bme.hu wrote: On Sat, 20 Jul 2019, Jd Lyons wrote:
Using ATI ROM Xtender 1.2 with OS 9 and the ATY,Rage128v ‘NDRV’ i.e.
Where did you get Rage128v ROM and is it for Rage 128 instead of Rage128P i.e. Pro? If so it probably not supposed to work.
The ATI ROM Xtender is a bunch of disk based ‘NDRV’, for the Rage128 they match the “ name” property in the IOreg for our card. Changing the “ name” property you can test each one.
dev /pci/@f “ ATY,Rage128v” encode-string “ name” property boot
ATY,Rage128ns ATY,Rage128n ATY,Rage128o ATY,Rage128v
v1.2 contains these ns is a 32MB gram card, so is n, and o is a 16MB Vram card.
You can change how much vram is allocated with the vgamem_mb property (e.g. -device ati-vga,vgamem_mb=32 default is 16 and making it too big or unrealistic sizes probably breaks without warning) but it does not matter, this won't make it work better so probably best to leave it alone and test with a proper rom driver from a real card matching the model we're emulating rather than trying random ones because that just creates confusion because we don't know if it's not working becuase the driver sends wrong data for the card or because of emulation problems.
I'm still not convinced that these are correct. Doesn't Rage 128 Pro has Rage128P in it's name and then a lower case version letter such as p or s which is what I've seen in every device tree dump I've seen so far. So I think Rage128 without P might be a different GPU so drivers for that may not program the card correctly. Therefore you should only test with a driver for Rage128P. Then if it's not working it may be a problem with emulation (or missing setup from FCode ROM part).
Regards, BALATON Zoltan
-
BALATON Zoltan -
Jd Lyons