[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] ATY 'NDRV'
From: |
BALATON Zoltan |
Subject: |
Re: [Qemu-ppc] ATY 'NDRV' |
Date: |
Sat, 20 Jul 2019 12:57:09 +0200 (CEST) |
User-agent: |
Alpine 2.21.9999 (BSF 287 2018-06-16) |
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