Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Nice it finally works!

...and good idea to set the GPU-clock back to 350. That's what most of the 6200s run. 200 would have been terribly slow. But, as you did find out, overclocking the RAM beyond it's specs is one thing they don't really like. So stupid thing the former owner has done. I doubt that it ran smoothly in Windows that way.
But I was worried it may corrupt the mac rom, so after changing the rom, I used Hex Fiend on my Mac to open both roms and do a compare..
Nice find, that NiBitor doesn't mess up fCode ROMs didn't know that and would have feared to use it too.
to make sure and yes it only changed the two values. So I started poking about a bit more. I think in timings area one still needs to be careful not to mess up the 0115011212FC string.
You only need to be careful that the gap between the 0115011212FCs allways stays at FC bytes. Exception the last two where the last byte of the first one shows the length of gap.
 
I wasn't able to boot OS9, but did get a white screen on one of my tests I think. I downloaded the updated 2.1.1 Geforce drivers for OS9, haven't installed them. Wondering if any of those hacks like changing the device ID in the driver is possible.

So far I have not been able to get my Powercenter Pro to boot with the 6200. It has integrated ATI Rage, no matter what slot I put it in, also can't do PRAM reset with the card in. Can't boot to OS9. Just black screen on both cards.
Its Catalyst based, so like Powermac 7200/8200.

But haven't tried Joevt new rom.
 
Right. Is 6200 supposed to work in Mac OS 9 on New World Macs?
Because the New World ROM has the "Non-Existent Hardware" 'NDRV' for any frame buffer device handed off from Firmware. Well, the versions of Mac OS 9 anyway.

The version of the Mac OS ROM for OS 8.6 and older don't have it, this generic FB 'NDRV'.

Old Would BootROMs don't have it either.

Maybe we can extract it( pip3 install tbxi ) and package it as an OS 9 style extension. I'm not sure that will work or not, but it's worth a shot.

It depends if OS 9 continues to boot on these Old World Macs with the 6200 installed, if booting just hangs when loading the Old World ROM, before it scans the Extensions folder for 'NDRV's it won't work tho.
 
IMG_6029_MOV_AdobeExpress-2.gif


Core Image Ripple effect.. with G3 cpu in Tiger.
Tried to run Open Mark benchmark, but it bombs on start, guessing it needs G4?
 
  • Like
Reactions: LightBulbFun
It depends if OS 9 continues to boot on these Old World Macs with the 6200 installed, if booting just hangs when loading the Old World ROM, before it scans the Extensions folder for 'NDRV's it won't work tho.
In my case OS 9 boots just fine with the 6200 installed. The card is even seen by System Profiler as it appears under Tiger's System Info. I just don't get no signaling to the display from it.
 
Thanks to Open Firmware 2.4 for having all the fcode names, and dingusppc for being able to use Open Firmware 2.4 and @flyproductions for getting the info and testing.
Information is worth nothing if one does not know how to make use of it! 😉

So very interesting to see, you were on the right track - which now led to success - more than ten years ago! Might be just that long i have this very nice card in my collection, which sadly i never had real use for as any machine in my posession that could run it had much stronger options for the AGP. But that finally changed...

Should have found (or started) this thread somewhat earlier! 😊
 
Last edited:
I have a EVGA 6200 PCI (512MB) so maybe I can help at some point (Have two oldworld mac clones, Powercentre Pro and Powertower Pro, e.g. Catalyst, and a Tsunami architecture. The Powertower has 6 slots, bandit PCI bridge). Also have a MDD that is apart right now, but can put it back together and stick the 6200 card in also. That has Leopard & OS 9 on it. The clones just have OS9 & OSX Panther (but hope to get Tiger on them shortly, and Leopard once I figure out what is wrong with my ebay special Sonnet G4 upgrade).
Kind of too bad, as that EVGA does have a 2mb flash instead of 64kb (and 512mb onboard memory).
Here are the PC and Mac ROMS for the EVGA 512MB PCI card:
On a G5 with a EVGA PCI 512MB card that is picky as hell. The debug rom did finish but did not produce any display when I booted Tiger.

