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.
Attached below. It is the ROM which produced the lspci-output, posted before.
That rom doesn't modify the BAR1 size soft strap bits so I guess they purposefully decided to make it 256MB.

So what should the correct output for 512MB be instead of
Code:
00008014:a0000008.f0000008
?
I explained BAR sizing in an earlier post. It's also explained in the PCI Local Bus specification.
The 4 least significant bits are flag bits. 8 = bit 3 = prefetchable flag.
f0000000 represents the size of the BAR. ffffffff is written to the BAR and when we read it back, only the first 4 bits were modified successfully which means the address must be a multiple of 256MB (2^28 = 10000000).
For 512MB, BAR should return e0000000.
a0000000 is the current address of the BAR and must be a multiple of the BAR size. a0000000 is actually a multiple if 512MB. I suppose you have other PCI devices that use the 90000000 address.

So don't the values OGLDM shows for VRAM (used and free) mean that it is working / 512MB are available to the system?
Probably?

Shouldn't hard straps be set to 512MB for any 512MB-card (like the PNY 6200 is) in the first place? So, in this case, if the soft straps in the ROM are used at all, they seem to do more harm than good.
I suppose a manufacturer can set the hard straps/soft straps however they like.
Maybe 256MB BAR is perfectly valid for a 512MB VRAM PCI card. It may be more compatible that way.
If you want to try 512MB BAR (with my nvramrc patches for Open Firmware versions before 2004), then try setting the 20 bytes at 0x58 to c3c36ffe 08108001 ffffff7f 00000080 2200a5b1
Code:
thesoftstraps="$(readsoftstraps ./6200/ROMs/PNY_512_Mac.rom)"
dumpheading ; dumponesoftstraps "$thesoftstraps" ; echo
newsoftstraps="$(setsoftstraps "$thesoftstraps" 0 23 2 3)"
dumpheading ; dumponesoftstraps "$newsoftstraps" ; echo

                                   CHECKSUM RESULT┬┐         SOFTSTRAPS0 RESULT               SOFTSTRAPS1 RESULT
                             EXPECTED CHECKSUM┬┐  ││  33222222222211111111110000000000 33222222222211111111110000000000
AND0     OR0      AND1     OR1    CHECKSUM┬┐  ││  ││  10987654321098765432109876543210 10987654321098765432109876543210
c3c3efff 08100000 ffffff7f 00000080 2200a5b1  b1  00  -----------0------0100----0010-- 1-------------------------------
                                   CHECKSUM RESULT┬┐         SOFTSTRAPS0 RESULT               SOFTSTRAPS1 RESULT
                             EXPECTED CHECKSUM┬┐  ││  33222222222211111111110000000000 33222222222211111111110000000000
AND0     OR0      AND1     OR1    CHECKSUM┬┐  ││  ││  10987654321098765432109876543210 10987654321098765432109876543210
c3c36ffe 08108001 ffffff7f 00000080 2200a5b1  b1  00  -------11--0------0100----0010-- 1-------------------------------


Just to be complete I suppose. Just bothers me that I had this working before and it doesn't work now.
I am interested in seeing it work as 512MB BAR.
 
So what is the deal with BAR memory allocations , does it reduce the system RAM by that amount when you boot the OS, or does it release the RAM so it is still available to the system?

512MB is huge amount of VRAM for the 64bit VRAM interface and the clock speed of the VRAM and throughput of the 6200 GPU. I'm not sure we are going to find any use case where 512MB of VRAM is any faster than 256MB.
32 bit addresses support 4 GB.
Power Macs allocate PCI memory starting from ≈2GB.
Power Macs don't have more than 2 GB RAM until the G5 which supports 64 bit and has a DART for address translation.
https://developer.apple.com/library...arwin/Conceptual/KernelProgramming/vm/vm.html
https://developer.apple.com/library...tual/IOKitFundamentals/DataMgmt/DataMgmt.html
https://developer.apple.com/library...rboltDrivers/DebuggingThunderboltDrivers.html
The G5 can reserve parts of low 32 bit memory for PCI and just have RAM skip that area.

BTW Just curious where does AGP GART play into all of this?

I have always wondered if the 7800 GS 512MB issues was maybe something AGP GART related?

I THINK the AGP GART in a PowerMac is set to 256MB (thats what I see in the linux dmesg anyhow)
I'm not sure what the GART is. Something to do with using system RAM for GPU purposes.
https://en.wikipedia.org/wiki/Graphics_address_remapping_table

as a follow on from this I am pleased to report it works just as well in my Power Macintosh 9600 even with its stock 604ev CPU, yeah Core Image on a 604!
Using one of my made for Old World Macs roms?
 
To the fCode-ROMs:
Not that i'd understand, what it actually does. But to my experience, it is one single byte having the biggest influence on working or not working of these 512MB cards. In the 6200 ROM it is at offset 0xF3AF and has to be set to 01 for the 512MB card and to 00 for any 256MB card. Same for the Gainward Bliss ROM, where this byte can be found at offset 0xE23B. In the ROM which made System Profiler show 512MB for the card with a safe boot it is set to 01. If set to 00, the card boots normal with drivers, but only showing 256MB.
offset from start of rom is not helpful when the offset can be anything.
 
It's interesting to see how Apple's Open Firmware progresses over time.

The iBook G4, Mac mini G4, and PowerBook G4 have support for 512MB BAR just like Quad G5. Of those three, the latest has the reverse order allocation that the G5 uses when a 512MB BAR exists. The earlier ones use the non-reverse order method that I'm using for my 512MB nvramrc patches.

See post #1 for a list of Open Firmware versions.
 
Last edited:
If you want to try 512MB BAR (with my nvramrc patches for Open Firmware versions before 2004), then try setting the 20 bytes at 0x58 to c3c36ffe 08108001 ffffff7f 00000080 2200a5b1
Congrats! 👏

This did the trick (again)! I edited the strap as adviced and reapplied the patch. So this is, what System Profiler shows up with now:

6200 512.png


OpenGL Driver Monitor shows Memory in Use and Free just like before. So this seems a "complete" GeForce 6200 512MB AGP now.

Without the patch applied and the straps set like this, i got a signal to the display, but no image and the system not booting up. Will this patch do any "harm" with cards not using it, or can it safely just be left in nvramrc?
 
Last edited:
Congrats! 👏

This did the trick (again)! I edited the strap as adviced and reapplied the patch. So this is, what System Profiler shows up with now:

View attachment 2096318

OpenGL Driver Monitor shows Memory in Use and Free just like before. So this seems a "complete" GeForce 6200 512MB AGP now.

Without the patch applied and the straps set like this, i got a signal to the display, but no image and the system not booting up. Will this patch do any "harm" with cards not using it, or can it safely just be left in nvramrc.
That's what I thought would happen, the 2004 G5 1.8Ghz (PCI) I use to own must have had support for 512MB BAR.

This explains why the card I made worked for me in my G5, but didn't work in the Cube, it would have needed @joevt patch.

Joe's a true GFX hero!
 
  • Like
Reactions: flyproductions
Also tried the "small" G5, a 1.8 GHz single of 2003, now. It obviously didn't work, as this machine should have OF 5.1.5. So none of the patches "matched".

So, if some info/dumps are needed to adjust the patch to this OF-version, i will happily provide it if i can. As to my honest opinion, these machines, the AGP-G5s up to the Dual 2.7, are the only ones, a 512MB video card would really make some sense in.

If only one could find one, they would get a new "best" card in person of this Gainward Bliss 7800GS Special Edition. Some of them could be clocked up to 475/700 and outperform the X800xt PE as well as the Quadro 4500 on the PCIe side.

Edit: Just checked. Exact BootROM-version is 5.1.5f2
 
Last edited:
  • Like
Reactions: LightBulbFun
Congrats! 👏

This did the trick (again)! I edited the strap as adviced and reapplied the patch. So this is, what System Profiler shows up with now:

View attachment 2096318

OpenGL Driver Monitor shows Memory in Use and Free just like before. So this seems a "complete" GeForce 6200 512MB AGP now.

Without the patch applied and the straps set like this, i got a signal to the display, but no image and the system not booting up. Will this patch do any "harm" with cards not using it, or can it safely just be left in nvramrc?
very awesome! its a shame no one has one of those Gainward 512MB GeForce 7800 GS cards! would be epic to see one of those finally work

interesting about what you get without the patch, as thats exactly what I get with the Quadro FX 4500 in my PowerMac G3/G4's

maybe I need to retry the patches I only ever tested it with my MDD and maybe I fluffed something up, ill have to dig out the sawtooth

or maybe try and see if I can type it out by hand into the G3 Blue and white (since it lacks telnet sadly)

(BTW I noticed in a couple recent screenshots, that you correctly capitalised the F in GeForce, thanks for doing that :) as an aside I have wondered what is the way to go about changing the name, when its a different length, id like add NVIDIA to the front of mine as well LOL)



BTW I wonder would it be possiable to add the BAR patch to the card ROM itself, so the first thing thats done as the card is loaded is it applies the patch?

that way it solves any issue of losing the NVRAMRC script should ya need to PRAM reset or such
 
Gainward Bliss 7800GS Special Edition
Sadly most of the 7800GS cards one will ever find with 512MB VRAM are really G71 aka GeForce 7900 cores. The G71 was a die shrink of the G70 and nVidia reworked the BMP in ways I could never figure out.

The 7800GS 256MB was a a waste in even the 1.8Ghz G5, it wasn't any faster than a R9800 Pro 128MB except in the case where the extra VRAM came into play. The CPU just couldn't hit the fill rate.

I always wanted to try it in the 2.7Ghz G5 AGP, but those are so rare to find in working condition.
 
Sadly most of the 7800GS cards one will ever find with 512MB VRAM are really G71 aka GeForce 7900 cores. The G71 was a die shrink of the G70 and nVidia reworked the BMP in ways I could never figure out.
Yes! ...and even if you find one of them, the guys selling them are calling impressive numbers!

I gave mine a try again. But sadly absolutely no sign of life. Would have surprised me anyway, as i remember having tried to revitalize it with a heatgun years back with no success.
The 7800GS 256MB was a a waste in even the 1.8Ghz G5, it wasn't any faster than a R9800 Pro 128MB except in the case where the extra VRAM came into play. The CPU just couldn't hit the fill rate.
This i cannot confirm for the 1.8 i have. It's the early one with the 900MHz (instead of 600MHz) bus. And at least in benchmarks like OpenMark or OpenGL Extensions Viewer i got way higher numbers with the 7800. Aside of the Dual Link DVI support the 7800 provided.

9800 Pro:

9800pro_openmark.jpg


9800pro_oglviewer.png



7800 GS:

7800gs_openmark.jpg


7800gs_oglviewer.png
 
(BTW I noticed in a couple recent screenshots, that you correctly capitalised the F in GeForce, thanks for doing that :)
I don't know, if there is any correct way to type this. So - after evaluating the pros and cons of either way for some extended period of time - i decided to go the way NV itself suggests in almost all the publications since these cards exist.

😝
 
  • Like
Reactions: LightBulbFun
Congrats! 👏

This did the trick (again)! I edited the strap as adviced and reapplied the patch. So this is, what System Profiler shows up with now:

View attachment 2096318

OpenGL Driver Monitor shows Memory in Use and Free just like before. So this seems a "complete" GeForce 6200 512MB AGP now.

Without the patch applied and the straps set like this, i got a signal to the display, but no image and the system not booting up. Will this patch do any "harm" with cards not using it, or can it safely just be left in nvramrc?
The patch should be safe for normal GPUs or other PCI/AGP cards.

Can you provide output from lspci and dump-device-tree to show that reg and assigned-addresses and BAR1 are now 512MB?

Also tried the "small" G5, a 1.8 GHz single of 2003, now. It obviously didn't work, as this machine should have OF 5.1.5. So none of the patches "matched".

So, if some info/dumps are needed to adjust the patch to this OF-version, i will happily provide it if i can. As to my honest opinion, these machines, the AGP-G5s up to the Dual 2.7, are the only ones, a 512MB video card would really make some sense in.

If only one could find one, they would get a new "best" card in person of this Gainward Bliss 7800GS Special Edition. Some of them could be clocked up to 475/700 and outperform the X800xt PE as well as the Quadro 4500 on the PCIe side.

Edit: Just checked. Exact BootROM-version is 5.1.5f2
I don't think BootROM 4.8.7f1 or later should require patch for 512MB BAR.
A ROM dump and a dictionary dump of the 5.1.5f2 BootROM would be helpful.

or maybe try and see if I can type it out by hand into the G3 Blue and white (since it lacks telnet sadly)
You should find a Stealth Port or Griffin gPort or similar adapter for the internal modem port so you can use serial.
http://macos9lives.com/smforum/index.php?topic=3623.0
http://alexhixon.com/projects/jamport/development.html
http://alexhixon.com/jamport/tech.html
https://68kmla.org/bb/index.php?thr...-circuittalk-localtalk-for-powermac-g4.40182/
I have a Griffin gPort for my B&W G3.

(BTW I noticed in a couple recent screenshots, that you correctly capitalised the F in GeForce, thanks for doing that :) as an aside I have wondered what is the way to go about changing the name, when its a different length, id like add NVIDIA to the front of mine as well LOL)
All changes should be made to the Forth code produced by DumpPCIRom.sh, then use toke to build the rom. This will automatically update the Open Firmware fcode checksum (but I don't think Open Firmware cares about the checksum) and also any fcode offsets in case you decide to add more bytes to the NVDA,BMP.

BTW I wonder would it be possiable to add the BAR patch to the card ROM itself, so the first thing thats done as the card is loaded is it applies the patch?

that way it solves any issue of losing the NVRAMRC script should ya need to PRAM reset or such
It may be possible but it might be specific to one version of Open Firmware depending on how much room is available.
 
  • Like
Reactions: LightBulbFun
If only we knew some way to dump the NVDA,BMP property in Windows we could like bring the GF7600 AGP/PCI-E and the GF7900 cards to PowerPC Mac's.

I know how to dump them in OS X with IOReg and LinuxPPC with the /proc file system.

Sadly I just don't know anything about Windows, but I would assume the property gets written to RAM somewhere we could dump it to a file.....

I tested years ago and there was driver support for the 7600 in PPC
 
There maybe issues with that card anyway!


Beware!!!!
Sounds a lot like what i experienced! Also beeing a bit more in luck, beeing able to use the card for some years(!) without any issues, it all out of nothing started to produce artefacting whenever OpenGL came into play and later went all black. I would exclude the reason beeing software problems but would suggest a very poor solder quality.

Above all with todays experience: Motivated by this thread's development, i threw it to light yesterday. Reading from your thread how rare these things are, i'm happy now not having it dumped even not functioning anymore. So i tried in the G5 again. But first with no success. Tried different power cables an some un- and replugging. All nothing! Finally decided to throw some extra dose of heat to it. Still nothing. Then, after remounting the cooler, i gave it on last shot. And bang! Display lit up and booted normaly to Leo. I was even able to launch OpenMark and finish one OpenGL Extensions Viewer test run. But then it went black again. Thereafter i had random signs of life. If it comes to life, anything seems like normal. But every time very temporary. So it is almost certainly just a broken solder joint. And most likely a professional reflow with controlled temperature and flux all over it could be a reliable fix. But this is far beyond my skills and i know of no one offering a service like that. So it is like it is.

But, if joevt will be able to adjust the patch for OF 5 and maybe also the strap of the ROM i use, maybe it will at least work for testing. Also it might be plain impossible to get one of these cards in working condition if there have only been 2.500 of them ever produced and those beeing of such a low build quality. 😟
 
Sounds a lot like what i experienced! Also beeing a bit more in luck, beeing able to use the card for some years(!) without any issues, it all out of nothing started to produce artefacting whenever OpenGL came into play and later went all black. I would exclude the reason beeing software problems but would suggest a very poor solder quality.

Above all with todays experience: Motivated by this thread's development, i threw it to light yesterday. Reading from your thread how rare these things are, i'm happy now not having it dumped even not functioning anymore. So i tried in the G5 again. But first with no success. Tried different power cables an some un- and replugging. All nothing! Finally decided to throw some extra dose of heat to it. Still nothing. Then, after remounting the cooler, i gave it on last shot. And bang! Display lit up and booted normaly to Leo. I was even able to launch OpenMark and finish one OpenGL Extensions Viewer test run. But then it went black again. Thereafter i had random signs of life. If it comes to life, anything seems like normal. But every time very temporary. So it is almost certainly just a broken solder joint. And most likely a professional reflow with controlled temperature and flux all over it could be a reliable fix. But this is far beyond my skills and i know of no one offering a service like that. So it is like it is.

But, if joevt will be able to adjust the patch for OF 5 and maybe also the strap of the ROM i use, maybe it will at least work for testing. Also it might be plain impossible to get one of these cards in working condition if there have only been 2.500 of them ever produced and those beeing of such a low build quality. 😟
Even the eBay link to the card you posted says it's G71, but the seller may not know. However I know many( most ) 512MB 7800GS cards you can find really use G71 and that doesn't work with PPC Mac's FCODE ROM, yet.

The G71 ran a lot cooler as that should help with "cold solder joints", tho. @LightBulbFun could likely reflow the GPU for you, it likely needs the GPU complexly reballed, and who is to say about the VRAM.

Giving the time and expense of having it reballed, and the fact that it will still run so hot it just fails again, we need to figure the G71 7900 cards if we can.
 
If only we knew some way to dump the NVDA,BMP property in Windows we could like bring the GF7600 AGP/PCI-E and the GF7900 cards to PowerPC Mac's.

I know how to dump them in OS X with IOReg and LinuxPPC with the /proc file system.

Sadly I just don't know anything about Windows, but I would assume the property gets written to RAM somewhere we could dump it to a file.....
It's probably just a set of bytes in the BIOS firmware. Don't any of the Nvidia bios editors have source code?
 
If only we knew some way to dump the NVDA,BMP property in Windows we could like bring the GF7600 AGP/PCI-E and the GF7900 cards to PowerPC Mac's.

I know how to dump them in OS X with IOReg and LinuxPPC with the /proc file system.

Sadly I just don't know anything about Windows, but I would assume the property gets written to RAM somewhere we could dump it to a file.....

I tested years ago and there was driver support for the 7600 in PPC

if you know how to dump them in OS X/IOReg/Linux PPC

then surely that would work with an x86 system too?

for example a GeForce 7600 AGP in an AGP based x86 system booted into linux or OS X?


as you say the GeForce 7xxx drivers in OS X are completely universal so all G7x based cards should work just fine in a PPC system :)

if either a proper ROM can be made for them, (or some sort of kext injector?)
 
It's probably just a set of bytes in the BIOS firmware. Don't any of the Nvidia bios editors have source code?
It is, there was a windows tool made for nVidia's board partners for the GeForce2 that could edit all the properties of the BMP, but I never had a copy of it, Arti did, and I just never asked for it as it didn't work for later cards.

I assume such a tool exists for the laters cards, just it's never been leaked.

Closest thing to open source tools I know was nvclock, sadly Thunderbird who wrote it has gone off the grid like Atri,gotch, and Aquamac.

If we could dump the properties of the BMP on x86 and compare them to PPC we could likely have a go at the Die Shrink cards based on the G7x, but I don't know of any tools that can dump that the way we can dump properties OF builds in the Device-Tree.
 
if you know how to dump them in OS X/IOReg/Linux PPC

then surely that would work with an x86 system too?

for example a GeForce 7600 AGP in an AGP based x86 system booted into linux or OS X?


as you say the GeForce 7xxx drivers in OS X are completely universal so all G7x based cards should work just fine in a PPC system :)

if either a proper ROM can be made for them, (or some sort of kext injector?)
It's a property the IOReg gains from OF, I doubt x86 OS X has it, and I don't have any hardware that could run the 7600GT anymore for OS X.

But if we could find someone that had an Intel iMac with one, or a Hackintoch:

Code:
ioreg -lw0 | grep NVDA,BMP
 
The patch should be safe for normal GPUs or other PCI/AGP cards.
Thanks!
Can you provide output from lspci
Code:
0 > lspci
00:0b.0         [106b:0020] [060000] 6b10200016003022000000060810000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000040080000000000000200000e00000000c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200100003020007000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00:10.0         [10de:0221] [030000] de1021020400b002a100000300f8000000000092080000a00000009100000000000000000000000000000000de10100000000090600000000000000000010501de101000020030001702001f000000000100000000000000ced623000f0000000144020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010440c100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
                                     00008010:92000000.ff000000
                                     00008014:a0000008.e0000008
                                     00008018:91000000.ff000000
                                     00008030:90000000.fffe0001
 ok
and dump-device-tree
See attached textfile.
I don't think BootROM 4.8.7f1 or later should require patch for 512MB BAR.
I got a little more than without the patch in the Sawtooth. But the screen was completely garbeled and OS did not bootup.
A ROM dump and a dictionary dump of the 5.1.5f2 BootROM would be helpful.
What's the best way to dump the BootROM in a G5? Can this be done from the OS or from OF?
 

Attachments

  • sawtooth_device_tree.zip
    34 KB · Views: 91
Last edited:
@LightBulbFun could likely reflow the GPU for you, it likely needs the GPU complexly reballed, and who is to say about the VRAM.
Hmm, if these things are really that rare - only 2.500 ever in existance - it might be well worth a try. Depends on how much @LightBulbFun would ask for the service or if he likes to play around with it a little... 😉
Giving the time and expense of having it reballed, and the fact that it will still run so hot it just fails again, we need to figure the G71 7900 cards if we can.
It has this special edition of the Arctic Cooler on it and a fat copper plate also covering the RAM-chips. Much better cooling as the reference 7800s. So as long as it worked, i never had any temperature issues. Even with the higher clocks.
 
I got a little more than without the patch in the Sawtooth. But the screen was completely garbeled and OS did not bootup.
That's what I get on my PCI 6200 card with 512MB, so maybe there is hope that an edit to the soft strap will fix that and a nvram patch for 512MB BAR1.

My soft strap is
Code:
FF814F7E 001E8081 FFFFFF7F 00000080 2200A5D1

I think that's correct? D1 is the checksum byte? or is it just A5?

Also I think the G5's made before 2004 need the 512MB nvram patch too.

Anyway, @joevt if you could help me set the bits correct for the 512MB BAR1 in the soft strap, please?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.