A couple of additional observations:

1. If the desktop ends up with the bad resolution switch occurring, at that point it can be fixed by temporarily disabling the Monitors control panel and then deleting the Monitors Prefs file and rebooting.  Once the problem is triggered the first time by the combination of everything which causes it, the Monitors control panel is what keeps triggering the bad switch at the desktop from thereafter until I intervene.

2. I ran CineBench's "OpenGL HW-L" benchmark test.  Two things occurred - first, and almost immediately, the known 'rainbow pixel snow' issue appeared, which is supposed to be a problem with the ATI ROM setting too aggressive a VRAM clock.  This is hard-coded into the physical ROM, and I don't know if there is a workaround without some means of editing and re-flashing the ROM.  Secondly, very shortly after the 'pixel snow' began, the screen blanked out and got itself locked into the bad desktop resolution after reboot.  What I've found is if I get good display at the desktop, and the system reports 1920x1080, if you then actually pick the 1920x1080 resolution from the list in SwitchRes or the Monitors control panel, it immediately ends up in the junk mode.  I gather that this situation would occur if any software, such as a game, forces a mode switch and then tries to set it back again upon exit.  I'm not really interested in games fortunately, but I wouldn't want to leave out the possibility entirely.

  In addition to a desire to force a certain video mode at initial boot, it would be nice if the Monitors Prefs file could be overwritten automatically too so it never attempts to switch modes at the desktop once a good boot resolution is established.  SwitchRes can force a mode at the desktop, but as it stands cannot force a workable 1920x1080 mode on my current hardware config.  It has been a dream for as long as I've been toying with Macs that a desired resolution could be forced every boot and not upset by a PRAM/NVRAM/PMU reset.  Even under ideal circumstances it has been incredibly frustrating when you get a system doing exactly what you want it to do and yet it gets fouled up at random by the various resets, especially when it involves multiple monitors.

this shouldn't be here either, take out a 60 day trial period at adrive, this circumvents the downloading problem, if you would like to continue with adrive thereafter it is $2.50 a month. this i what I did to get a few bits and pieces.

You could of course wait for one of the gurus here to sort the present non downloading misery, or even wait for the answer to the question "why it doesn't work" for free.

http://www.game-debate.com/gpu/index.php?gid=757&gid2=113&compare=geforce4-ti-4600-vs-radeon-9200-series

is there a mac based comparison of these two?

I was doing some bench marking of the Gainwood Dual DVI( 4600Ti ) vs. R9200 with some odd results in OS 9 vs OS X.

So far I only tested JK2 and Quake III.

What I found so far is the R9200 is about 75% as fast as the 4600Ti, however when you run out of texture memory on the R9200  things come almost to a halt. You know 128Mb of VRam vs 32Mb.

Jk2 allows a setting for "Very High" textures, and it will bring the R9200 to it's knees, yet the 4600Ti breezes right on( not unexpected ).

The odd part comes with some of the results of the 4600Ti in JK2 OS 9 vs. 10.5.8. Same binary( Carbon ) under OS X is double the frame rate at the same setting, on the same hardware. Setting r_smp 1 doesn't seem to speed things up at all under OS X, even tho in Quake III based games it should off load the sound subsystem to the second CPU and be good for a 15%-20% gain in frame rate, but requires 10.1 or later, so no OS 9 support for SMP in JK2.

Not sure about other Quake III based titles, if SMP worked, ever, under OS 9.

Also, FSAA requires 10.2 in JK2, so no love there for OS 9. The only cards that supported FSAA under OS 9 was the Voodoo cards, and they my have only supported it in Glide games, not Open GL, but I don't know for sure.   

Alright, so here's what I was planning to post about

First-rate detective work as usual, MacOS Plus. Perhaps Daniel could cook up a utility that uses StartLib calls from within 9 to at least set display timings in NVRAM? This would not be very elegant, but I expect that it would find use with a few other Macs.

The thing is, I bought my Mini for $20, it's a nice little toy, and it didn't take me long to hack out the OS 9 drivers for the R9200, but I'm just not looking to invest a bunch of time in decoding the 'NDRV' to work better with some displays.

I only put the time into the Mini I did in order to figure how the OS 9 drivers linked and loaded for ATI cards, because one day I would like to do register level emulation of 3D accelerated graphics for Qemu-System-PPC.

20 years from now, most of this hardware will be gone, or non-working, qemu will endure and allow people to use only Mac PPC applications.

Doesn't mean someone else won't take up the fight with the 'NDRV' issues, I just got it working as well as it can with the 4 displays I keep around, and I don't really see a need to invest more time into a $20 computer. 

Good work so far, darthnVader! Would you consider putting together a "handover" repo that documents your patches and provides the required binaries? For posterity, I have been trying to leave as much of my Mac work online as possible (https://github.com/elliotnunn/cdg5). And somebody (possibly me) might be able to fix this resolution issue, even if it requires some sneaky special-casing. I appreciate any chance to show off my PEF patching stack.

If you do get working on 3D acceleration in QEMU, and you need to instrument some binaries on the Mac OS side, let me know!

  I very much appreciate your work, Darth, as it certainly made for a much better experience for me on my Mini.  I'm not asking You[/] personally to put any further time and effort into it, as others here can probably refine the code later.  (My Mini, and a second one currently in transit to me cost about $100 each, the first one because I thought I was getting a 1.5GHz model but the seller lied, and the second one so I actually end up with a 1.5GHz model - As such I intend to put them to serious work in the studio here running software synths and the like.)  Keep in mind that the unmodified 'stock' ATI drivers caused the same problem anyway.

  As it stands, my workaround is to boot the Mini to OS 9 with the ATI extensions off first so the machine detects the monitor on DVI and stores the working mode, then reboot with the extensions back on to gain back the acceleration.  This sequence preserves the properly timed 1920x1080/60Hz mode from the first boot indefinitely, presumably, unless I switch resolutions or disconnect/reconnect the monitor with the system up.  The monitor, on DVI, is detected correctly by name too in SwitchRes and the Monitors control panel - "W2243" (an LG model).  The only reason I would have for booting once to OS X would be to make VGA work on the following re-boot - DVI works without this trick.

  I presume the 'mechanics' of creating custom timings for OS 9 is complicated given that it was never a feature of any OS 9 or earlier utility that I'm aware of.  It would be great if we could do it, essentially back-porting the function from SwitchResX to SwitchRes, but I don't have any idea of the feasibility.  Maybe some of the coders here know enough to comment.