I use the one for the single sided card. Got this card relatively cheap of ebay. I think, these have been used in DELL workstations.
They are all PCIe.
No, sadly not.
Got a tip for us?
Let us know
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?
- Thread starter LeoI07
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
I don't know how many times I have to say it, to get 512MB to work on the only AGP card it ever worked on I had to edit the strap. 512MB would not work otherwise, so just copying the straps is NOT ENOUGH!!!!!!!!!!
I think it has to do with the drivers for OS X, I think the 512MB card I had success with worked as a 256MB card without the edit to the NVSTRAP, but that is only as good as my memory from 2006.
I only ever got it working in the 600Mhz FSB 1.8 Ghz G5( 2004 ), so that Mac may or may not have a version of OF that doesn't need patching for 512MB VRAM, but we can assume it doesn't need patching as the card worked fully, and when I say it worked fully, I mean I tested it while monitoring the VRAM usage to ensure it could exceed 256MB without any issues.
Sometimes the Apple System Profiler will not report the VRAM,size correctly, you need to use a deeper tool to test the VRAM.
Install Developer Tools and use OpenGL Driver Monitor to monitor the Free VRAM. In a system with Quartz Extreme enabled you can just COMMAND+N a bunch of Safari windows and watch to see how much VRAM is free and in use.
On the AGP 6200 that you have that reports 512MB under OS 9, boot into Open Firmware and get the .properties of the NDVA,Parent@10 to see what the reported VRAM,size is.
If it's 0X2000000 or 0X0100000.
If Open Firmware is reporting the VRAM,size as 512MB( 0x2000000 ) then the issue is likely with OS X drivers, they may read the NVSTRAP and that value needs to match correct for what the driver expect.
There is a reason I keep posting info on the Soft Straps( NVSTRAP ) it's because I already know they have to be edited to get 512MB to work correct under OS X and report the correct amount of VRAM to the ASP( purely cosmetic ).
The info I posted before from nouveau and the info I quoted from Arti should be enough for us to figure out what bits to set for 512MB of VRAM in the strap to get it to work with a Macintosh computer. Forget what makes it work with Linux or Windows.
With PCI Passthrough I tested the PCI 512MB card I have in Emu with SLOF and the FCODE ROM I created with the ROM Maker. I got garbled video out of the card in Open Firmware( SLOF ), however once the nouveau drivers loaded in Debian 11 PPC(LE) the Console loaded with proper video output on the card, tho nouveau reported 1024MB of VRAM and 1024MB of RAM used as the shadow memory( or whatever it's called ) So we know that even the nouveau drivers don't properly report the VRAM,size for the card.
I could not get Xorg up and running in this situation, I could login in the text Console on the card just fine, proper video output on the card, but I get garbled video form Xorg. I'm not real sure the issue here, if I just have an improperly configure Xserver or the are Endianness issues, or it's an issue with PCI Passthrough.
PCI Passthrough needs some special configuration to work with VGA cards and other than me, not a lot of people have ever tested it with older cards, so no one ever fixed the bugs.
These old cards, and PCI cards are mostly untested with PCI Passthrough.
But PCI Passthough is a great way to port HW like these old PCI cards because it sits between the Software and the Hardware and you can dump the register state in realtime while the drivers load and configure the system right to the tty on the host. A "poorman's PCI Analyzer".
The future of PowerPC is emulators, all these old Mac's are going to die and it's going to get harder and harder to find parts and repair them, and the more and more it is going to cost in time and money( and time is money ).
Even PCI Passthrough is only a stop gap. Blanton Zoltan has already made Rage128 emulation work with Qemu PPC, and with a little help from me we got that to work with Mac OS 9. Blanton's target OS the morphOS so he got that working for VGA and even some 2D acceleration. We got basic 'NDRV' support working for OS 9, so you can change the screen resolution and bit depth. It works just as well as the QEMU,VGA device does on PPC. You can even get 32MB of VRAM working on the emulated Rage128 and the ATI Control Panel with properly report all the aspects of the card, including all the VRAM usage buffer.
@joevt work with emulation of the GF6200 in DingusPPC lays the groundwork for register level emulation of GeForce cards.
DosBox and PCemu have register level emulation of the Voodoo2 3D accelerator. It even works in the macOS, but there is a leaked white paper for the Voodoo2 that details all the registers, we don't have this for Rage/Radeon/GeForce cards, so we need to reverse engineer them with the help of the open source Linux drivers and PCI Passthough.
Already my 2022 M2 MPB emulates a PowerMac faster than any real hardware ever built by Apple. With a few drawbacks, the CPU's integer performance is around that of a 1.5Ghz G4, disk IO is way faster than any G4 can achieve other than maybe 64bit SCSI or SATA cards.
Sadly we are kind of limited right now with PCI bus emulation for PCI Passthrough, but that can be fixed.
So we take what we can learn from hacking about in this thread and we build upon it. Sadly Apple didn't leave us in path forward with the macOS on PPC. Beta versions of 10.6 is as far as we can go, but we can still run any software that will run on a real G4 made by Apple in emulation for when the day comes that the hardware is all gone or too expensive to maintain.
The great news about that is 5 years form now G4 emulation will likely be faster than any real G5 ever made.
Install Developer Tools and use OpenGL Driver Monitor to monitor the Free VRAM. In a system with Quartz Extreme enabled you can just COMMAND+N a bunch of Safari windows and watch to see how much VRAM is free and in use.
On the AGP 6200 that you have that reports 512MB under OS 9, boot into Open Firmware and get the .properties of the NDVA,Parent@10 to see what the reported VRAM,size is.
If it's 0X2000000 or 0X0100000.
If Open Firmware is reporting the VRAM,size as 512MB( 0x2000000 ) then the issue is likely with OS X drivers, they may read the NVSTRAP and that value needs to match correct for what the driver expect.
There is a reason I keep posting info on the Soft Straps( NVSTRAP ) it's because I already know they have to be edited to get 512MB to work correct under OS X and report the correct amount of VRAM to the ASP( purely cosmetic ).
The info I posted before from nouveau and the info I quoted from Arti should be enough for us to figure out what bits to set for 512MB of VRAM in the strap to get it to work with a Macintosh computer. Forget what makes it work with Linux or Windows.
With PCI Passthrough I tested the PCI 512MB card I have in Emu with SLOF and the FCODE ROM I created with the ROM Maker. I got garbled video out of the card in Open Firmware( SLOF ), however once the nouveau drivers loaded in Debian 11 PPC(LE) the Console loaded with proper video output on the card, tho nouveau reported 1024MB of VRAM and 1024MB of RAM used as the shadow memory( or whatever it's called ) So we know that even the nouveau drivers don't properly report the VRAM,size for the card.
I could not get Xorg up and running in this situation, I could login in the text Console on the card just fine, proper video output on the card, but I get garbled video form Xorg. I'm not real sure the issue here, if I just have an improperly configure Xserver or the are Endianness issues, or it's an issue with PCI Passthrough.
PCI Passthrough needs some special configuration to work with VGA cards and other than me, not a lot of people have ever tested it with older cards, so no one ever fixed the bugs.
These old cards, and PCI cards are mostly untested with PCI Passthrough.
But PCI Passthough is a great way to port HW like these old PCI cards because it sits between the Software and the Hardware and you can dump the register state in realtime while the drivers load and configure the system right to the tty on the host. A "poorman's PCI Analyzer".
The future of PowerPC is emulators, all these old Mac's are going to die and it's going to get harder and harder to find parts and repair them, and the more and more it is going to cost in time and money( and time is money ).
Even PCI Passthrough is only a stop gap. Blanton Zoltan has already made Rage128 emulation work with Qemu PPC, and with a little help from me we got that to work with Mac OS 9. Blanton's target OS the morphOS so he got that working for VGA and even some 2D acceleration. We got basic 'NDRV' support working for OS 9, so you can change the screen resolution and bit depth. It works just as well as the QEMU,VGA device does on PPC. You can even get 32MB of VRAM working on the emulated Rage128 and the ATI Control Panel with properly report all the aspects of the card, including all the VRAM usage buffer.
@joevt work with emulation of the GF6200 in DingusPPC lays the groundwork for register level emulation of GeForce cards.
DosBox and PCemu have register level emulation of the Voodoo2 3D accelerator. It even works in the macOS, but there is a leaked white paper for the Voodoo2 that details all the registers, we don't have this for Rage/Radeon/GeForce cards, so we need to reverse engineer them with the help of the open source Linux drivers and PCI Passthough.
Already my 2022 M2 MPB emulates a PowerMac faster than any real hardware ever built by Apple. With a few drawbacks, the CPU's integer performance is around that of a 1.5Ghz G4, disk IO is way faster than any G4 can achieve other than maybe 64bit SCSI or SATA cards.
Sadly we are kind of limited right now with PCI bus emulation for PCI Passthrough, but that can be fixed.
So we take what we can learn from hacking about in this thread and we build upon it. Sadly Apple didn't leave us in path forward with the macOS on PPC. Beta versions of 10.6 is as far as we can go, but we can still run any software that will run on a real G4 made by Apple in emulation for when the day comes that the hardware is all gone or too expensive to maintain.
The great news about that is 5 years form now G4 emulation will likely be faster than any real G5 ever made.
Got this info not just yet. But it's not so easy to evaluate, if it's not known what has been done to the strap.
Also, if the 512MB have only been confirmed in one single machine, it may well be possible (as you estimate yourself), that it is this particular machine ('s version of OF), which does the trick. As shown, in OS 9 the 6200 shows up as "512MB V-Ram" too.
What apps can be used to monitor the real V-Ram usage of a GPU in OS X?
Edit: Ah, allready answered! Thanks!
In the Sawtooth OF well shows 2000000 for NVDA,memsize and VRAM,memsize. So problems seem to be within the OS itself. Will try the developer-tools, to see, if more than 256 can be used, regardless of what System Info shows.
Last edited:
We'll need @joevt input on that, maybe it needs his forthcoming patch anyway, even tho OF reports the correct VRAM,size.
Remember I only tested this round 2006, so the version of Tiger that was out at that time( maybe 10.4.8 ) Maybe a later Mac OS update brought a bug with 515MB on AGP cards ).
I can remember if Arti's strap editor set 3 or 4 bits for VRAM,size, but we know what two of those bits are( bits 23 and 24 ) so I would assume that bit 25 would be for 512MB and maybe bit 26 does something to, I was hoping @joevt could decode the meaning of the and or mask for us?
I assume we need to set bits 23-26 in the second 32bit word to override the resisters. I really wish I had not lost Atri's NVStap editor or I had at least paid attention to what the tool did with each setting.
So i did some testing with/without the NVRAM-script.
Completely removed the script: VRAM,memsize is still correct, 2000000, in OF
Added the updated script: In OS/System Info VRAM is still "seen" as 256MB
Is there anything having to be installed in addition? No matter what i do on the machine, it allways says "Current GPU Memory Utilization: Zero"
VRAM,memsize property comes from register 0x10020c NV04_PFB_FIFO_DATAThe current patches are for fixing
(alloc-mem-addr) so that map-in will allocate a 512MB BAR. What was missing is the 512MB BAR in the assigned-addresses property.I've updated #487 with additional patches to make Open Firmware set
asigned-addresses for 512MB BAR.
Just tested the updated version. OF shows correct amount. But booting to OS, no matter if safe mode or normal, still shows 256.
Will you dump the .properties of the NVDA,Parrent so we can see the assigned-addressed property?
Also check the perimeters of OGLDM you should see one for free vram or vram in use or some such( I don't have it in front of me right now ).
Make sure that ASP isn't just miss reporting the vram.
Also, install Apple's CHUD tools and use ReggieSE to read 0x10020c. On the physMem tab.
Most of the time this is 0x9110020c, it's a 32bit word, but you can read 0x10 of the NVDA,Parrent to get the base address if it isn't 0x91, on the PCI tab.
Code:
0 > dev /pci@f0000000/NVDA,Parent@10 ok
0 > .properties
vendor-id 000010de
device-id 00000221
revision-id 000000a1
class-code 00030000
interrupts 00000001
min-grant 00000005
max-latency 00000001
subsystem-vendor-id 000010de
subsystem-id 00000010
devsel-speed 00000001
fast-back-to-back
fcode-rom-offset 00000000
model GeForce 6200
NVDA,BMP 55aa7eeb 4b373430 30e94c19 77cc5649 44454f20 0d000000 00005710 00004942
4d205647 4120436f 6d706174 69626c65 01000000 b010cc23 30362f32 342f3035
00000000 00000000 01100000 00000000 e93edd00 00000000 00000000 00004081
efffff7f 10000080 2200a542 e9f5b7e9 fcb7ffb8 42495400 00010c06 10473201
0400de00 42021600 e2004301 0e00f800 44010400 06014901 0e000a01 4c010200
18017401 12001a01 4d010200 2c014e00 00000000 50011900 2e015302 15004701
54010200 5c015501 03005e01 56010600 61016300 00000000 69022300 67010000
00007502 43050000 00000000 a8073030 2f30302f 30300200 00000000 00000000
... 000024fb bytes total
device_type NVDA,GeForce
NVPM 01000000 00000000 00000000 00000000 00000000 00000000 00000000
NVCAP 04000000 00000001 000e0000 00000007 000000
name NVDA,Parent
#address-cells 00000001
#size-cells 00000000
rom-revision 32313439 6100
NVDA,Features 004d02ef
NVDA,Level 00000001
reg 00008000 00000000 00000000 00000000 00000000
02008010 00000000 00000000 00000000 01000000
02008018 00000000 00000000 00000000 01000000
42008014 00000000 00000000 00000000 10000000
02008030 00000000 00000000 00000000 00020000
VRAM,memsize 20000000 20000000
assigned-addresses c2008014 00000000 a0000000 00000000 10000000
82008010 00000000 92000000 00000000 01000000
82008018 00000000 91000000 00000000 01000000
82008030 00000000 90000000 00000000 00020000
AGP_Master
AGP_Address_Range 00000000 ffffffff
AGP_Address_Block 10000000
AGP_Alignment 10000000
AGP_AllowOverlap 00000001Most likely the case:
A bit strange is, that, once used, the Vram is not set free again. I opend a bunch of browser windows as you suggested. But, when i closed the browser, the free memory did not reappear. But in all it looks like 512MB to me.
Is this what you need to see?
I will now check how things behave, when i remove the patch.
Even with the script/patch removed by PRAM-reset OGLDM still shows 512MB of Vram. So the whole System Profiler thing seems to be plain cosmetic.
Last edited:
Why is reg/assigned-addresses showing only 256MB BAR1 while memsize is 512MB?
Verify reg by running my lspci script in Open Firmware.
Code:
dev pci
\ copy and paste contents of "lspci for paste OpenFirmware.txt" here.
lspciThe assigned address for BAR0 is 92000000 so I think you need to look at 0x9210020c. The result should have a single bit set, representing the memsize.
update: Replaced attachment with link to latest lspci for Open Firmware.
https://www.dropbox.com/scl/fi/ddwv...ware.zip?rlkey=rujv8sbhb8v4ehk9b845bd3k1&dl=0
Last edited:
When you read 0x10 under PCI tab in ReggieSE, it's the same as reading 82008010 and should return 9200000, but we can see this value is not what we expect 0100000(256MB) rather than 20000000(512MB).
So, as Joe said, read 9210020c in Reggie and see if the drivers change anything here.
Normally the VRAM is set free within a min. or so after closing out all the windows, I'll do some testing here.
Those roms (Quadro FX 4500 PCIe OEM, Quadro FX 4500 Single, 7800GTX 512) all use Fcode version 2149.
Only the OEM Pcie Quadro FX4500 has a valid checksum but I don't think that matters.
All the code is the same except the name "GeForce7800GTX" vs "Quadro FX 4500". They have different straps. The FX 4500 has device-id 9D instead of 92.
BIOS:5.70.02.16.00 FCode revision:2149
That 7800 GTX 256MB matches my Mac 7800GT but with different straps and names "GeForce7800GTX" vs "GeForce 7800GT".
Mine has a valid checksum.
I suppose the GTX used the Mac rom and just had some bytes edited. See the names are both the same length (the space in "GeForce 7800GT" was removed to allow room for the X in "GeForce7800GTX").
These use newer FCode reversion: 2152.2
I'll work on an Old World Mac compatible version for 2152.2.
Yes, that's what i remembered too, that these were all spinoffs of the 7800 GT OEM, even with the 512 MB card's physical appearance beeing much more like the Quadro. Don't they all have the same Device ID, 92, too?
It's amazing the Quadro ROM works with the 7800's. When I made the 7800gs rom I made it from the Quadro ROM because it was 64k.
Most Quadro GPU's have additional registers the laser cut off the die for the GeForce cards, but maybe these just get ignored on the Geforce cards.
I tried to convert the 5200FX to a Quadro, but under Linux and Windows it did not score any better at SPECViewerPerf than the Geforce cards. So I flashed it with the compatible Quadro ROM for the 5200(PC), but it was just all garbled screen.
I tried to edit the ROM but the Quadro ROM just had so many regs that the GeForce card didn't have, it just ended up being a confusing mess.
Tho the Mac Quadro cards don't really support the Quadro features, other the the 3D mini DIN. So likely the Mac Quadro ROM doesn't have all those regs that make the card a true Quadro.
We don't have Quadro Driver for PPC Linux, so we can't really see if the Quadro features will work with the FCODE ROM. I would assume they would not, even tho the PC flashed cards are true Quadros, without the regs in the FCODE ROM they are just Geforce with 3D mini DIN support.
Even when we went to Intel, the Quadro/FireGL cards don't support the pro features you get with Linux/Windows under the Mac OS.
I built SPECViewerPerf for PPC and Intel and tested all this myself. FireGL means nothing in OS X and Quadro only means 3D mini DIN.
But if you boot Linux/Windows on the Intel Mac's you do get the Pro features.
Tho some cards did support ECC VRAM and that did work on OS X Intel.
Last edited:
Sadly when i try to run the script, i get just this:
Code:
Trying 192.168.0.150...
Connected to 192.168.0.150.
Escape character is '^]'.
ok
0 > dev pci ok
0 > 0 value pcirepeat 3 value vcirepeat 0 value therepeat 0 value ." :"
:", unknown word
ok
0 > 10 >> 4 u.r ." ] [" adr 8 + pc@ 8 >> do dup i lspcidev loop drop ; : lspci dead
[", unknown word
ok
0 > : lsvci vcirepeat to therepeat cr 100 0 do i lspcibus loop ;:" dup 8 u.r ."
lspcibus, unknown word
ok
0 > : lspcifun { bus dev fun ; adr } bus dev fun pciconfig -> adr adr ['] pc@ c
pciconfig, unknown word
ok
0 > then if bus dev fun lspcidump else 1 fun 0= if drop 8 then then ; : lspcide
DEFAULT CATCH!, code=300 at %SRR0: ff8095d8 %SRR1: 0000b030
ok
0 > : lspcibus 20 0 do dup i lspcidev loop drop ; : lspci pcirepeat to therepea
lspcidev, unknown word
ok
0 > : lsvci vcirepeat to therepeat cr 100 0 do i lspcibus loop ;:" dup 8 u.r ."
lspcibus, unknown word
ok
0 > : lspcifun { bus dev fun ; adr } bus dev fun pciconfig -> adr adr ['] pc@ c
pciconfig, unknown word
ok
0 > then if bus dev fun lspcidump else 1 fun 0= if drop 8 then then ; : lspcide
DEFAULT CATCH!, code=300 at %SRR0: ff80b208 %SRR1: 0000b030
ok
0 > : lspcibus 20 0 do dup i lspcidev loop drop ; : lspci pcirepeat to therepea
lspcidev, unknown word
ok
0 > : lsvci vcirepeat to therepeat cr 100 0 do i lspcibus loop ;
lspcibus, unknown word
okIs this, what was expected?
Not really, would have expected 0x20. You could try and set that, then sleep/wake the Mac and see if ASP reports 512 after that, but the BAR maybe ro or it may crash you Mac.
Yes, those are 92.
That does not match what is supposed to be pasted for the first line.
0 value pcirepeat 3 value vcirepeat 0 value therepeat 0 value pcilast : pc@ { adr } adr config-l@ dup to pcilastObviously copy and paste doesn't work properly with telnet to Open Firmware. You need a method to throttle the text speed (text pacing). I don't think Terminal.app has an option for that. Maybe an Apple Script can be created to paste the clipboard characters more slowly.
Or maybe you can load the file as text and execute the result. #55
0x10 is for 256MB. It should be 0x20. But if it's 0x10 then why do you have
VRAM,memsize 20000000 20000000?Are you sure it's a 512MB card?
Yes, 100%!
...but stupid me...who did not remember he had allready swapped the 6800XT back in...which is - of course - 256MB! 🙄
Looks somehow better now: