Radeon X1900 G5 Mac Edition Cheap 'n Easy Flashing Guide

[eastone]

Connect your second PC x1900GT card and get dump-device-tree from that. It might be a more suitable match with the Apple firmware?

The problem with the your first PC X1900GT or with the PC & Mac ROM that you applied to your card is that the PC firmware has device IDs that don't match the Mac firmware.

Mac firmware has device ID 7240.
PC firmware has device ID 724B and a secondary function with device ID 726B.

I've attach a new combined firmware where the Mac firmware comes first.
dump-device-tree with this new ROM.
Does it allow the card to work in Mac OS X?
Does the card still work in MintPPC?

If it doesn't work in the latter, then we can try changing device IDs in one of the firmwares to match the device IDs in the other firmware.

WOW, we’re making progress. Your new combined Mac & PC firmware works on Mac (but only OSX!!! unfortunately MintPPC doesn’t work—the screen freezes on the splash) and it also WORKS on PC!!!!!!

Let’s start by focusing on the first card. I’ll also include the device tree dump from the second card in this post. For anyone interested—if there are any—I’m also attaching photos of my cards. The top card has a 128 KB EEPROM, while the bottom one has a 64 KB EEPROM. If I find a larger EEPROM, I’ll replace it on the second card and flash your firmware onto it.

 

[apmarmotta]

WOW, we’re making progress. Your new combined Mac & PC firmware works on Mac (but only OSX!!! unfortunately MintPPC doesn’t work—the screen freezes on the splash) and it also WORKS on PC!!!!!!

Let’s start by focusing on the first card. I’ll also include the device tree dump from the second card in this post. For anyone interested—if there are any—I’m also attaching photos of my cards. The top card has a 128 KB EEPROM, while the bottom one has a 64 KB EEPROM. If I find a larger EEPROM, I’ll replace it on the second card and flash your firmware onto it.

Great, is the right way! But the goal is a working card with linux ;-)

 

[randomdamage]

Hi - I finally got my 64K flash rom swapped out for a 128K flash rom. As a reminder, I have the rev 1 version of the card the looks identical to the original retail version. With the combined Mac / PC rom flashed, I happily can still boot into OS X. Trying MintPPC, however, I see a kernel message when the card is probed flagging an invalid PCI ROM header signature. Attached photo shows the kernel messages - note I am running with an HD 6xxx card installed as well.

 

[joevt]

Hi - I finally got my 64K flash rom swapped out for a 128K flash rom. As a reminder, I have the rev 1 version of the card the looks identical to the original retail version. With the combined Mac / PC rom flashed, I happily can still boot into OS X. Trying MintPPC, however, I see a kernel message when the card is probed flagging an invalid PCI ROM header signature. Attached photo shows the kernel messages - note I am running with an HD 6xxx card installed as well.

Did you use the Mac & PC ROM or the earlier PC & Mac ROM?
Can you use the flash utility to read the flash so we can make sure it flashed correctly?
Connect using telnet to capture output from dump-device-tree
Then maybe flash the other ROM, get another dump-device-tree, and do your tests again.

 

[eastone]

Great, is the right way! But the goal is a working card with linux ;-)

Yes, that would be great. The question remains: why does a Mac recognize a PPC ROM, a PC recognizes an x86 ROM, but Linux doesn't? Is this a problem with the ROM configuration or a problem with Linux itself?

 

[randomdamage]

I’ll play around with my card this weekend. I had flashed it with the ROM from post #125. I didn’t use atiflash on a PC, rather wrote the flash ROM using a programmer before installing it on the board.

 

[randomdamage]

Here is the relevant section from dump-device-tree when run with the flash programmed with the copy in post #125

/pci@0,f0000000/ATY,PrionaceParent@0
PROPERTIES:
#address-cells 00000001
#size-cells 00000000
AGP_Address_Block 10000000
AGP_Address_Range 00000000 ffffffff
AGP_Alignment 10000000
AGP_AllowOverlap 00000001
ATY,Card# 3130392d 41353230 33312d30 3000
ATY,FCODE_MEM 10000000
ATY,Fcode 322e3030 00
ATY,Flags 00000488
ATY,MCLK 000927c0
ATY,MRT 00000070 007f0000 8000006a 00000010 8000006b 00000010
ffffffff 00000002 8000006b 00000000 8000006a 00000000
80000008 03004412 00000070 007f0000 80000068 00000100
80000069 00000100 ffffffff 00000002 80000060 020f6ffe
ffffffff 00000002 80000060 120f6ffe ffffffff 00000002
80000068 00000180 80000069 00000180 80000068 00000080
80000069 00000080 80000068 00000000 80000069 00000000
00000070 007f0000 80000008 03004412 80000076 00020000
80000076 00010221 80000076 0001400a 80000076 00110532
ffffffff 000000c8 80000076 00010432 80000076 00020432
80000076 00030432 80000076 00030432
... 00000120 bytes total
ATY,RefCLK 00006978
ATY,Rom# 3131332d 41353230 37302d31 303900
ATY,SCLK 0007a120
R2AD 5c3e8202 90ff0030 00000000 00000000 3c280780 08200030
002004b0 04d30003 000604b0 07800001 00000000 00000000
00000000 00000000 00000000 00000000
VRAM,totalsize 10000000
assigned-addresses c20a0010 00000000 b8000000 00000000 08000000
820a0030 00000000 b0020000 00000000 00020000
820a0018 00000000 b0000000 00000000 00010000
class-code 00030000
device-id 00007240
device_type ATY,DDParent
devsel-speed 00000000
fcode-rom-offset 00000000
interrupts 00000001
max-latency 00000000
min-grant 00000000
model ATY,RadeonX1900
msi-capability 000a0080
name ATY,PrionaceParent
pci-e-capability 000a0058
reg 000a0000 00000000 00000000 00000000 00000000
420a0010 00000000 00000000 00000000 08000000
020a0018 00000000 00000000 00000000 00010000
020a0030 00000000 00000000 00000000 00020000
revision-id 00000000
subsystem-id 00007240
subsystem-vendor-id 00001002
vendor-id 00001002
METHODS:
close close-vector decode-unit draw-logo open
open-vector restore write
/pci@0,f0000000/ATY,PrionaceParent@0/ATY,Prionace_A@0
PROPERTIES:
EDID 00ffffff ffffff00 06103692 00005702 14130104 a5342078
266ea1a7 554c9d25 0e505400 0000d100 01010101 01010101
01010101 0101283c 80a070b0 23403020 36000644 2100001a
000000ff 00324139 32303031 54304b30 0a200000 00fc004c
45442043 696e656d 610a2020 00000000 00000000 00000000
00000000 00000130
NVPR 06800600 00190000 00000000 00000000 00000000 00000000
00000000 00000000 00000052 00000000 0000
address b8008000
character-set ISO8859-1
compatible ATY,Prionace
connector-type 00000200
depth 00000008
device_type display
display-timing-flags 00000000
display-type 4c434400
height 000004b0
iso6429-1983-colors
linebytes 00000800
name ATY,Prionace_A
reg 00000000
width 00000780
METHODS:
#columns #lines background-color blink-screen
char-height char-width close close-vector color!
color@ column# ddc2-get-byte ddc2-send-byte
ddc2-set-start ddc2-set-stop ddc2ci-monitor-off
ddc2ci-monitor-on delete-characters delete-lines
device-vectors dimensions disable-videomode
draw-character draw-logo draw-logo draw-rectangle
enable-videomode erase-screen fill-rectangle font-adr
fontbytes foreground-color frame-buffer-adr
get-colors insert-characters insert-lines
inverse-screen? inverse? invert-screen line# mode#
open open-vector read-rectangle reset-screen restore
screen-height screen-width set-colors set-depth set-mode
show-modes toggle-cursor widths window-left window-top
write
/pci@0,f0000000/ATY,PrionaceParent@0/ATY,Prionace_B@1
PROPERTIES:
NVPR 967f0600 00180780 04b00820 060a04d3 03090001 3c280000
06103692 00000000 00000052 00000000 0000
character-set ISO8859-1
compatible ATY,Prionace
connector-type 00000004
depth 00000008
device_type display
display-type 4e4f4e45 00
height 000001e0
iso6429-1983-colors
linebytes 00000300
name ATY,Prionace_B
reg 00000001
width 00000280
METHODS:
#columns #lines background-color blink-screen
char-height char-width close close-vector color!
color@ column# ddc2-get-byte ddc2-send-byte
ddc2-set-start ddc2-set-stop ddc2ci-monitor-off
ddc2ci-monitor-on delete-characters delete-lines
device-vectors dimensions disable-videomode
draw-character draw-logo draw-logo draw-rectangle
enable-videomode erase-screen fill-rectangle font-adr
fontbytes foreground-color frame-buffer-adr
get-colors insert-characters insert-lines
inverse-screen? inverse? invert-screen line# mode#
open open-vector read-rectangle reset-screen restore
screen-height screen-width set-colors set-depth set-mode
show-modes toggle-cursor widths window-left window-top
write

 

[srp]

After 2 dead cards from eBay, I finally got a *working* X1900 XT. I threw Codex at the ROM file that I flashed, and it found a way to patch the X1900 G5 ROM to support 512MB. It correctly reports 512MB in System Profiler and I was able to verify it can now use over 256MB of VRAM:

x1900-512mb.rom

drive.google.com

This patched ROM keeps the working G5 X1900 identity/display code, but changes the VRAM size and AGP/aperture properties from 256 to 512MB. It also imports the memory controller layout from the Mac Pro X1900 ROM, so it actually addresses more than 256MB properly.

Overall, it seems stable, but obviously use at your own risk. You should just be able to flash back to your 256MB ROM if it doesn't work right.

If you try it on your system, please let me know if it works! In the meantime, I will keep stress testing and report back if I have any issues.

 

[joevt]

After 2 dead cards from eBay, I finally got a *working* X1900 XT. I threw Codex at the ROM file that I flashed, and it found a way to patch the X1900 G5 ROM to support 512MB. It correctly reports 512MB in System Profiler and I was able to verify it can now use over 256MB of VRAM:
View attachment 2628602
View attachment 2628596

x1900-512mb.rom

drive.google.com

This patched ROM keeps the working G5 X1900 identity/display code, but changes the VRAM size and AGP/aperture properties from 256 to 512MB. It also imports the memory controller layout from the Mac Pro X1900 ROM, so it actually addresses more than 256MB properly.

Overall, it seems stable, but obviously use at your own risk. You should just be able to flash back to your 256MB ROM if it doesn't work right.

If you try it on your system, please let me know if it works! In the meantime, I will keep stress testing and report back if I have any issues.

I compared your ROM with the original. It changes most (but not all) occurrences of 0x10000000 (256 MiB) with 0x20000000 (512 MiB). And it changes a handful of other values that I don't know the purpose of. Does Codex understand fcode or Forth or Open Firmware? Does it cross reference the code with ATI registers used in Linux drivers or described in ATI documentation?

Your ROM has the checksum updated correctly. Did Codex do that for you, or did you or it use a Open Firmware fcode tokenizer?

I think the original ROM is able to determine the 512 MiB BAR size (stored to value_9f9 which is defaulted to 256 MiB but the default is ignored and replaced by the detected value) but it doesn't use the detected BAR size for the other occurrences (value_bb0 which is used for VRAM,totalsize and ATY,FCODE_MEM properties, and the hard coded values for the AGP_Address_Block and AGP_Alignment properties).

 

[kolutshan]

After 2 dead cards from eBay, I finally got a *working* X1900 XT. I threw Codex at the ROM file that I flashed, and it found a way to patch the X1900 G5 ROM to support 512MB. It correctly reports 512MB in System Profiler and I was able to verify it can now use over 256MB of VRAM:
View attachment 2628602
View attachment 2628596

x1900-512mb.rom

drive.google.com

This patched ROM keeps the working G5 X1900 identity/display code, but changes the VRAM size and AGP/aperture properties from 256 to 512MB. It also imports the memory controller layout from the Mac Pro X1900 ROM, so it actually addresses more than 256MB properly.

Overall, it seems stable, but obviously use at your own risk. You should just be able to flash back to your 256MB ROM if it doesn't work right.

If you try it on your system, please let me know if it works! In the meantime, I will keep stress testing and report back if I have any issues.

I just flashed my X1900 XT and can confirm, that it appears to work. So far I only booted up OSX and that seems to run well - including now showing all 512MB of RAM. Thanks for the great work!

 

[srp]

Does Codex understand fcode or Forth or Open Firmware? Does it cross reference the code with ATI registers used in Linux drivers or described in ATI documentation?

Will start by saying I have no prior experience patching these kinds of ROMs and I understand the dangers of using AI for these kinds of tasks. However, Codex took an informed approach to patching (including reviewing yours and other posts from this exact forum), understood the F Code format and specifically made sure to detokenize to make its changes and retokenized and verifying the checksum before outputting a final file.

Here is a write-up it gave me:


X1900 512 MB ROM Patch Write-Up

We started from the known-working Power Mac G5 X1900 ROM, x1900p.rom, because it already had the correct Open Firmware/FCode path for a PCIe PowerMac G5. The problem was that this ROM came from the G5 X1900 Mac Edition, which was a 256MB card, while our physical PC Radeon X1900 XTX board had 512 MB installed. Public card history matched that split: the G5 X1900 Mac Edition was 256 MB, while the Mac Pro X1900 XT was 512 MB (Macworld (https://www.macworld.com/article/182241/radeon-11.html), MacRumors (https://www.macrumors.com/2006/11/01/ati-releases-x1900-for-pci-e-g5s-updated/)).

The first patch changed the ROM’s FCode-visible memory size properties from 256 MB to 512 MB, including the main size token and the AGP/aperture-related properties. That made macOS report 512 MB, but early probes showed that reporting alone was not enough: the card could still corrupt or freeze under high VRAM pressure. The useful lesson from joevt-style Open Firmware/device-tree work was that these ROM properties matter because the Mac driver consumes the FCode-created device-tree values, not just the raw PC BIOS layout.

The final working ROM, Probe 6, kept the stable G5 identity/display path but imported the Mac Pro 512 MB X1900 memory-controller layout constants. In practical terms, we changed the card from “a 256 MB G5 X1900 ROM claiming 512 MB” into a G5-bootable ROM whose size, aperture, and memory-layout constants agree with a 512 MB X1900-class board.

The result was verified in macOS, not just by System Profiler. The ATI driver reported 512 MB total VRAM, QE/CI remained hardware accelerated, texture and FBO tests passed, and the driver’s own vramFreeBytes counter showed about 418 MiB of primary VRAM in active use for a 30-second render-target hold. That proves the upper VRAM is genuinely usable, not just cosmetically reported.

References we used or leaned on:

- ATI/Radeon Linux register knowledge
Helped interpret memory-controller style constants and avoid treating every 0x10000000 literal as a VRAM-size value.
- Existing G5 ROM: x1900p.rom
This was the real base. It provided the working PowerMac G5 FCode, device identity, display bring-up path, and
checksum format.
- Mac Pro X1900 XT 512 MB ROM
Used as the main 512 MB Apple reference. Probe 6 imported matching memory-layout constants from this ROM while
keeping the G5 boot/display identity.
- PC X1900 XT/XTX 512 MB ROM
Used as a board-family comparison source to confirm we were dealing with a 512 MB R580-class layout, not just
editing strings.
- Mac OS X ATI driver reverse engineering
ATIRadeonX1000.kext was important. We found writePerformanceStats, ATIR500Memory::total_free(),
set_display_mode_and_vram(), and confirmed the driver really reads the ROM/device-tree memory size and publishes
vramFreeBytes.
- Open Firmware / FCode behavior
The key idea was that the G5 consumes FCode-generated properties before the OS driver binds. That is why patching
the ROM properties mattered more than just changing a PC BIOS table.
- Public card history
Sources like Macworld/MacRumors confirmed the product split: G5 X1900 Mac Edition was 256 MB, Mac Pro X1900 XT was
512 MB. That explained why the stock G5 ROM had the wrong memory assumption for your PC X1900 XTX board.
- Live empirical tests
The most important reference was the machine itself: System Profiler, ioreg performance counters, texture readback,
FBO allocation, and the 410+ MiB hold test. That’s what proved which patches were real versus cosmetic.

 

[LightBulbFun]

is there any mention on how the Pixle shaders/ROP's of the card are enabled?

details are scant but AFAIK the X1900 G5 card is based on the X1900 GT, so 36 shaders etc, where as the X1900 XT is a 48 shader card

so thats something I have often wondered about when people flash the X1900 G5 ROM to their X1900 XT's are we leaving some performance on the table here are some Shaders being un-used?

tho interestingly what I have seen of the X1900 G5, actual genuine ones I *think* IIRC they have the Device ID of an X1900 XTX of all things...

 

[kolutshan]

After playing Doom 3 on max settings for around 2 hrs I would say that this new 512MB rom (X1900 XT) is stable. Thanks again!

 

[srp]

Jazzzny and I were testing everything out yesterday, and just putting the card on this ROM without modifying clock speeds or anything else causes significantly higher benchmark scores. OpenMark jumped to 18874 (same as flashed X850XTPE), while on the benchmarking tool he created, we got higher scores on everything (beyond margin of error) except for fixed function lighting and FBO offscreen render, which dropped noticeably (?)

I wrote an overclocking tool for the X1900 that now lets you modify core clock, memory clock, and hopefully I can get it to change the voltage too. I was able to push my card from a 500MHz base clock to 625MHz and the memory clock from 600MHz to 700MHz, staying stable and pushing out extra numbers on benchmarks.

If I can unlock voltage, I think this is now pretty much tied for the spot of "fastest PPC GPU".

If anyone wants to give it a try I'll release it soon.

 

[Jazzzny]

Hello everyone, I've put together a package that will update a flashed X1900 to the 512MB ROM directly from Mac OS X.
Simply run the included script and reboot - you should now have all 512MB recognized.

This is possible because of a driver from the ATI Radeon X1900 XT Firmware Update for the Mac Pro, which just so happens to be a universal binary.

 

[jktwice]

Hello everyone, I've put together a package that will update a flashed X1900 to the 512MB ROM directly from Mac OS X.
Simply run the included script and reboot - you should now have all 512MB recognized.

This is possible because of a driver from the ATI Radeon X1900 XT Firmware Update for the Mac Pro, which just so happens to be a universal binary.

Does this work only on Leopard or Tiger or will it work on both?

 

[Jazzzny]

I have not tried Tiger but I don’t see why it wouldn’t work.

 

[travsG5]

This worked on a X1900XT out of a Mac Pro. I had to use Rufus to make the FreeDos USB disk instead however. Rufus is actually easier as it includes FreeDOS. I had to play some games with my PC's BIOS to be able to boot, but I got it finally. Also was able to use Jazzzny's script to show the 512MB in the System Profiler. Performance seems pretty close to the 7800GT I had in it, but this frees that card up to go into my 2.3 Dual core either way. Thank you for this guide and script!