The ROM I made with the ROM Maker also finished and I was able to get a rather garbled display out of it when I booted Tiger, but booting halts at the window server and just hangs there, in safe mode KP.

I hand edited the ROM I got from the 64k ROM Maker and fixed a few things, sadly still the same as before, garbled display and no window server.

I tried to make a ROM with the ROM Maker that doesn't reduce the rom, but it goes to abort soon after it sets the subsystem-id to 0x10 and all I get are the open and close words.

OF reports "VRAM,memsize 20000000 20000000, with my garbage ROM I made from the ROM Maker@joevt that's 512MB right?
So the card doesn't even work in New World machines?

Is in this case 512MB a problem as for the AGP-cards? I also had one low profile AGP 512. Don't even know the brand anymore. But i never got it to work with 512MB. Could boot in safe boot with System Profiler showing 512MB. But as soon as i tried booting this ROM with drivers loading: Hang or KP! With a 256MB ROM the card worked normal.
Yes, that's 512 MB. That's one eighth of the 32 bit PCI config space. I don't know if that's a problem.
thats an interesting one I wonder if that has anything to do with why my Quadro FX 4500 wont play ball in my PCI to PCIe setup, as thats a 512MB card

I was wondering if that its taking up to much memory space, as described in the PowerMac G4 fun thread, the system will see it an load its fCode ROM and i can see all its properties just fine in the device tree but the moment i go to plug in a display it all falls over an OF will just hang at display int, or in the case of the G3 blue and white display garbled rubbish and hang

so I was wondering if it was a memory space/overlap issue

@DearthnVader is there a quick and dirty way to disable half the VRAM of an fCode NVIDIA ROM? would be interesting to nerf the card to 256MB and see if behavour changes

(much like how its been suggested to try a 256MB ROM with your 512MB 6200 just to verify things)

I know back in the day MacVidCards was never able to get the full 512MB of the Gainward 7800 GS working, he could get the card to work just fine as a 256MB card but not as a 512MB one

I always wondered if it was an AGP GART issue but now I wonder perhaps it is an address space issue?
I got all 512 MB to work just fine on a SP 1.8Ghz G5 with a 6200 AGP.
I remember looking into this a while back and I cant remember if it was on here or the Strange dog forums but I seem to recall MVC and Co did try 512MB AGP versions of the 6200 and ran into the same Gainward 7800 GS issues

thats why I asked about details on the 512MB PCI card when you mentioned it here

I did not do anything special, just 64k rom maker and a windows tool arti wrote to edit the nvstrap to hard set 512mb vram and ignore the cards resistors.
If people have gotten 512MB cards to work in the past then it might not be a problem.

Old World Macs had max 1.5 GB RAM (9500/9600). They are 32 bit and the PCI memory is mapped into the 32 bit address space and accessed with regular PowerPC load and store instructions.

I would check all the assigned addresses for all memory mapped base address registers to see where they were set in relation to each other and RAM and ROM. Maybe the order in which they are probed matters. Also check the memory ranges of the host bridge and other bridges. The lspci command I created for Open Firmware can get all the bytes of PCI config space and I wrote a script to decode the bytes in Mac OS X.
Yes, this i can confirm!

i didn't even know that i still have the card. But found it in a forgotten stack in the basement.

View attachment 2049248

View attachment 2049247

It's also PNY, but has a pcb very similar to some Club 3D which is 256MB. So with the Club 3D's ROM it worked just fine. 256MB, of course. But i spend alot of time, trying to get it to work with all the 512MB, comparing to the PC ROM or adapting things from the experiments with the Gainward Bliss. I got to the point where it showed 512MB after a safe boot, but never got it to fully boot to the OS with one of these ROMs.
I haven't given up on the 512MB card, but I'm at a loss on getting a working ROM for it. There is some stuff about the PSTRAPS/nVSTRAPS that doesn't always translate from PC to Mac even when you copy the strap directly over from the PC ROM to the FCODE ROM.

I remember I would always used Arti's Windows based Strap editor to hard set a few values after I used the ROM Maker. The ID in the the tables and the amount of VRAM, but I don't have that tool anymore.....

