Re: [Qemu-ppc] ATY 'NDRV'

[Jd Lyons]

Ok I enabled ati debuging and with an ‘NDRV’ loaded I get:

ATI_vga_switch_mode 0 > 1

I noted this is in the ati.c but I only understand some of it( 15bit mode???, 
never saw that before;-)

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

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?


> On Jul 19, 2019, at 2:19 PM, BALATON Zoltan <address@hidden> wrote:
> 
> On Fri, 19 Jul 2019, Jd Lyons wrote:
>> Few different things about ATI ‘NDRV’s and the Mac OS/X. Retail ATI cards 
>> tend to have differing NDRV’s than OEM cards. The presence of the ATI ROM 
>> Xtender under OS 9/X can change the ‘NDRV’ loaded from ROM/Openbios.
> 
> Do you know about what's different between these or are these only because of 
> different versions of the driver? I imagine that ATI had developed these 
> drivers and always put the then current version in the cards they shipped. 
> (Then when a bug was found in a ROM of a shipped card the disk based drivers 
> replaced it to fix it as there was no other way to update ROM.) So these 
> driver versions probably mostly do the same but evolved with the cards so if 
> we have a version that's later than the card it might work (unless it's for a 
> completely different chip of course). (The whole ATI line of chips seems to 
> have evolved similarly, starting from a simple VGA chip they've added more 
> and more features and changing the old ones when necessary but mostly keeping 
> for backwards compatibility until it was too much to maintain and then 
> replaced the whole architecture around R600 dropping most of the 
> compatibility stuff.
> 
> In any case I think OS drivers should work with any ROM and any chip version 
> it supports so we only have to pick one ROM version and implement ati-vga to 
> emulate the chip that works with that ROM and we don't have to care about the 
> driver. We probably also don't need a ROM once we find out what the disk 
> based driver needs to load and drive the card so the ROM is only needed until 
> we identify this then we can replace it with an OpenBIOS driver. (We will 
> have to do that becuase the ROMs are copyrighted and cannot be distributed 
> with QEMU. Downloading and trying them may also be illegal actually but until 
> someone/AMD complains it's probably OK as these are old discontinued stuff. 
> But because of this ROMs are only useful for testing not as a final solution.)
> 
>> Also, under OS X /System/Library/Extensions/AppleNDRV/AtiDriver.bundle or 
>> ATI ROM Extender.
>> 
>> I have successfully extracted the disk based ‘NDRV’s for all the Radeon 9200 
>> equipped OS X only GPU’s and made OS 9 ‘NDRV’ disk based drivers as well as 
>> hacked the ATI Accelerator( 2D ) and Radeon 8500 3D driver to work under OS 
>> 9 with full 2D and 3D acceleration. So I understand a little bit how the 
>> drivers work and load.
>> 
>> I also founded to Mac Elite and worked closely with a the edited ROM’s on 
>> the wiki.
>> 
>> In this case I likely just know enough to confuse you or I;-)
> 
> Good to know that at least one of us knows what we are doing because most of 
> the time I don't. I know OSX a bit but don't know OS 9 and had to research 
> ATI cards because I knew nothing about them before trying to implement this 
> emulation. I'm interested in making this work but my primary target is still 
> Amiga like OSes and maybe Linux to get more people involved in this so I only 
> target MacOS and OSX for testing and it's not priority to make them work. I 
> think these and Windows are more difficult than Linux or MorphOS because 
> those have simpler reverse engineered drivers that don't use much of the 
> card's features while Windows and Mac having official ATI drivers probably 
> use every nuance of the card so we need to emulate it more accurately for 
> them to work. It would be easier to start with simpler drivers (with Linux or 
> BSD or Darwin also having the source so we can check what the driver tries to 
> do to undestand what to emulate).
> 
> Also because MorphOS now works and it only lacks video accel that's all I 
> plan to implement for Rage128P then focus on RV100 which will need 3D to work 
> and even simpler drivers want more advanced features so adding those will 
> probably improve R128P as well but once we have RV100 we don't need R128P so 
> the R128P is probably only a first step towards RV100 just to have something 
> working now to try and experiment with but better focus on RV100 now. But 
> again, you said OSX does not use 3D for Quartz on R128P so it might work even 
> before we get to 3D and I believe OS 9 likely also does not use 3D so that's 
> why I wanted to try to get it working with an NDRV to see what it might need.
> 
>> What ‘NDRV’ do we want to use to debug?
>> 
>> We need to set the “ name” property in Openbios to match the ‘NDRV’ we want 
>> to use, for simplicity.
>> 
>> I’ll have to look at the ATI ROM Xtender for OS 9, but for OS X ( 10.4.11 ) 
>> we have:
>> 
>> ATY,Rage128k
>> ATY,Rage128Pk
>> ATY,Rage128Ps
>> ATY,Rage128s
>> ATY,Rage128y
>> ATY,Rage128Pd
>> ATY,Rage128P2ks
>> 
>> I’m not sure if this list only includes retail cards or also OEM cards, and 
>> I don’t have any Rage128 PCI cards to test, but I’m working on getting one.
> 
> I think they include OEM cards too, at least the ROM I've found was said to 
> be for OEM card and it has Rage128Pd. Also Howard (Cat_7) from 
> emaculation.com has a PowerMac3,1 with a Rage 128 Pro card and sent me a 
> device tree dump which has Rage128Ps. The other two dumps I've seen and 
> linked from my Mac99 I2C emulation page at 
> https://osdn.net/projects/qmiga/wiki/SubprojectMac99I2C also have Rage128Ps 
> so I think at least Rage128Ps likely is an OEM card (but I don't have ROM for 
> that so I've picked something that's likely close). I think the driver would 
> work with any of those so we need to emulate one of them. I've picked the 
> specific device ID 5046 based on what I've seen in device tree dumps and this 
> is what the MorphOS driver looks for. So we want to emulate this card but not 
> sure what ROM it has. Howard has dumped the NDRV from his card but that's 
> only the NDRV part not the full FCode ROM. If you can dump the full ROM you 
> can tell him how or work with him to get it if he's willing. Then we know 
> what ROM we have for sure.
> 
>> I’m not that versed in C, so dumb question:
>> 
>> How do I set DEBUG_ATI before I build?
> 
> Just edit qemu/hw/display/ati_int.h and uncomment the #define DEBUG_ATI like 
> this:
> 
> diff --git a/hw/display/ati_int.h b/hw/display/ati_int.h
> index 31a1927b3e..4285a607a6 100644
> --- a/hw/display/ati_int.h
> +++ b/hw/display/ati_int.h
> @@ -13,7 +13,7 @@
> #include "hw/i2c/bitbang_i2c.h"
> #include "vga_int.h"
> 
> -/*#define DEBUG_ATI*/
> +#define DEBUG_ATI
> 
> #ifdef DEBUG_ATI
> #define DPRINTF(fmt, ...) printf("%s: " fmt, __func__, ## __VA_ARGS__)
> 
> This enables DPRINTFs in the code so it will log some stuff so you can see 
> what it does and also adds register names to traces so it helps to see what 
> it's supposed to be or if it logs unknown that's not yet emulated. Enabling 
> DEBUG_ATI helps but then you also need to add -trace enable='ati*' to QEMU 
> command line to enable logging register access. This will create a lot of 
> logs so redirect to a file then you can read it from there. (Please don't 
> send me megabytes of logs because I won't read them, I have no time for that, 
> I can capture my own logs to read.)
> 
>> Also, what version of Linux and MorphOS are you booting and what Qemu 
>> commands are you using to boot?
> 
> This is mostly documented here:
> http://zero.eik.bme.hu/~balaton/qemu/amiga/#morphos
> 
> I use the latest demo iso of MorphOS that's freely downloadable and has a 30 
> minute time limit which is enough for testing. I've found it can change 
> screen mode but sometimes it messes up drawing after that but other times it 
> works so maybe it's a bug in the MorphOS driver or what we do is not quite 
> like real hardware works and that triggers some unexpected behaviour. There 
> could be bugs or differences with screen mode change as this seems to be done 
> differently by every driver and I did not try to emulate this accurately only 
> enough for the OSes I've tried to get picture.
> 
> For Linux any live CD that has rage128fb driver would be OK (x86 ones are 
> easier to come by than ppc), I've installed one for testing in an image where 
> I can experiment but I could not get the Xorg driver to use the card, only 
> frame buffer. I'll probably wait for someone to tell me which image works on 
> real hardware to be sure not chasing Linux driver bugs. MacOS and OSX are 
> known to work but they may need more card features.
> 
> For MacOS I had this command line:
> 
> qemu-system-ppc -M mac99,via=pmu -m 1024 \
> -cdrom "Mac OS 9.2.2 Universal Install.iso" -boot d \
> -net none -device ati-vga,romfile=ati.rom \
> -prom-env 'vga-ndrv?=false' \
> -trace enable='vga*' -trace enable='ati*' \
> -d guest_errors,unimp -serial stdio \
> 2>&1 | fgrep --line-buffered -v "ati_mm_read 4 0xa4" | tee debug-macos-ati.log
> 
> but probably the vga traces are not needed, I had that enabled to see when 
> the VGA and when the ATI regs are poked.
> 
>> I know, I’m not being very helpful, thus far, still trying to understand the 
>> code, what has been implemented and how to be helpful in debugging.
> 
> No, I'm happy that someone is interested and spends time with this and I'm 
> also learning a lot while doing this about ATI card and MacOS and PPC, 
> OpenBIOS etc. that I did not have low level knowledge of so if anyone can add 
> any detail that could help. Also testing with different OS drivers help 
> becuase I don't have time to try everything and analysing register dumps only 
> takes time and effort, no programming knowledge is needed so anyone can help 
> with that. Once we undestand what the driver does by looking at what it 
> programs and reading docs then I can try to implement that in emulation but 
> it takes more time to get there than to actually implement.
> 
>> A few miscellaneous thoughts on OS 9. The Mac OS ROM has a display ‘NDRV’ I 
>> like to call the non-existent hardware ’NDRV’. I will load for any display 
>> device that doesn’t have a ROM or Disk based ’NDRV’. You can see it in the 
>> IOREG as the driver,aaplmacosppc in the IORegistry from the PCIDDK3.0 for 
>> the classic Mac OS.
>> 
>> If we build our own Mac OS ROM we can add ‘NDRV’s’ to the file 
>> /newworld-rom/pef/ndrv/display and they will load so long as they match our 
>> PCI device in name space. That’s not really useful right now, but I just 
>> wanted to say it can be done and sometimes helps. We don’t replace the 
>> non-existent hardware ’NDRV’ we only add another ‘NDRV’.
> 
> Not sure I fully understand this but the problem of NDRV was solved for QEMU 
> stdvga already. This is what the QEMU,NDRV OpenBIOS patches in for everything 
> it recognises as vga. The source of this NDRV is open and included with QEMU 
> so one can see what it does (if you know how to write a MacOS driver). I 
> believe it just uses the Bochs VBE extensions the QEMU vga cards have to 
> switch mode and set up a frame buffer where OS can then render without any 
> acceleration. The ati-vga also has this VBE extension so it may work with the 
> QEMU,NDRV but then it won't be driven by an ATI driver, won't use any ATI 
> card features so it won'd be any better than just using QEMU stdvga so that's 
> not the point of this experiment. We want to have MacOS try to use an  ATI 
> driver even if it won't work yet to see how it programs the card so we can 
> verify the emulation (that what we have is correct and see what else is 
> missing).
> 
>> As far as booting OS 9, the non-existent hardware ’NDRV’ gets us to the 
>> desktop, but we fail to get graphics output with our real ATY,Rage128Pd 
>> ‘NDRV’.
> 
> I think this is the same as I've said above.
> 
>> We do get the Nano Kernel, but it just stalls at the point that the graphics 
>> should load, and booting halts. You can add -prom-env “aapl,debug=3013fff” 
>> along with -serial stdio to get the debug output of the Nano Kernel.
> 
> I knew about this and tried it before but it dit not give me much useful info 
> as we stop within the NDRV which does not print logs.
> 
> I wrote too much already so I stop, maybe later I'll add some more tips on 
> where to look up registers or how to attach debugger to QEMU if you want to 
> disassemble and debug the NDRV but that would probably too much for starting. 
> Maybe check my Qmiga page also having some tips:
> https://osdn.net/projects/qmiga/wiki/DeveloperTips
> 
> As for ati-vga sources, almost everthing is in qemu/hw/display/ati.c When the 
> guest reads or writes the card's mmio registers (or io space which is an 
> alias of first 256 bytes of mmio regs) these will end up in ati_mm_read() and 
> ati_mm_write() functions where all the registers are implemented. These will 
> either get/store the values in the device state structure (defined in 
> ati_int.h) or perform the operations it should based on the register 
> contents. Only a few ops are implemented yet, mostly basic mode switch, 
> display DDC/EDID and some 2D ops but some of the missing ones we don't need 
> (such as clocking, memory controller, secondary CRTC, stereo mode, what have 
> you; these ATI cards are a mess of random functions seemingly grown by 
> evolution rather than careful design). Those that we need are probably video 
> accel/scaler, CCE memory buffers, more 2D ops, then finally 3D.
> 
> Regards,
> BALATON Zoltan