No, I wish it was that simple. W49V002AP (on the Mac card) and SST49LF020A (on my card) are both 256K byte parts.
I will try that and report back. I can upgrade the machine to Tiger if necessary, probably should anyway.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Mathey MSATA-13UMAC IDE/SATA card
- Thread starter finkmac
- Start date
The fcode overrides the vendor/device-id to 1106:3249. If you force the fcode to not get loaded (such as by nvramrc patch or by connecting the card to a PC or to a Intel Mac), does the vendor/device-id change? Or use lspci for Open Firmware to read the vendor/device id directly from the PCI card (as well as the BAR sizes).
For device 1106:3249, the fcode actually sets the
For devices with vendor 1095, the fcode sets the
A registered kext will unload if it doesn't match something within a certain time period. What you need to do is test the kext manually using the command line and verbose mode. Check dependencies, etc.
Something like
The kext matches the
For device 1106:3249, the fcode actually sets the
reg property to show only 64K for the expansion ROM BAR - overriding the default.For devices with vendor 1095, the fcode sets the
reg property to show 512K for the expansion ROM BAR.A registered kext will unload if it doesn't match something within a certain time period. What you need to do is test the kext manually using the command line and verbose mode. Check dependencies, etc.
Something like
kextload -v 6 pathtokext.kextThe kext matches the
XRackSATA16 name which is stored in the compatible property. The kext's probe method might do some testing to see if it should match the PCI card. Maybe look in the logs (it doesn't appear that the kext does much logging so there's probably no message there).
How about just booting into Open Firmware with no EEPROM installed in the card?
Thanks, that explains what we've been seeing here (but not why, since it appears to actually prevent the card from working properly).
That's weird. PCI vendor code 1095 belongs to Silicon Image
Thanks. I have 10.4 on the machine now and will play around with this.
Here's the output from loading the kext after fixing its permissions with your utility (thanks for that!) It loads successfully, then after a while, unloads. With the last line of output from kextload being "matching started", I'm assuming this means it never finds a match? As was the case in 10.3, nothing at all shows up in Apple System Profiler for the card in the PCI Cards section. Yes, I did reinstall the EEPROM in its socket 
Booting without EEPROM should show the unmodified vendor/device id and reg values. Your screen shot shows that it still indicates a 64K ROM.
The fcode is required to set the name that is matched by the kext. Otherwise, you need to change the kext to match on PCI vendor/device id instead of name. I suppose you can have one kext personality match on name and the another to match on vendor/device-id. The latter might not work if the kext requires some setup done by the fcode.
Check the ioreg to make sure the fcode has set the name.
1106:3249 is a VIA Technologies, Inc. VT6421/VT6421A IDE/SATA Controller. The Datasheet says the expansion rom is 64K or 32K or 16K. It also says "Supports external FLASH or EEPROM for BIOS expansion and RAID functions" which appear to be two different things. Perhaps a different method of accessing the > 64K of the ROM data is used to load the SIM in classic Mac OS (i.e. it doesn't use the PCI expansion ROM method to read the SIM).
https://theretroweb.com/chip/documentation/vt6421a-641dc8837d76e713508862.pdf
There's separate registers for BROM and EEPROM in the PCI config space of the card. You can use lspci in Open Firmware or OS X to read all the registers. It would be interesting to compare these between the Mac card and your card.
https://gist.github.com/joevt/e3cd4ff08aae06279134969c98ca3ab7
The fcode is required to set the name that is matched by the kext. Otherwise, you need to change the kext to match on PCI vendor/device id instead of name. I suppose you can have one kext personality match on name and the another to match on vendor/device-id. The latter might not work if the kext requires some setup done by the fcode.
Check the ioreg to make sure the fcode has set the name.
ioreg -fliw0 | grep XRackSATA161106:3249 is a VIA Technologies, Inc. VT6421/VT6421A IDE/SATA Controller. The Datasheet says the expansion rom is 64K or 32K or 16K. It also says "Supports external FLASH or EEPROM for BIOS expansion and RAID functions" which appear to be two different things. Perhaps a different method of accessing the > 64K of the ROM data is used to load the SIM in classic Mac OS (i.e. it doesn't use the PCI expansion ROM method to read the SIM).
https://theretroweb.com/chip/documentation/vt6421a-641dc8837d76e713508862.pdf
There's separate registers for BROM and EEPROM in the PCI config space of the card. You can use lspci in Open Firmware or OS X to read all the registers. It would be interesting to compare these between the Mac card and your card.
https://gist.github.com/joevt/e3cd4ff08aae06279134969c98ca3ab7
I hit a wall on this and set it aside for a while. I flashed a 93C46 with the data from finkmac and wired it up according to the VT6421 datasheet. I tried it in both 16-bit and 8-bit mode (ORG pin pulled up and down) and nothing changed about how the card shows up and works in the system vs. before I added the serial EEPROM.
I can't think of anything else to try without having one of the real Mac cards in hand.
I can't think of anything else to try without having one of the real Mac cards in hand.
Last edited:
I was able to make some progress on this thanks to @opualuan generously loaning me his XRack card. I dumped the ROM and attached it to this post. It's only superficially different from the Mathey ROM; just the names are changed, everything else is the same. The contents of the AT93C46 are identical.
My problem was the ROM device ID check all along. The Fcode has a whitelist of 5 flash ROM parts:
Only the first two make sense. The remaining 3 lack LPC support, which the VIA 6421 requires. Not sure what they're doing there, maybe left over from something else. My PC card came with a SST49LF020A which is not the same as the plain SST49LF020. It has a device code of 0x52, so it will not match the 0x61 the firmware is expecting. When I install the Winbond chip from the XRack card on my modified PC card pictured above, with no other changes, it works great, just like the original XRack card, bootable in OS 9 and X, etc.
As an aside, the AT93C46 is operating in 16-bit mode, but instead of pulling the ORG pin up to VCC as specified in the datasheet, the XRack card leaves it floating. The datasheet says that ORG has an internal 1Mohm pull-up, so the part should default to 16-bit mode, but also that if you want to leave that pin floating, you should use the AT93C46A, which is a 16-bit only part, so you don't need to worry about the ORG pin. I am pulling ORG up to VCC on my PC card and it works well. I wouldn't trust such a weak pull-up, but apparently whoever designed this card did, and it seems to work fine too.
So, the device code check...that should be pretty easy to hack, right? Here's how it's encoded in the firmware:
The manufacturer code and device code are in there twice, the second time is endian-swapped, no idea why, but all the ROM entries are like that. So, a simple change to BF 52 52 BF should do it, but that'll screw up the checksum, right? To take care of that, I used the old trick of adding some bits elsewhere equal to what I subtracted. In this case, 0x61 - 0x52 = 0xF, so I needed to add 0xF in two places. I chose the spaces before and after Storage, which turns them into ASCII slashes:
I was feeling quite clever, but this did not work. Thanks to the detokenized Forth that joevt posted earlier, I was able to figure out where the checksum is stored and how to calculate it, so I made another version of the ROM where instead of adding 0xFs, I corrected the checksum. That didn't work either. With either modified ROM loaded onto the SST49LF020A, connected devices will show up in the boot menu when holding down the Option key, but I cannot boot from them, and they do not show up when booted into 10.4 on another device (and neither does the card).
If I load my modified ROM onto the W49V002AP and install that onto either card, it works fine, so I don't think I screwed anything up. Something is still weird with the SST49LF020A vs. SST49LF020. The only difference I can find in the A version is some ID pins that are used as straps, so that up to 16 of the devices to share the same bus. I'll look at what, if anything, either card is doing with those pins. In the meantime, I have some W49V002APs on the way.
My problem was the ROM device ID check all along. The Fcode has a whitelist of 5 flash ROM parts:
| Brand | Model | Mfg. Code | Dev. Code | Notes |
| Winbond | W49V002A | 0xDA | 0xB0 | Same as W49V002AP, found on Mathey and XRack cards |
| SST | SST49LF020 | 0xBF | 0x61 | Should work |
| AMD | AM29LV040 | 0x01 | 0x4F | No LPC support |
| SST | SST39SF010A | 0xBF | 0xB5 | 5V part, also no LPC |
| Atmel | AT49BV512 | 0x1F | 0x03 | Too small (only 64KB) and no LPC |
Only the first two make sense. The remaining 3 lack LPC support, which the VIA 6421 requires. Not sure what they're doing there, maybe left over from something else. My PC card came with a SST49LF020A which is not the same as the plain SST49LF020. It has a device code of 0x52, so it will not match the 0x61 the firmware is expecting. When I install the Winbond chip from the XRack card on my modified PC card pictured above, with no other changes, it works great, just like the original XRack card, bootable in OS 9 and X, etc.
As an aside, the AT93C46 is operating in 16-bit mode, but instead of pulling the ORG pin up to VCC as specified in the datasheet, the XRack card leaves it floating. The datasheet says that ORG has an internal 1Mohm pull-up, so the part should default to 16-bit mode, but also that if you want to leave that pin floating, you should use the AT93C46A, which is a 16-bit only part, so you don't need to worry about the ORG pin. I am pulling ORG up to VCC on my PC card and it works well. I wouldn't trust such a weak pull-up, but apparently whoever designed this card did, and it seems to work fine too.
So, the device code check...that should be pretty easy to hack, right? Here's how it's encoded in the firmware:
The manufacturer code and device code are in there twice, the second time is endian-swapped, no idea why, but all the ROM entries are like that. So, a simple change to BF 52 52 BF should do it, but that'll screw up the checksum, right? To take care of that, I used the old trick of adding some bits elsewhere equal to what I subtracted. In this case, 0x61 - 0x52 = 0xF, so I needed to add 0xF in two places. I chose the spaces before and after Storage, which turns them into ASCII slashes:
I was feeling quite clever, but this did not work. Thanks to the detokenized Forth that joevt posted earlier, I was able to figure out where the checksum is stored and how to calculate it, so I made another version of the ROM where instead of adding 0xFs, I corrected the checksum. That didn't work either. With either modified ROM loaded onto the SST49LF020A, connected devices will show up in the boot menu when holding down the Option key, but I cannot boot from them, and they do not show up when booted into 10.4 on another device (and neither does the card).
If I load my modified ROM onto the W49V002AP and install that onto either card, it works fine, so I don't think I screwed anything up. Something is still weird with the SST49LF020A vs. SST49LF020. The only difference I can find in the A version is some ID pins that are used as straps, so that up to 16 of the devices to share the same bus. I'll look at what, if anything, either card is doing with those pins. In the meantime, I have some W49V002APs on the way.
Thanks. Yeah, since there are so few boards out there with the SOIC-8 footprint, this may never be an easy PC-to-Mac conversion accessible to anyone not comfortable soldering under a microscope. It does open up the possibilities for new custom PCI cards though, perhaps multifunction ones. I'm partway through a schematic in KiCAD, we'll see where that goes.
Thanks for getting this whole thing started; I know people have been curious about these cards for a while.
Thanks for getting this whole thing started; I know people have been curious about these cards for a while.
The XRack_W49V002AP ROM is identical to the Mathey-MSATA-U13MAC-W49V002AP ROM except for the
model and name which causes the fcode checksum to differ as well. The name changes causes the length of the fcode to change by two bytes.Both ROMs have the exact same SIM pef at offset 0x10004.
The
BF 52 52 BF that you found is in the driver,AAPL,MacOS,PowerPC for classic Mac OS. It is a PEF, so you should extract the PEF, make the changes to that, and verify that mpw DumpPEF accepts the change.The ROMs include a
driver,AAPL,MacOSX,PowerPC for Mac OS X. It is a mkext, which means it is compressed so you can't just search it for things to change. You should extract the mkext and then extract the kexts from the mkext then examine the code for the kexts and the Info.plist files.
Thanks @joevt, I always appreciate your insights. I need to sit down sometime and learn about PEFs, NDRVs, MKEXTs, and the lot, but I'm typically in too much of a hurry and too quick to bust out the hex editor or the soldering iron when there are more elegant methods available (and sometimes required) to accomplish my goals, as you have shown. For what it's worth, I was trying to boot OS 9 off a SATA HDD with the modified ROM.
Speaking of me being impatient, I scrounged around and found a proper SST49LF020 on an old socket 478 motherboard last night. I dumped the PC BIOS off it, flashed the unmodified XRack ROM, and it works well on both cards as one would expect. I tried flashing the PC BIOS onto the SST49LF020A to see if I could just swap the two chips, but the PC motherboard won't accept it either!
I found the attached document from SST highlighting the differences between the two chips. For now, I would recommend anyone wanting to attempt this to just source some W49V002APs, since they're still available from places like UTSource, Quest, and AliExpress, and not expensive.
Speaking of me being impatient, I scrounged around and found a proper SST49LF020 on an old socket 478 motherboard last night. I dumped the PC BIOS off it, flashed the unmodified XRack ROM, and it works well on both cards as one would expect. I tried flashing the PC BIOS onto the SST49LF020A to see if I could just swap the two chips, but the PC motherboard won't accept it either!
I found the attached document from SST highlighting the differences between the two chips. For now, I would recommend anyone wanting to attempt this to just source some W49V002APs, since they're still available from places like UTSource, Quest, and AliExpress, and not expensive.
This card was listed on JDirectItems and Mercari for a while, but I couldn't justify the price:
...until I found some other stuff I wanted and ended up talking myself into a FromJapan order, so here we are. This is the System TALKS SUGOI SATA-IF150CM. Tested in my Quicksilver, works fine as you'd expect. Here it is next to opualan's XRack card before I packed that one up for return shipping:
Electrically, they appear to be exactly the same card right down to the reference designators on every component. The board outline is slightly different, though.
This silkscreen on the back of the card is what really sold me:
I smile when I see it. I feel VALUED UP!!
ROM dumps attached. Same Projovian ROM with superficial rebranding changes. Weirdly, System TALKS decided to change the data in the AT93C46 a little bit, so the subsystem-id shows up as 0x88da instead of 0xaa01 like the other cards. Not sure why, but it doesn't seem to affect anything.
...until I found some other stuff I wanted and ended up talking myself into a FromJapan order, so here we are. This is the System TALKS SUGOI SATA-IF150CM. Tested in my Quicksilver, works fine as you'd expect. Here it is next to opualan's XRack card before I packed that one up for return shipping:
Electrically, they appear to be exactly the same card right down to the reference designators on every component. The board outline is slightly different, though.
This silkscreen on the back of the card is what really sold me:
I smile when I see it. I feel VALUED UP!!
ROM dumps attached. Same Projovian ROM with superficial rebranding changes. Weirdly, System TALKS decided to change the data in the AT93C46 a little bit, so the subsystem-id shows up as 0x88da instead of 0xaa01 like the other cards. Not sure why, but it doesn't seem to affect anything.
The TALKs ROM seems to have differences between itself and the Mathey card that don't exist in the XRack card.
Specifically, the ndrv, SIM, and kext have differences which are not related to the change in sub system-id
The TALKs ndrv is from 2005 rather than 2006. The only difference may be some error strings?
The TALKs SIM is 18 minutes newer. It has more code differences. Specifically this additional code:
Code:
TALKs:
4800006C b $+0x006C
X 38600000 li r3,0
A01E18D4 lhz r0,0x18D4(r30)
X 2800CC97 cmplwi r0,0xCC97
X 40820014 bne $+0x0014
A01E18D6 lhz r0,0x18D6(r30)
X 280088DA cmplwi r0,0x88DA
X 40820008 bne $+0x0008
X 38600001 li r3,1
7C600774 extsb r0,r3
Code:
Mathey:
48000050 b $+0x0050
X 38000001 li r0,1
7C000774 extsb r0,r0... which you can find by removing parts of the disassembly produced by DumpPEF.
Code:
Remove these parts marked with vvvvvvvvv
vvvvvvvvv vvvvvvvvvvvv
19E8 1598 4800006C b $+0x006C ; 0x00001604To compare the kexts, you need a PowerPC version of
otool?
