Re: [Qemu-ppc] ATY 'NDRV'

[BALATON Zoltan]

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