*** Do NOT attempt to do this on your MVC flashed RX580 regardless if that's the Sapphire PULSE RX580 8GB or not ***
*** This mod CANNOT make any RX580 shows boot screen ***
Forum member Teddy managed to get a Sapphire PULSE RX580 8GB card. But the part number is changed already, so, can't identify itself correctly in MacOS (technically speaking, we can't really see the part number in MacOS, but if it's "right", High Sierra should able to recognise this card. Therefore, the R9 XXX in "about this Mac" can be used as an indication that the part number is "wrong"). He showed me a post about how to "fix" it, and that guide suggest users to use the Polaris BIOS Editor to open an edited ROM, then save it again. To me, this looks like the process to fix the checksum. I never own this card, and never play around with the Polaris BIOS Editor. But Teddy showed me this warning message from the Polaris BIOS Editor.
Despite the PULSE ROM size is just 256k, it seems the Polaris BIOS Editor may still base on the 512k size assumption to apply the checksum fix. Which may eventually apply the fix on an important byte and causing error. More than one users reported that, the card "fixed" in this way will only shows back screen once driver is loaded (in Windows), or all the way black screen (in MacOS).
So, I worked with him to correctly fix the card. The following records what we did. I use macOS calculator and Hexminer (Mac apps) to assist him because I work with him via the internet, and I am in MacOS. In fact, the whole process can be done within Windows. No need to boot back to MacOS until everything is done. All you need is
1) ATIWinFlash.exe
2) Any Hex calculator
3) Any Hex Editor
I am quite sure the whole process can also be done in DOS or Linux, but I don't know how to do it. So, the following procedures are all base on Windows. You can do that in a PC, or Bootcamp Windows on the Mac Pro (and NO, this cannot be done within Parallel Windows, or any virtual machine).
He sent me the original dumped ROM (by using ATIWinFlash in Windows. GPU-Z can also be used to dump the ROM), I open it (with HexMiner, but any hex editor can do the job), and obviously the part number is not the one that same as the Apple developer kit. (N.B. Before you do anything to the ROM image, backup your original dumped ROM at least twice, and only edit the copy of copy, NEVER edit the original ROM image backup. We should ALWAYS keep a MASTER BACKUP.)
So, we apply the "part number fix", change it to 113-4E353BU-O4E (N.B. Make sure you UPDATE / REPLACE the required byte, NOT add / insert some new bytes) (113-4E3531U-O4V should also work, but we never test it)
The work is fairly easy, only 5 bytes need to be changed in this case.
However, after this "part number fix", the checksum of ROM may be wrong (and 99.99% of time, it is wrong). So, we need to fix that as well. Since we know the Polaris BIOS Editor will cause issue, we use a more complicated but safer way to manually fix it.
First, we need a hex calculator to workout the checksum difference. This is easy, macOS already included a calculator, and can be switch to hex mode. In this case, the 5 bytes changed as follow (all numbers are in Hexadecimal).
31 -> 34
38 -> 35
37 -> 33
30 -> 42
42 -> 45
If we put all the new numbers in the Hex calculator, 34+35+33+42+45 = 123
And then minus all the old numbers, 123 - 31 - 38 - 37 - 30 - 42 = 11
That means, we need to find a useless byte and make it 11 smaller than the original number. A very standard way to do that is to find the very large piece of FF, which located at the end of the ROM, and change one of them from FF to EE (FF - 11 = EE from the Hex calculator). An example is like this.
I am not familiar with the ROM, and simply avoid to change the very last few bytes, just in case it's used to define the end of the ROM. However, this is just an example. We did NOT correct the checksum in this "standard" way. And this ROM is never tested at the end. (update: leVel tested this method on his Nitro+, and doesn’t work. So please avoid this method until further update)
We choose another way to fix the checksum. Since the overall difference is just 11, it's very easy to mod some other useless info to match the requirement. In Hex, 11 means 9+8, coincidentally, there is a 9 and a 8 in the ROM which is very obvious not belongs to any card's setting.
So, we pick this number, changed both the 9 and 8 to 0. (the relative bytes change from 39 and 38 to 30, overall difference is -11).
So, up to this stage, all the "preparation" is done. We can now save this edited ROM image to another new ROM file (NOT to overwrite the original one).
Of course, in general, no one will apply checksum fix in this way. However, this looks extremely safe, because we believe this 1998 is completely a "for info" item in that ROM image. It should be safer than pick a random FF to apply the correction. So we go ahead, and use ATIWinFlash to flash the edited ROM back to the card (This process can take a minute or two. The computer may stop responding, the progress bar may stop moving, do NOT touch anything! Just wait and let it do the job). End result? A big success.
Thanks Teddy for providing his card, ROM, and time for me to test the "fix". And if anyone want to try this "part number fix" on the new Sapphire PULSE RX580 8GB card, please AVOID the Polaris BIOS Editor.
If there is ANY error during / after flash, do NOT restart, but flash your MASTER BACKUP ORIGINAL ROM image back in. Then dump it out again to double check if it's the same as the MASTER BACKUP (You may simply check the modded bytes by yourself, or use some software to compare them automatically). I didn't use the ATIWinFlash for a while already. I am not 100% sure, but from memory, if the checksum is wrong, it should refuse to flash the ROM onto the card. So, as long as the software take it, the ROM should be OK.
If you only edit the part number, some useless info, or that large piece of FF. Even you did something wrong, the card should still work, but just still shows R9 XXX in High Sierra. If this happened, I suggest you also flash the MASTER BACKUP ROM image back to the card. Then start everything from the beginning again.
Of course, please feel free to post any questions (or share your work) at here. I prefer to discuss at here rather than PM. Therefore, everyone can benefit from the discussion.
*** This mod CANNOT make any RX580 shows boot screen ***
Forum member Teddy managed to get a Sapphire PULSE RX580 8GB card. But the part number is changed already, so, can't identify itself correctly in MacOS (technically speaking, we can't really see the part number in MacOS, but if it's "right", High Sierra should able to recognise this card. Therefore, the R9 XXX in "about this Mac" can be used as an indication that the part number is "wrong"). He showed me a post about how to "fix" it, and that guide suggest users to use the Polaris BIOS Editor to open an edited ROM, then save it again. To me, this looks like the process to fix the checksum. I never own this card, and never play around with the Polaris BIOS Editor. But Teddy showed me this warning message from the Polaris BIOS Editor.
Despite the PULSE ROM size is just 256k, it seems the Polaris BIOS Editor may still base on the 512k size assumption to apply the checksum fix. Which may eventually apply the fix on an important byte and causing error. More than one users reported that, the card "fixed" in this way will only shows back screen once driver is loaded (in Windows), or all the way black screen (in MacOS).
So, I worked with him to correctly fix the card. The following records what we did. I use macOS calculator and Hexminer (Mac apps) to assist him because I work with him via the internet, and I am in MacOS. In fact, the whole process can be done within Windows. No need to boot back to MacOS until everything is done. All you need is
1) ATIWinFlash.exe
2) Any Hex calculator
3) Any Hex Editor
I am quite sure the whole process can also be done in DOS or Linux, but I don't know how to do it. So, the following procedures are all base on Windows. You can do that in a PC, or Bootcamp Windows on the Mac Pro (and NO, this cannot be done within Parallel Windows, or any virtual machine).
He sent me the original dumped ROM (by using ATIWinFlash in Windows. GPU-Z can also be used to dump the ROM), I open it (with HexMiner, but any hex editor can do the job), and obviously the part number is not the one that same as the Apple developer kit. (N.B. Before you do anything to the ROM image, backup your original dumped ROM at least twice, and only edit the copy of copy, NEVER edit the original ROM image backup. We should ALWAYS keep a MASTER BACKUP.)
So, we apply the "part number fix", change it to 113-4E353BU-O4E (N.B. Make sure you UPDATE / REPLACE the required byte, NOT add / insert some new bytes) (113-4E3531U-O4V should also work, but we never test it)
The work is fairly easy, only 5 bytes need to be changed in this case.
However, after this "part number fix", the checksum of ROM may be wrong (and 99.99% of time, it is wrong). So, we need to fix that as well. Since we know the Polaris BIOS Editor will cause issue, we use a more complicated but safer way to manually fix it.
First, we need a hex calculator to workout the checksum difference. This is easy, macOS already included a calculator, and can be switch to hex mode. In this case, the 5 bytes changed as follow (all numbers are in Hexadecimal).
31 -> 34
38 -> 35
37 -> 33
30 -> 42
42 -> 45
If we put all the new numbers in the Hex calculator, 34+35+33+42+45 = 123
And then minus all the old numbers, 123 - 31 - 38 - 37 - 30 - 42 = 11
That means, we need to find a useless byte and make it 11 smaller than the original number. A very standard way to do that is to find the very large piece of FF, which located at the end of the ROM, and change one of them from FF to EE (FF - 11 = EE from the Hex calculator). An example is like this.
I am not familiar with the ROM, and simply avoid to change the very last few bytes, just in case it's used to define the end of the ROM. However, this is just an example. We did NOT correct the checksum in this "standard" way. And this ROM is never tested at the end. (update: leVel tested this method on his Nitro+, and doesn’t work. So please avoid this method until further update)
We choose another way to fix the checksum. Since the overall difference is just 11, it's very easy to mod some other useless info to match the requirement. In Hex, 11 means 9+8, coincidentally, there is a 9 and a 8 in the ROM which is very obvious not belongs to any card's setting.
So, we pick this number, changed both the 9 and 8 to 0. (the relative bytes change from 39 and 38 to 30, overall difference is -11).
So, up to this stage, all the "preparation" is done. We can now save this edited ROM image to another new ROM file (NOT to overwrite the original one).
Of course, in general, no one will apply checksum fix in this way. However, this looks extremely safe, because we believe this 1998 is completely a "for info" item in that ROM image. It should be safer than pick a random FF to apply the correction. So we go ahead, and use ATIWinFlash to flash the edited ROM back to the card (This process can take a minute or two. The computer may stop responding, the progress bar may stop moving, do NOT touch anything! Just wait and let it do the job). End result? A big success.
Thanks Teddy for providing his card, ROM, and time for me to test the "fix". And if anyone want to try this "part number fix" on the new Sapphire PULSE RX580 8GB card, please AVOID the Polaris BIOS Editor.
If there is ANY error during / after flash, do NOT restart, but flash your MASTER BACKUP ORIGINAL ROM image back in. Then dump it out again to double check if it's the same as the MASTER BACKUP (You may simply check the modded bytes by yourself, or use some software to compare them automatically). I didn't use the ATIWinFlash for a while already. I am not 100% sure, but from memory, if the checksum is wrong, it should refuse to flash the ROM onto the card. So, as long as the software take it, the ROM should be OK.
If you only edit the part number, some useless info, or that large piece of FF. Even you did something wrong, the card should still work, but just still shows R9 XXX in High Sierra. If this happened, I suggest you also flash the MASTER BACKUP ROM image back to the card. Then start everything from the beginning again.
Of course, please feel free to post any questions (or share your work) at here. I prefer to discuss at here rather than PM. Therefore, everyone can benefit from the discussion.
Last edited:
