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.
We don't need input. Just output.
" enet:telnet,192.168.0.111" io dumpbytes
Didn't seem to work, I'm sure I just did it wrong:

Code:
0 > FFF00000 FF000000 100000 0 do-map  ok
0 > FF000000 100 dump

That dumped the first 100 bytes to screen.

Code:
 0> : dumpbytes bounds ?do i 3f and 0= if cr then i c@ 2 u.r loop cr ;

Next I did:

Code:
" enet:telnet,10.1.2.3" io dumpbytes

Then I connected to the telnet session on the remote computer, but it just locked up after:

Code:
escape charactor is '^]'


Without any other output.
 
Didn't seem to work, I'm sure I just did it wrong:

Code:
0 > FFF00000 FF000000 100000 0 do-map  ok
0 > FF000000 100 dump

That dumped the first 100 bytes to screen.

Code:
 0> : dumpbytes bounds ?do i 3f and 0= if cr then i c@ 2 u.r loop cr ;

Next I did:

Code:
" enet:telnet,10.1.2.3" io dumpbytes

Then I connected to the telnet session on the remote computer, but it just locked up after:

Code:
escape charactor is '^]'


Without any other output.
dumpbytes requires the address and length:
Code:
" enet:telnet,10.1.2.3" io FF000000 100000 dumpbytes
 
Doesn't seem to work with the BAR1 patch for the Beige 2.0f1. I get the same screen corruption I get without the BAR1 patch.

It maybe I have just mistyped the patch?

Here is with the nvram patch applied:

I'm not sure line 5 of the patch, is that ' before m5?

And without the patch:
Yes, single quote '

Last line should be 1e 971 & 1c + code!
 
dumpbytes requires the address and length:
Code:
" enet:telnet,10.1.2.3" io FF000000 100000 dumpbytes
Doesn't work for the QS, telnet session just locks up.

So I tried this as well:

Code:
" enet:telnet,10.1.2.3" io ff000000 100 dump

That seemed to dump about the first 8 or 10 bytes then the telnet session locked up.

On the G5( SP 1.6Ghz PCI ) I tried to just dump the first 100 bytes local to screen without a telnet session:

Code:
fff00000 ff000000 100000 0 do-map
ff000000 100 dump

That just locked up the G5 as soon as it tried to access with the only output being:

Code:
ff000000:
 
Yes, single quote '

Last line should be 1e 971 & 1c + code!
That doesn't seem to work either, I don't spot any change to the reg or AA .properties.

IMG_0543.jpeg

IMG_0545.jpeg
 
That doesn't seem to work either, I don't spot any change to the reg or AA .properties.
Check #487 again. c should be c + in the 2nd to last line like this:
96e & dup 3c + ' m5 44 + swap $R 9c + ' m5 c + $R

You should do this with serial port so you can copy/paste. You need a Mac serial printer cable (like for an Image Writer II) instead of a modem cable.

You had that line correct in your previous attempts... Did it get erased? The nvedit command does allow moving up and down through existing lines so you don't need to erase everything when making changes.

This nvramrc might get replaced by Mac OS 9 or Mac OS X or XPostFacto. In that case you'll want to modify an OFpt resource to include the patch.
 
Doesn't work for the QS, telnet session just locks up.

So I tried this as well:

Code:
" enet:telnet,10.1.2.3" io ff000000 100 dump

That seemed to dump about the first 8 or 10 bytes then the telnet session locked up.

On the G5( SP 1.6Ghz PCI ) I tried to just dump the first 100 bytes local to screen without a telnet session:

Code:
fff00000 ff000000 100000 0 do-map
ff000000 100 dump

That just locked up the G5 as soon as it tried to access with the only output being:

Code:
ff000000:
That's a weird IP address. Are you connecting the Macs directly together? I have my G5 connected to a Ethernet switch which is connected to a router which is the cable modem. I boot the G5 and look at the network settings to see what IP address was assigned by DHCP. Then I use that IP address in Open Firmware.

What version of telnet are you using? What Mac and macOS version are you using for telnet? I use Monterey on my MacPro3,1.

Before doing do-map, check the list of translations

For 64 bit CPUs:
Code:
dev /cpus/@0
cr " translations" active-package get-package-property 0= if bounds do i @ u.  i 4+ @ u.  i 8 + @ u.  i c + @ u.  i 10 + @ u. cr 14 +loop then

For 32 bit CPUs:
Code:
dev /cpus/@0
cr " translations" active-package get-package-property 0= if bounds do i @ u.  i 4+ @ u.  i 8 + @ u.  i c + @ u.  i cr 10 +loop then

The translations show:
32-bit virtual address, 32-bit size, 32 or 64 bit physical address, mode

It is possible to map the same physical address to multiple virtual addresses.

The do-map command is defined like this (32-bit physical and virtual addresses)
Code:
: do-map ( phys virt size mode -- )
\ mode is one of these:
40 constant w___ \ Write-through
28 constant _i_g \ Cache-Inhibited, Guarded
10 constant __m_ \ Memory-coherent

Try this (after making sure there's no translation for virtual address 40000000 already):
Code:
: dumpbytes bounds ?do i 3f and 0= if cr then i c@ 2 u.r loop cr ;  ok
fff00000 40000000 100000 28 do-map  ok
40000000 100000 dumpbytes
 
Check #487 again. c should be c + in the 2nd to last line like this:
96e & dup 3c + ' m5 44 + swap $R 9c + ' m5 c + $R

You should do this with serial port so you can copy/paste. You need a Mac serial printer cable (like for an Image Writer II) instead of a modem cable.

You had that line correct in your previous attempts... Did it get erased? The nvedit command does allow moving up and down through existing lines so you don't need to erase everything when making changes.

This nvramrc might get replaced by Mac OS 9 or Mac OS X or XPostFacto. In that case you'll want to modify an OFpt resource to include the patch.
Nice, that was the issue, no more screen corruption!

I'll have to bust out ResEdit and add this to XPF, thanks.

This is the EVGA 512MB PCI card with the Mac/PC ROM.

IMG_0547.jpeg

IMG_0548.jpeg
 
  • Like
Reactions: LightBulbFun
@domii we now have a working ROM for this EVGA 512MB PCI card and a way to flash it, tho it requires nvram patches to work in most PowerMac's and clones, and depending on the version of Open Firmware you have it may need a few more patches to the FCode ROM.

The good news is it works in both Macs and PCs with it's dual ROM.

We just tricked NVFLASH by putting the PC VBIOS image as the first image in the ROM file, and the FCode image as the second image in the ROM file.
 
@domii we now have a working ROM for this EVGA 512MB PCI card and a way to flash it, tho it requires nvram patches to work in most PowerMac's and clones, and depending on the version of Open Firmware you have it may need a few more patches to the FCode ROM.

The good news is it works in both Macs and PCs with it's dual ROM.

We just tricked NVFLASH by putting the PC VBIOS image as the first image in the ROM file, and the FCode image as the second image in the ROM file.
Oh nice, ok! I will figure out where I put that thing and give this a try soon.

Was just distracted with some other projects.

I did run the Openmark tonight on the BFG 6200 though, not exactly stellar results but still not bad either considering the age and the 50mhz bus on that Powertower. Unless that is still low? Might not have it in the most ideal PCI slot and its probably sharing bandwidth with the SATA card.
 

Attachments

  • thumbnail_IMG_6195.jpg
    thumbnail_IMG_6195.jpg
    233.9 KB · Views: 88
I was hoping to report nice things about the EVGA 512MB card working with Tiger, however, it seems while the card works with OF I get reports of bus errors trying to boot Tiger from my SiL3112 SATA SSD.

Something seems incompatible with the Beige G3. Also if I boot OS 9 with the EVGA card installed I end up with data corruption on the SSD.

These issues go away if I install the 256MB card. I'm not sure I even want to bother trying to fix these issues. I don't think I'd really see any real world benefit from the extra VRAM.

We figured the issue with 512MB cards, and 256MB PCI should be fine in Old World. So I would say with Old World just avoid 512MB cards. With New World AGP systems 512MB should be fine, and I didn't have any real issues with 512MB PCI cards in New World, but there again it's kind of a waste other than maybe in the B&W/Yikes 66Mhz PCI Slots.

I don't have a B&W/Yikes, so that's beyond the scope of my testing.
 
These issues go away if I install the 256MB card. I'm not sure I even want to bother trying to fix these issues. I don't think I'd really see any real world benefit from the extra VRAM.
As said further up the thread, the only "real world" benefit of these 512MB i could imagine was, if we would get this Gainward Bliss to run in some powerful AGP G5. But at the moment my G5 as well as the Bliss seem to be somehow dead.

I again played around with the Bliss for some while. I thought i had spotted some weak/broken solder joints near to the power input which i then resoldered. I tested in the Quicksilver and first it looked like success. I was even able to finish one run in OpenGL Extensions Viewer with very promising results...

Gainward Bliss 7800GS 512MB...

bliss_oglviewer_3.png

...GeForce 6600GT...

6600gt_oglviewer_3.png

...but then it went black again! 😟
 
Does this fit on some "normal" (i. e. 128K) EEPROM or does it need the exotic thing that is on your particular EVGA card?
Should work with any 128k EEPROM, but it depends on the ROM's you start with, if they are both less than or = to 64k.

But I have to use this for the EVGA card as NVFLASH won't flash the FCODE ROM by itself. We put the PC VBIOS first in the ROM image to "fool" NVFLASH into flashing the card.
 
  • Like
Reactions: flyproductions
As said further up the thread, the only "real world" benefit of these 512MB i could imagine was, if we would get this Gainward Bliss to run in some powerful AGP G5. But at the moment my G5 as well as the Bliss seem to be somehow dead.

I again played around with the Bliss for some while. I thought i had spotted some weak/broken solder joints near to the power input which i then resoldered. I tested in the Quicksilver and first it looked like success. I was even able to finish one run in OpenGL Extensions Viewer with very promising results...

Gainward Bliss 7800GS 512MB...

View attachment 2108236
...GeForce 6600GT...

View attachment 2108237
...but then it went black again! 😟
So is there a BAR1 nvram patch for 512MB in the QS, or is the card still identified as 265MB?
 
That's a weird IP address. Are you connecting the Macs directly together? I have my G5 connected to a Ethernet switch which is connected to a router which is the cable modem. I boot the G5 and look at the network settings to see what IP address was assigned by DHCP. Then I use that IP address in Open Firmware.

What version of telnet are you using? What Mac and macOS version are you using for telnet? I use Monterey on my MacPro3,1.

Before doing do-map, check the list of translations

For 64 bit CPUs:
Code:
dev /cpus/@0
cr " translations" active-package get-package-property 0= if bounds do i @ u.  i 4+ @ u.  i 8 + @ u.  i c + @ u.  i 10 + @ u. cr 14 +loop then

For 32 bit CPUs:
Code:
dev /cpus/@0
cr " translations" active-package get-package-property 0= if bounds do i @ u.  i 4+ @ u.  i 8 + @ u.  i c + @ u.  i cr 10 +loop then

The translations show:
32-bit virtual address, 32-bit size, 32 or 64 bit physical address, mode

It is possible to map the same physical address to multiple virtual addresses.

The do-map command is defined like this (32-bit physical and virtual addresses)
Code:
: do-map ( phys virt size mode -- )
\ mode is one of these:
40 constant w___ \ Write-through
28 constant _i_g \ Cache-Inhibited, Guarded
10 constant __m_ \ Memory-coherent

Try this (after making sure there's no translation for virtual address 40000000 already):
Code:
: dumpbytes bounds ?do i 3f and 0= if cr then i c@ 2 u.r loop cr ;  ok
fff00000 40000000 100000 28 do-map  ok
40000000 100000 dumpbytes
That worked for the G5.
 

Attachments

  • G5_ROM_Dump.txt
    2 MB · Views: 80
That worked for the G5.
It's a good rom dump. Updated #487 with a patch for that G5 (OpenFirmware 4 5.1.5f2) since it does not have 512MB BAR support in Open Firmware.
What model is it? I think you said you had a 2004 G5 1.8Ghz ( PCI )?
Can you provide output for dev / ls unselect-dev " devalias" evaluate " printenv" evaluate dump-device-tree words
In my list of Mac ROMs (see #1 ), it is the last one limited to 256MB BAR support.

I gave the FW800 MDD patch a quick test with my FW800 MDD and my Quadro FX 4500 (which is a 512MB PCIe card from/for my G5 Quad) but sadly I get the same result as without it, OF hard locks as it attempts to output video to the monitor

(the patch installed into NVRAMRC fine and the system on its own still boots to OF just fine with it in place, so its not regressing anything at least, but the moment I chuck the FX 4500 it all falls over like it normally does)
I also fixed the patch for G4 (FW800).

As said further up the thread, the only "real world" benefit of these 512MB i could imagine was, if we would get this Gainward Bliss to run in some powerful AGP G5. But at the moment my G5 as well as the Bliss seem to be somehow dead.

I again played around with the Bliss for some while. I thought i had spotted some weak/broken solder joints near to the power input which i then resoldered. I tested in the Quicksilver and first it looked like success. I was even able to finish one run in OpenGL Extensions Viewer with very promising results...

Gainward Bliss 7800GS 512MB...

View attachment 2108236
...GeForce 6600GT...

View attachment 2108237
...but then it went black again! 😟
You are using 512MB cards in Macs that don't support 512MB BAR? Without using the 512MB BAR patch?
Or are these 512MB VRAM cards with 256MB BAR?



I am still working on FCode revision: 2152.2 for Old World Mac (7800GT, etc.)
I wonder if it can replace the 2149 rom for 6600 (but you would have to copy the 6600 straps and BMP info).
 
Last edited:
You are using 512MB cards in Macs that don't support 512MB BAR? Without using the 512MB BAR patch?
Or are these 512MB VRAM cards with 256MB BAR?
Sadly in this case the first goal can only be to get the card reliably working at all, if possible. It did for years. Only 256MB, of course. But now it only runs for minutes. If at all. If it runs, it does just like normal, showing no distortion, artefacts whatsoever. So it doesn't seem to be much. But i am just unable to find it. And, if there really only 2.500 have ever been produced, finding a replacement should be farely impossible.
I am still working on FCode revision: 2152.2 for Old World Mac (7800GT, etc.)
I wonder if it can replace the 2149 rom for 6600 (but you would have to copy the 6600 straps and BMP info).
Attached is the fCode-ROM i'm using with this card. Seems to be 2149-based.
 

Attachments

  • BlissMac.rom.zip
    31 KB · Views: 71
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.