Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Question: How powerful of a graphics card will work in a beige Power Macintosh G3?

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.
My quick hack of trying to change the device ID to that of a Geforce 4 TI didn't do anything.
Although all I did was change the first hex address on the rom that had the 6200 id so it may have required it in another spot, or I don't understand how the PCI id gets mapped to a nvidia or other display driver in the extension folder. Is there a generic framebuffer driver that is mapped by device ID?

But I did revert the rom back, and setup vnc. And booted the Mac with only the 6200 in it, and was able to connect to.

So it does boot into OS 9 (unless the vnc driver does something else to allow it to boot as a virtual display is listed).
But am assuming that happens after boot, as I have the vnc application in my startup folder.

Screen Shot 2022-09-19 at 1.48.28 PM.png
 
Last edited:
joevt said:
They are stored as OFpt resources. The OFtc resource says which Mac gets which OFpt.
https://github.com/OpenDarwin-CVS/X...808b15449a124fb4/XPostFacto/Resources/nvram.r
Click to expand...
It worked!

I just inserted
Code: 
setenv pci-probe-list fffbffff
instead of
Code: 
hex
into
Code: 
'OFpt' (133, "Silk")
of XPF's SharedResources.rsrc right behind "nvramrc"...

...and now i can safely use XPF i. e. to switch the startup disk without the onboard video constantly beeing reactivated and then instantly trying to gain control over the output. I was close to desoldering that crappy mess!

Thanks again @joevt !

...and every time in future a PRAM-reset is needed, once using XPF thereafter should be sufficient to turn onboard off again.
 
Last edited:
flyproductions said:
It worked!

I just inserted
Code: 
setenv pci-probe-list fffbffff
instead of
Code: 
hex
into
Code: 
'OFpt' (133, "Silk")
of XPF's SharedResources.rsrc right behind "nvramrc"...

...and now i can safely use XPF i. e. to switch the startup disk without the onboard video constantly beeing reactivated and then instantly trying to gain control over the output. I was close to desoldering that crappy mess!

Thanks again @joevt !

...and every time in future a PRAM-reset is needed, once using XPF thereafter should be sufficient to turn onboard off again.
Click to expand...
It should probably be:
Code: 
hex setenv pci-probe-list fffbffff
but maybe hex is always the default base so it's redundant?
 
joevt said:
It should probably be:
Code: 
hex setenv pci-probe-list fffbffff
but maybe hex is always the default base so it's redundant?
Click to expand...
Makes sense.

But i remember beeing advised somewhere, where i first read about the pci probe list command, to delete the hex before entering. Could easily be reinserted. But seems to work anyway.
 
DearthnVader said:
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.
Click to expand...
Turns out the third display was the built-in display, that now seems to support CI but not QE;-)
 
DearthnVader said:
Turns out the third display was the built-in display, that now seems to support CI but not QE;-)
Click to expand...
That's what i have experienced in the Sawtooth too: As soon as there is any card present, which supports CI, System Info shows "CI supported" for all of them! So the 9000pro PCI once supported CI too!
 
  • Like
Reactions: Amethyst1
flyproductions said:
That's what i have experienced in the Sawtooth too: As soon as there is any card present, which supports CI, System Info shows "CI supported" for all of them! So the 9000pro PCI once supported CI too!
Click to expand...
I used Core Image Funhouse on the built in display, just to ensure it was actually working, and it was.

So it must be rendering on the 6200 and just displaying on the built-in display. Pretty cool, but I've seen this type of thing before. If you flash the R9000 with a PC VBIOS and install in in the PCI slot you can run ATI's Smart Shader Demos on the Beiges built-in display.

Also, you can use OpenGL Driver Monitor to view the VRAM usage. Core Image Funhouse really likes lots of VRAM when you start stacking effects. It would be nice if we could crack the 512MB barrier again.
 
  • Like
Reactions: Amethyst1
DearthnVader said:
Also, you can use OpenGL Driver Monitor to view the VRAM usage. Core Image Funhouse really likes lots of VRAM when you start stacking effects. It would be nice if we could crack the 512MB barrier again.
Click to expand...
joevt said:
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):
...

Here's the Open Firmware 4 version (compiled fcode obtained from dictionary dump):
...

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.
Click to expand...
I've updated my fcode to forth converter so it doesn't need MPW anymore. It uses capstone (modified) to do disassembly of compiled fcode. I've figured out how to decompress the Open Firmware parts from New World roms and extract fcode images from them. I've checked B&W G3, iMac G3, G4 Sawtooth / Gigabit, and Quad G5.

It seems that Open Firmware 3 has the same 256 MB limit as 2.4. (alloc-mem-addr) is the same between them.

Only in Open Firmware 4 there is support for ≥ 512 MB BARs. Here is the forth code for (alloc-mem-addr) from my Quad G5:
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
	begin
		local_pciBridgeInfo
		>as.mem-addr-max
		@
		local_newMemAddr
		local_size
		+
		u<
		while
			local_pciBridgeInfo
			>as.mem-addr-max
			@
			h#10000000
			0
			['] claim-real
			catch
			if
				" catch occured"
				[
				last@
				]
				literal
				(time-stamp-hdr)
				3drop
				local_savedMemAddr
				local_pciBridgeInfo
				>as.next-mem-addr
				!
				0
				exit
			else
				dup
				h#10000000
				map-range
				h#10000000
				+
				local_pciBridgeInfo
				>as.mem-addr-max
				!
			then
	repeat
	local_newMemAddr
	local_size
	+
	local_pciBridgeInfo
	>as.next-mem-addr
	!
	local_newMemAddr
	;

It's basically identical to the Open Firmware 2.4 / 3.0 version except this new version has while ... repeat instead of if ... then.
I'll try to make some nvramrc patches for Open Firmware 1.0.5 and 2.0 / 2.4. Does anyone with a 512 MB card have an Open Firmware 3 Mac that they want to try it with?
 
  • Like
Reactions: LightBulbFun
joevt said:
Does anyone with a 512 MB card...
Click to expand...
I have this PNY GF 6200 512MB, but only 256MB fCode ROMs for it.
joevt said:
...have an Open Firmware 3 Mac that they want to try it with?
Click to expand...
Is a G5 Single 1.8 with AGP slot and 900MHz bus one of these?

Edit: Ah sorry, just remembered that also the Sawtooth is 3. 2.4 is, what the Beige was. How quick one forgets! 😉
 
Last edited:
DearthnVader said:
I can test that.
Click to expand...
What Mac model, Open Firmware version? Maybe do a dev / ls unselect-dev " devalias" evaluate " printenv" evaluate dump-device-tree words

flyproductions said:
I have this PNY GF 6200 512MB, but only 256MB fCode ROMs for it.
Click to expand...
I don't know if a 512MB VRAM fcode rom is different.

flyproductions said:
Is a G5 Single 1.8 with AGP slot and 900MHz bus one of these?
Click to expand...
Aren't all G5's Open Firmware 4? Provide a rom dump and the above command output.

flyproductions said:
Edit: Ah sorry, just remembered that also the Sawtooth is 3. 2.4 is, what the Beige was. How quick one forgets! 😉
Click to expand...
2.4 is latest Beige G3 revision.
Sawtooth has Open Firmware 3. So does B&W G3 but the Open Firmware versions are different.
 
Last edited:
flyproductions said:
But doesn't all this require a special "512MB"-fCode-ROM on the card itself too? Or does this overwrite what's in the card's ROM?
Click to expand...
It requires the ROM be 512MB enabled. Just sadly for my lost backup drive with the 512MB rom I made years ago.

I only ever tested that rom in my 2004 PM G5 SP 1.8Ghz( PCI 600mhz FSB ).

So that must have been OF 4.x, because the card work fully with Tiger. But one card I sent to a user of a Cube that worked in my G5 did not work in his Cube.

So maybe now we know the reason why no one else ever got 512MB to work. A limitation of OF <4.x.

Tho, just from my memory, we still need to patch the NVSTRAP to enable 512MB to work correct and we no longer have Arti's strap editor..........

But you can still use the 6200 ROM Maker to make a 512MB ROM.
 
DearthnVader said:
You'll get garbled video without OF 4.x and the NVSTRAP patch may also be need......
Click to expand...
I also found some instruction to manually "fix" the softstraps. Don't know, in what context i got / ever used this. But it's like this:

1. write down the hex numbers contained within addresses 5a to 5b and swap them round.

2. subtract 1 from the first swapped number and 80 from the second number (hex goes from 1-9 and then a-f, so for example, 80 subtracted from e4 would be 64. Now swap the numbers round again and you're done with those 2.

3. Do the same for the hex numbers contained within 5e to 5f, but add instead of subtract.

5. Now replace the original hex numbers with your adjusted hex numbers and save the rom.

Does this have anything to do with the actual problem?
 
DearthnVader said:
I think my MDD should work for what we need, no?
Click to expand...
(alloc-mem-addr) is not in the words list, so I need a dictionary dump at least to know how to patch it.

flyproductions said:
But doesn't all this require a special "512MB"-fCode-ROM on the card itself too?
Click to expand...
Maybe. One thing at a time.

flyproductions said:
Or does this overwrite what's in the card's ROM?
Click to expand...
This does not overwrite the card's ROM.

You only need the ROM changes that we made in this thread for Nvidia 6200 PCI cards if you want to use them in Old World Macs with Open Firmware < 3 (Open Firmware 1.0.5, 2.0f1, or 2.4). Those ROM changes will allow the card to work in any Power Mac.

You may need a new ROM for 512MB cards if you were previously using a 256 MB fcode rom (or if the card doesn't have a fcode rom).

DearthnVader said:
It requires the ROM be 512MB enabled. Just sadly for my lost backup drive with the 512MB rom I made years ago.

I only ever tested that rom in my 2004 PM G5 SP 1.8Ghz( PCI 600mhz FSB ).

So that must have been OF 4.x, because the card work fully with Tiger. But one card I sent to a user of a Cube that worked in my G5 did not work in his Cube.

So maybe now we know the reason why no one else ever got 512MB to work. A limitation of OF <4.x.

Tho, just from my memory, we still need to patch the NVSTRAP to enable 512MB to work correct and we no longer have Arti's strap editor..........

But you can still use the 6200 ROM Maker to make a 512MB ROM.
Click to expand...
Does the 6200 ROM Maker patch the NVSTRAP to enable 512MB?
 
joevt said:
Does the 6200 ROM Maker patch the NVSTRAP to enable 512MB?
Click to expand...
Likely not.

I just made a ROM of the PC ROM of the PNY 6200 AGP 512MB i have, using the ROM Maker. And the NVSTRAP (if it is the same thing called "Softstraps" in the WIKI) look just the same as in other fCode ROMs for 256MB cards.

Sadly the ROM did not work at all. Not even a signal to the display. The card works fine with a ROM, made of one of the Club3D cards. But only showing 256MB.
 
Updated #487 : G4 Gigabit and G4 Sawtooth should be able to use the same patch as Open Firmware 2.4. I'll work on 2.0f1 and 1.0.5 until someone sends a Open Firmware dictionary dump from a Mac with a different rom (such as G4 MDD, ...).
 
joevt said:
Updated #487 : G4 Gigabit and G4 Sawtooth should be able to use the same patch as Open Firmware 2.4. I'll work on 2.0f1 and 1.0.5 until someone sends a Open Firmware dictionary dump from a Mac with a different rom (such as G4 MDD, ...).
Click to expand...
Sorry, if i don't get it right and asking stupid questions again! 😉

The Patch has to be added to the nvramrc. And thereafter a working card with a valid fCode ROM which has 512MBs of memory should show up with the real amount instead of i. e. 256MB? Or has anything to be adjusted in the card's ROM too, as DearthnVader suggests?
 
DearthnVader said:
You'll get garbled video without OF 4.x and the NVSTRAP patch may also be need......
Click to expand...
Still wondering, if NVSTRAP and (in Wiki) so called "Softstraps" are the same thing.

In case: I just compared this area of two different PC-ROMs, one from a 6200 with 256MB and the one of the PNY 6200 which has 512MB of V-Ram. They are completely identical:

Code: 
C3C3EFFF 08100000 FFFFFF7F 00000080 2200A5B1

So should be no need to patch anything there?
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back