Sometimes the active timing table set in the STRAP( 0-7 ) isn't always honored when we put the FCODE ROM on, as well as the VRAM Size. I think there is a VRAM Size register set later in the ROM, but the STRAP needs the override and needs to match the size set in the register. It got to the point where I would just do both overrides on any card I flashed and I has zero issue, tho I never tested Leopard as it had not shipped yet.
Buy the way: A pity the 6200 512MB ROM is lost. I wasted a lot of time, trying to get the PNY 6200 and earlier the Gainward Bliss to run with all of their memory. But have never seen the complete 512MB out of a safe boot.
When I ran V5 of JoeVT's debug ROM on the G5 it did produce a display on the card, but it was all garbled do to the differences, but that gives me hope I can fix the 512MB cards ROM as it also has BGA RAM.

I noted the CI says it is supported, but I don't get the ripple effect in the Dashboard, does that work on your PCI 6200?

QE seems to work fine tho.
I've been looking at how a 512MB card might behave on Open Firmware 2.4 (and therefore 2.0f1. and 1.0.5 with map-in nvramrc patches).

They don't have the code to map-in BARs that are > 256 MB but I believe Open Firmware 4 (from my Quad G5) does. I suppose I could make a patch to fix this for older Open Firmware versions. I didn't check the Open Firmware from Sawtooth or B&W G3. I should work on how to decompress the ROMs from those and the Quad G5 and any other new world ROMs I have so I can look at their (alloc-mem-addr) functions as Forth code.

Here's the Open Firmware 2.4 version (Forth code obtained from fcode image):
Code:
: (alloc-mem-addr)															
	{ local_pciBridgeInfo ; local_size local_newMemAddr local_savedMemAddr }
	h#1000																	
	max																		
	-> local_size															
	local_pciBridgeInfo														
	>as.next-mem-addr														
	@																		
	-> local_savedMemAddr													
	local_size																
	log2																	
	local_pciBridgeInfo														
	(align-mem-addr)														
	-> local_newMemAddr														
	local_pciBridgeInfo														
	>as.mem-addr-max														
	@																		
	local_newMemAddr														
	local_size																
	+																		
	u<																		
	if																		
		local_pciBridgeInfo													
		>as.mem-addr-max													
		@																	
		h#10000000															
		0																	
		['] claim-real														
		catch																
		if																	
			3drop															
			local_savedMemAddr												
			local_pciBridgeInfo												
			>as.next-mem-addr												
			!																
			0																
			exit															
		else																
			-> local_newMemAddr												
			local_newMemAddr												
			h#10000000														
			map-range														
			local_newMemAddr												
			h#10000000														
			+																
			local_pciBridgeInfo												
			>as.mem-addr-max												
			!																
		then																
	then																	
	local_newMemAddr														
	local_size																
	+																		
	local_pciBridgeInfo														
	>as.next-mem-addr														
	!																		
	local_newMemAddr														
	;

Here's the Open Firmware 4 version (compiled fcode obtained from dictionary dump):
Code:
FF885A8D: b(:) \ [0x0b7] 0x1bce (alloc-mem-addr)
FF885AA8: 967E FFFC                       stwu     r19,-4(r30)             
FF885AAC: 7E68 02A6                       mflr     r19                     
FF885AB0: 4BFC 17A1     FF847250          bl       (pushlocals)+8          
FF885AB4: 4BFC E0CD     FF853B80          bl       h#1000                  
FF885AB8: 4BFC 4451     FF849F08          bl       max                     
FF885ABC: 4BFC 1895     FF847350          bl       (local!)+16             
FF885AC0: 4BFC 17E9     FF8472A8          bl       (local@)                
FF885AC4: 4BFF E6F5     FF8841B8          bl       >as.next-mem-addr       
FF885AC8: 4BFC 27A9     FF848270          bl       @                       
FF885ACC: 4BFC 18A5     FF847370          bl       (local!)+48             
FF885AD0: 4BFC 17E9     FF8472B8          bl       (local@)+16             
FF885AD4: 4BFD 379D     FF859270          bl       log2                    
FF885AD8: 4BFC 17D1     FF8472A8          bl       (local@)                
FF885ADC: 4BFF FF65     FF885A40          bl       (align-mem-addr)        
FF885AE0: 4BFC 1881     FF847360          bl       (local!)+32             
FF885AE4: 4BFC 14E5     FF846FC8          bl       (begin)                 
FF885AE8: 4BFC 17C1     FF8472A8          bl       (local@)                
FF885AEC: 4BFF E6FD     FF8841E8          bl       >as.mem-addr-max        
FF885AF0: 4BFC 2781     FF848270          bl       @                       
FF885AF4: 4BFC 17D5     FF8472C8          bl       (local@)+32             
FF885AF8: 4BFC 17C1     FF8472B8          bl       (local@)+16             
FF885AFC: 4BFC 3A75     FF849570          bl       +                       
FF885B00: 4BFC 4211     FF849D10          bl       u<                      
FF885B04: 4BFC 1525     FF847028          bl       (b?branch)              
FF885B08: 4800 0090     FF885B98          b        $+144                   
FF885B0C: 4BFC 179D     FF8472A8          bl       (local@)                
FF885B10: 4BFF E6D9     FF8841E8          bl       >as.mem-addr-max        
FF885B14: 4BFC 275D     FF848270          bl       @                       
FF885B18: 4BFF EDA1     FF8848B8          bl       h#10000000              
FF885B1C: 4BFC 3645     FF849160          bl       0                       
FF885B20: 4BFC 0AA9     FF8465C8          bl       b<'>                    
FF885B24: FF87 FF48     FF87FF48          dc.l     claim-real              
FF885B28: 4BFC 02E9     FF845E10          bl       catch                   
FF885B2C: 4BFC 14FD     FF847028          bl       (b?branch)              
FF885B30: 4800 0044     FF885B74          b        $+68                    
FF885B34: 4BFC 145D     FF846F90          bl       b<">                    
FF885B38: 0D ...                          dc.b     " catch occured" 
FF885B48: 4BFC 0A59     FF8465A0          bl       b<lit>                  
FF885B4C: FF88 5A88                       dc.l     0xFF885A88              
FF885B50: 4BFD CFE9     FF862B38          bl       (time-stamp-hdr)        
FF885B54: 4BFD 342D     FF858F80          bl       3drop                   
FF885B58: 4BFC 1781     FF8472D8          bl       (local@)+48             
FF885B5C: 4BFC 174D     FF8472A8          bl       (local@)                
FF885B60: 4BFF E659     FF8841B8          bl       >as.next-mem-addr       
FF885B64: 4BFC 2805     FF848368          bl       !                       
FF885B68: 4BFC 35F9     FF849160          bl       0                       
FF885B6C: 4BFC 0935     FF8464A0          bl       exit                    
FF885B70: 4800 0024     FF885B94          b        $+36                    
FF885B74: 4BFC 30C5     FF848C38          bl       dup                     
FF885B78: 4BFF ED41     FF8848B8          bl       h#10000000              
FF885B7C: 4BFF EB05     FF884680          bl       map-range               
FF885B80: 4BFF ED39     FF8848B8          bl       h#10000000              
FF885B84: 4BFC 39ED     FF849570          bl       +                       
FF885B88: 4BFC 1721     FF8472A8          bl       (local@)                
FF885B8C: 4BFF E65D     FF8841E8          bl       >as.mem-addr-max        
FF885B90: 4BFC 27D9     FF848368          bl       !                       
FF885B94: 4BFF FF50     FF885AE4          b        $-176                   
FF885B98: 4BFC 1731     FF8472C8          bl       (local@)+32             
FF885B9C: 4BFC 171D     FF8472B8          bl       (local@)+16             
FF885BA0: 4BFC 39D1     FF849570          bl       +                       
FF885BA4: 4BFC 1705     FF8472A8          bl       (local@)                
FF885BA8: 4BFF E611     FF8841B8          bl       >as.next-mem-addr       
FF885BAC: 4BFC 27BD     FF848368          bl       !                       
FF885BB0: 4BFC 1719     FF8472C8          bl       (local@)+32             
FF885BB4: 4BFC 08EC     FF8464A0          b        exit

You see the Quad G5 version has a loop (begin) ... b $-176 that the 2.4 version does not.
In both cases, they seem to map 256MB at a time.
I guess the G5 version maps until enough has been mapped for the requested size.

Notes about BARs:
A BAR is a four byte register (for 32 bit BARs) that represents the physical address where it is mapped. The BAR is also used to determine its size. The fcode writes FFFFFFFF to the BAR and it returns F0000000 for 256MB and E0000000 for 512MB. Note how only the upper bits were changed. This means that the address in the BAR must be a multiple of the BAR size.

In the case of 256MB, if the next address assignable to a BAR is 83000000, then the next address which is a multiple of 256MB is 90000000. OF 2.4 will try to claim-real 256MB at that address but that fails so it does a map-range which succeeds.

In the case of 512MB, the next address should be A0000000 (multiple of 512MB) but the code only tries to allocate 256MB and the result address is 90000000. The BAR gets assigned 80000000 since bit 28 can't be 1. But 80000000 is used by other BARs. Mayhem ensues.

Code:
0 > dev pci/@e .properties

reg                     00007000 00000000 00000000  00000000 00000000 
                        02007010 00000000 00000000  00000000 01000000 
                        02007018 00000000 00000000  00000000 01000000 
                        42007014 00000000 00000000  00000000 20000000 
                        02007030 00000000 00000000  00000000 00020000 

VRAM,memsize            10000000 10000000 

assigned-addresses      82007010 00000000 82000000  00000000 01000000 
                        82007018 00000000 81000000  00000000 01000000 
                        82007030 00000000 80800000  00000000 00020000 

dev pci 7014 config-l@ cr u. 
8
I need to see where VRAM,memsize is coming from and what mechanism causes BAR 1 (reg 14) to not be included in the assigned-addresses. The fcode creates the reg property. The rom fcode somehow converts that to assigned-addresses.
 
I should work on how to decompress the ROMs from those and the Quad G5 and any other new world ROMs I have so I can look at their (alloc-mem-addr) functions as Forth code.
Nice work again!

Sadly these Quads have no regular PCI Slots. Would make testing with the 512MB cards easier.
 
Does anybody know where XPF stores the defaults it writes to the nvramrc, everytime it is used? Find it a bit annoying, it allways overwrites everything when i. e. only used to switch the startup disk. So i would very much like to edit this to my needs.
 
  • Like
Reactions: flyproductions
It depends if OS 9 continues to boot on these Old World Macs with the 6200 installed, if booting just hangs when loading the Old World ROM, before it scans the Extensions folder for 'NDRV's it won't work tho.

Mine has been booting just fine in OS 9, with the ATI card in there as well. I've also been booting the machine with only the 6200 in it (removed the ATI entirely), to OSX 10.4.11

I could try a screen mirroring or OF test, to see what happens its set to boot OS 9.

Did a quick benchmark with xbench 1.3. GeForce 6200 on left, ATI Radeon 9200 on right.
Significant improvement. I'll have to fire up Quake or Unreal and see what kind of fps improvement they get.

Picture 2.png
 
Also, not knowing anything about the nvidia driver engine, and compatibility between the various nvidia gpu's NV17, NV28, NV43. I know basic vga capability is there.

But has anyone tried a dirty hack such as changing the PCI device ID of the 6200 to the latest known nvidia card supported, e.g. a Geforce 4mx or 4ti and see what happens when booting OS 9.. ?

Or is that a dumb idea.. because in my simplistic thinking it would then be easy to undo that and then add the 6200 ID's to that nvidia driver extension.. e.g. Vendor ID is 10DE, device ID is 0141 for the 6600, 0280 for Geforce 4 ti?
or whatever. Or was this attempted before with like the NV30 5200 cards?
 
Last edited:
Mine has been booting just fine in OS 9, with the ATI card in there as well. I've also been booting the machine with only the 6200 in it (removed the ATI entirely), to OSX 10.4.11

I could try a screen mirroring or OF test, to see what happens its set to boot OS 9.

Did a quick benchmark with xbench 1.3. GeForce 6200 on left, ATI Radeon 9200 on right.
Significant improvement. I'll have to fire up Quake or Unreal and see what kind of fps improvement they get.

View attachment 2071531
I don't think you take my meaning, OS 9 must boot when the 6200 is the active display device in OF. So that the COFB driver can be loaded, what I call the "Non-Existent Hardware" 'NDRV'.
 

Attachments

  • Non-existent hardware-0.0d0.pef.zip
    14.9 KB · Views: 73
Last edited:
Where is that extracted from?
The New World Mac OS ROM Parcels file with Elliot Nunn's tbxi dump and build tool.

Code:
pip3 install tbxi
tbxi dump /path to/Mac OS ROM

It will also build, and it will dump 4MB Old World ROM's too.

This is loaded for any frame buffer that doesn't have an 'NDRV' in the device tree when the New World ROM loads from Open Firmware or Open Bios.

Older versions of the Mac OS ROM don't have it, that's why you can't get video out of Geforce cards without a ROM based 'NDRV' in OS 8.6 and older on New World Macs.
 
Last edited:
BTW @joevt @flyproductions I ran into a weird issue with the 6200 on my Beige with both DVI and VGA connected from boot.

A third "ghost" display at a really odd portrait mode resolution stuck that thousands of colors.

I think it related to Atri's code in the ROM Maker that enables the TV out when you connect the S-Video and hit "Detect Displays". Tho I think it should only be able to mirror one of the other display, as the 6200 only has two RAMDACs, but somehow it was driving three displays at different resolutions.

It doesn't appear if I boot from VGA then attach the DVI and "Detect Displays" only from boot with both connected.

Not an issue for me, and I didn't test if this also happens on New World Macs in my collection with our custom ROM. I just thought it was odd and worth mentioning.

Also, Core Image Fun House doesn't seem to work 100% at all of the effects, but I likely just forgot exactly how to use it correct. The transition effects don't seem to work quite right with the stock photos, but the other effects I tested seemed to work right.

Sadly Core Image was one of those really cool things Apple did that was so far ahead of it's time that third parties never really adopted it and Apple didn't make it a requirement of Leopard so they didn't do all the cool stuff with the UI they could have done.
 
BTW @joevt @flyproductions I ran into a weird issue with the 6200 on my Beige with both DVI and VGA connected from boot.
It doesn't appear if I boot from VGA then attach the DVI and "Detect Displays" only from boot with both connected.
Hmm, didn't test this somehow little exotic scenario. So i did not notice something like that. But i think, i remember something like that from the old 6200-experimental-days. And, as far as i remember, you can really attach a third monitor, which is then mirroring one of the other connector's output, as you estmated.

So far i now can confirm a behaviour mentioned before as reproduceable:
It's the booting of the 6200 only at second shot! Whenever the G3 was turned off for a certain timespan, no matter if connected to wall or not, on the first boot i only get a black screen from the 6200. On the second try everything works nice as expected. Onboard video, pci/@f1, has allways been excluded from the PCI probe, when testing.

This happens, no matter if via OF the output is set to "screen" (which the 6200 defaults to, if onboard is hidden) or explictly to where the 6200 is sitting, "pci/@e". Even with adding "/@1" to direct to DVI where the Display is actually connected.

Do you guys get this too? And what could be a reason for that. It's just somehow cosmetic. But if it can be easily fixed, i would do this.

Also to the OS9-topic:
I don't know if i didn't get something right and this was never in question. But for OS 9.2 in the Sawtooth the 6200 PCI works fine without any issues. No accelleration of course. But i get a full resolution output over DVI from it.

6200_OS9.jpg
 
Resources are stored in the resource fork of the main program.
Hmm, did "Show Package Contents" in OSX and went to /Contents/Resources/XPostFacto.rsrc, but couldn't find any sign of OFpt or OFtc in there. Was i on the wrong path and it has to be opened in OS9 with something like ResEdit?

Edit:
Just found them! In the "SharedResources.rsrc"-file from OS9 with ResEdit. Think i didn't have launched this for over 20 Years!

Edit 2:
Just seen, that this can be also done with Resorcerer in OSX. And also found the "nvramrc"-part inside the OFpt. So it should be easily possible to edit the
Code:
setenv pci-probe-list fffbffff
in there. So it is not annoyingly overwritten every time i use XPF.

Thanks very much for leading me in the right direction (again).
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.