• 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

joevt said:
I gave you binaries of the ndrv pef and extracted the kexts from the mkext. Why are you looking at hex still?
Disassemble them in a disassembler. MPW's DumpPEF does an ok job for the pef file but it's not perfect and might stop prematurely at weird trace back entries.
Click to expand...
I didn't see those there, but with MPW I normally need more hand holding than usual.

I thought you had linked DumpPEF somewhere?, that's going to be a really useful tool once I learn how to use it.

BTW is pef the formate that can serve as an 'ndrv' extension if placed in the Extensions folder?
 
obsolete said:
@Compgeke, if you're able to pull the ROM from your card, I'm curious whether it's any different, being used with a VT6421A instead of VT6421L. I can't find a datasheet for the VT6421L so I'm not aware if there are any relevant differences.
Click to expand...

Fink keeps bugging me, I keep forgetting to acquire hot air to actually do the job. I promise to get to it in the near future, I just need to grab a hot air station to actually get the chip off the board.
 
For some reason I can't get the machine to boot into OF, but I was able to pull some info with the PCI DDK (thanks @DarthNvader). Attached are the full device tree info dump (as Name Registry Output.txt) and just the Mathey card info (as Mathey.txt).

Poking around the ASCII in the driver,AAPL,MacOS,PowerPC section, I see some interesting stuff:
  • References to 3112 and 3149 devices. 1106:3149 is the Vendor:ID for the VIA VT6420 SATA controller, so that sort of makes sense. 1106:3112 comes up as the VT8361, VIA KLE133 Host Bridge, a northbridge chip for Socket A motherboards...that doesn't make any sense.
  • Later on, there's a specific mention of the SST49LF020 alongside the W49V002A and other supported ROM chips. That seems good.
@Compgeke, what's the chip at U6 on your card?
 

Attachments

obsolete said:
For some reason I can't get the machine to boot into OF, but I was able to pull some info with the PCI DDK (thanks @DarthNvader). Attached are the full device tree info dump (as Name Registry Output.txt) and just the Mathey card info (as Mathey.txt).

Poking around the ASCII in the driver,AAPL,MacOS,PowerPC section, I see some interesting stuff:
  • References to 3112 and 3149 devices. 1106:3149 is the Vendor:ID for the VIA VT6420 SATA controller, so that sort of makes sense. 1106:3112 comes up as the VT8361, VIA KLE133 Host Bridge, a northbridge chip for Socket A motherboards...that doesn't make any sense.
  • Later on, there's a specific mention of the SST49LF020 alongside the W49V002A and other supported ROM chips. That seems good.
@Compgeke, what's the chip at U6 on your card?
Click to expand...
You got the full 10429 Bytes of the 'ndrv' in the device tree, that's a good sign!

You did open Drive Setup or another disk tool to see if the drives connected were showing up there and not mounted, right?
 
obsolete said:
For some reason I can't get the machine to boot into OF
Click to expand...
the default output-device in OF is likely ttya as is the default input-device.

You'll need something like a Boot Variable program to set them to "screen" and "kbd", but I can't remember what that program is called right now.
 
DarthNvader said:
BTW is pef the formate that can serve as an 'ndrv' extension if placed in the Extensions folder?
Click to expand...
I'm not sure what is required to get an ndrv in a pef file loaded.
One way is to load it using the DriverLoaderLib from an INIT.

obsolete said:
Attached are the full device tree info dump (as Name Registry Output.txt) and just the Mathey card info (as Mathey.txt).
Click to expand...
The Mathey name registry output shows the ROM is only 64K.
Code: 
name = "mathey-eSATA-ATA-Combo-Mac"
vendor-id = [00001106 = 4358]
device-id = [00003249 = 12873]
AAPL,slot-name = "C1"
compatible = "XRackSATA16"
model = "MSATA-13UMAC"
device_type = "scsi"
Powered By = "Projovian.com"

reg
bus 0, dev 15, func 0, reg 48 (Mem) rel, 02007830 00000000 00010000

assigned-addresses
bus 0, dev 15, func 0, reg 48 (Mem) abs, 82007830 80810000 00010000

Therefore, the SIM ndrv could not get loaded.
 
joevt said:
I'm not sure what is required to get an ndrv in a pef file loaded.
One way is to load it using the DriverLoaderLib from an INIT.


The Mathey name registry output shows the ROM is only 64K.
Code: 
name = "mathey-eSATA-ATA-Combo-Mac"
vendor-id = [00001106 = 4358]
device-id = [00003249 = 12873]
AAPL,slot-name = "C1"
compatible = "XRackSATA16"
model = "MSATA-13UMAC"
device_type = "scsi"
Powered By = "Projovian.com"

reg
bus 0, dev 15, func 0, reg 48 (Mem) rel, 02007830 00000000 00010000

assigned-addresses
bus 0, dev 15, func 0, reg 48 (Mem) abs, 82007830 80810000 00010000

Therefore, the SIM ndrv could not get loaded.
Click to expand...
Good catch. 00020000 would be 128k, and his chip is 2Mbit?

All I can say is this shit again, same stupid game played with the internal logic of the Promise PDC20xxx flash memory.
 
DarthNvader said:
Good catch. 00020000 would be 128k, and his chip is 2Mbit?

All I can say is this shit again, same stupid game played with the internal logic of the Promise PDC20xxx flash memory.
Click to expand...
0x10000 is 64K and is 512 Kbit.
0x20000 is 128K and is 1 Mbit and is the size that is required for all the parts.
0x40000 is 256K and is 2 Mbit and is the size of the original ROM.

DarthNvader said:
So close....

Code: 
input: 88704 bytes
output: 67898 bytes (77%)

So we have to free up 2162 bytes, right @joevt?
Click to expand...
The mkext is compressed already so I would leave that uncompressed.
All the parts of the ROM could be compressed down to 63726 bytes but that would require modifying the LoadSIM routine of the NDRV which expects the SIM NDRV to be at offset 0x10000.

The card should at least be bootable for Mac OS X? If you have a Mac that supports booting Mac OS X.
 
joevt said:
0x10000 is 64K and is 512 Kbit.
0x20000 is 128K and is 1 Mbit and is the size that is required for all the parts.
0x40000 is 256K and is 2 Mbit and is the size of the original ROM.


The mkext is compressed already so I would leave that uncompressed.
All the parts of the ROM could be compressed down to 63726 bytes but that would require modifying the LoadSIM routine of the NDRV which expects the SIM NDRV to be at offset 0x10000.

The card should at least be bootable for Mac OS X? If you have a Mac that supports booting Mac OS X.
Click to expand...
Modifying the LoadSIM routine is relatively trivial, no? Just change the offset it is in the compressed rom?
 
The cheapest eBay card looks pretty good too, but the EEPROM chip is not on the front of the card, so we have no idea what it is, or what size it is.

The card has 1x IDE, 2xSATA, 1xESATA.

That would pretty much fit everyone's needs and should be bootable in any PPC OS, but we don't no what versions of OS X the mkext maybe compatible with.

If we can get this ROM down to 65,536 bytes, and the DOS flashing tool works with it, no more crazy prices and all HD bases are covered for PPC PCI/AGP Macs.s-l1600.jpg
 
Code: 
0836 0586          2E44756D...            dc.b      ".DumpFlash__9SerialATAFlPcl"

What does this instruction do?

Code: 
01A0  00000000 00000000 01000000 00000004  122E5072 6F6A6F76 69616E53 43534953

Is that the address in the EEPROM for the SIM? 0100 0000 0001 0000( endian flipped )?
 
Last edited:
DarthNvader said:
Modifying the LoadSIM routine is relatively trivial, no? Just change the offset it is in the compressed rom?
Click to expand...
That routine only works for uncompressed data in an unused part of the PCI Option Rom. We would probably store it as an uncompressed property in the name registry rather than as uncompressed data in an unused part of the PCI Option Rom.

DarthNvader said:
That would pretty much fit everyone's needs and should be bootable in any PPC OS, but we don't no what versions of OS X the mkext maybe compatible with.
Click to expand...
Just look at the Info.plist to determine what version of Mac OS X is required.
It says it requires com.apple.iokit.IOATAFamily 1.5.1d3.
which appears to be from Mac OS X 10.1.5 (source 151.3.1, version 1.5.1f1, OSBundleCompatibleVersion 1.0b1).

The 10.5.8 version (source 202.0.1, version 2.0.1) has OSBundleCompatibleVersion of 1.0b1 which is the version from Mac OS X 10.1 (source 1.4.8f3).

DarthNvader said:
Code: 
0836 0586          2E44756D...            dc.b      ".DumpFlash__9SerialATAFlPcl"

What does this instruction do?
Click to expand...
That is just data (define constant bytes) in the traceback table for the DumpFlash C++ method. Traceback tables are used for debugging. They help generate back traces, etc.

DumpFlash__9SerialATAFlPcl is a mangled C++ name.
Code: 
mpw unmangle ".DumpFlash__9SerialATAFlPcl"
SerialATA::.DumpFlash(long, char*, long)

DarthNvader said:
Code: 
01A0  00000000 00000000 01000000 00000004  122E5072 6F6A6F76 69616E53 43534953

Is that the address in the EEPROM for the SIM? 0100 0000 0001 0000( endian flipped )?
Click to expand...
No. PowerPC is big endian so it wouldn't need endian flipping. 01000000 endian flipped is 01. If you want to look at code, then you need a proper disassembler. Are there any good modern disassemblers for PPC PEF format? IDA, Ghidra, Binary Ninja, Hopper, ... ? I've attached output from Jasik's MacNosy which is a classic macOS disassembler for 68K and PPC.

Code: 
         mr       r3,r29                 ; Move Reg
         lis      r4,1                   ; Load Immed Shifted
         la       r5,vab_2(SP)           ; Load Address
         li       r6,4                   ; Load Immed
         bl       .SerialATA::DumpFlash(long, char *, long)
         nop                             ; No op
         mr       r3,r29                 ; Move Reg
         lis      r4,1                   ; Load Immed Shifted
         addi     r4,r4,4                ; Add Immed
         addis    r5,RTOC,0              ; Add Immed Shifted
         addi     r5,r5,-$74B8           ; Add Immed
         lwz      r6,vab_2(SP)           ; Load Word and Zero
         bl       .SerialATA::DumpFlash(long, char *, long)
This code in LoadSIM gets the first 4 bytes at offset 0x10000 which is the size of the SIM PEF. Then it loads that many bytes at offset 0x10004 which is the SIM PEF.

What purpose does the Fcode ndrv serve other than to load the SIM ndrv? Could the SIM ndrv replace the Fcode ndrv?
 

Attachments

Very interesting post, I have a hard time continuing because my English is not very good, but from what I understand, that ROM does not work on any card with that VIA chip, right?

I found this very cheap card that does have an EPROM chip, but it has 3 SATA and 1 ATA. I don't know if it would be valid for testing. The chip is also A, not L.

Thanks for your effort.

PCI ATA-SATA
 
joevt said:
That routine only works for uncompressed data in an unused part of the PCI Option Rom. We would probably store it as an uncompressed property in the name registry rather than as uncompressed data in an unused part of the PCI Option Rom.


Just look at the Info.plist to determine what version of Mac OS X is required.
It says it requires com.apple.iokit.IOATAFamily 1.5.1d3.
which appears to be from Mac OS X 10.1.5 (source 151.3.1, version 1.5.1f1, OSBundleCompatibleVersion 1.0b1).

The 10.5.8 version (source 202.0.1, version 2.0.1) has OSBundleCompatibleVersion of 1.0b1 which is the version from Mac OS X 10.1 (source 1.4.8f3).


That is just data (define constant bytes) in the traceback table for the DumpFlash C++ method. Traceback tables are used for debugging. They help generate back traces, etc.

DumpFlash__9SerialATAFlPcl is a mangled C++ name.
Code: 
mpw unmangle ".DumpFlash__9SerialATAFlPcl"
SerialATA::.DumpFlash(long, char*, long)


No. PowerPC is big endian so it wouldn't need endian flipping. 01000000 endian flipped is 01. If you want to look at code, then you need a proper disassembler. Are there any good modern disassemblers for PPC PEF format? IDA, Ghidra, Binary Ninja, Hopper, ... ? I've attached output from Jasik's MacNosy which is a classic macOS disassembler for 68K and PPC.

Code: 
         mr       r3,r29                 ; Move Reg
         lis      r4,1                   ; Load Immed Shifted
         la       r5,vab_2(SP)           ; Load Address
         li       r6,4                   ; Load Immed
         bl       .SerialATA::DumpFlash(long, char *, long)
         nop                             ; No op
         mr       r3,r29                 ; Move Reg
         lis      r4,1                   ; Load Immed Shifted
         addi     r4,r4,4                ; Add Immed
         addis    r5,RTOC,0              ; Add Immed Shifted
         addi     r5,r5,-$74B8           ; Add Immed
         lwz      r6,vab_2(SP)           ; Load Word and Zero
         bl       .SerialATA::DumpFlash(long, char *, long)
This code in LoadSIM gets the first 4 bytes at offset 0x10000 which is the size of the SIM PEF. Then it loads that many bytes at offset 0x10004 which is the SIM PEF.

What purpose does the Fcode ndrv serve other than to load the SIM ndrv? Could the SIM ndrv replace the Fcode ndrv?
Click to expand...
I ordered one of these cards and it took the slow boat from China, but I have it now.

So should we try and do away with the 'ndrv' and just load the SIM?
 
I admit, I got kind of overwhelmed by the barrage of posts on this and set it aside for a while, but I just dusted off my Digital Audio G4 today so I decided to give the flashed card a try there. Unfortunately, it doesn't seem to work in OS X either. In 10.0, it shows up in System Profiler the same as it did on the 5400 in 8.6, but there is no SCSI bus associated with it and no connected devices are visible to the system. In 10.3.8, it doesn't show up in System Profiler at all. Here's the .properties from Open Firmware:
IMG_20250308_201215.jpg
DarthNvader said:
All I can say is this shit again, same stupid game played with the internal logic of the Promise PDC20xxx flash memory.
Click to expand...
Are you saying there's some reason the VT6421 is only making 64K of the 256K ROM visible to the system? If that's the case, how does the Mac version of the card work?

The reason I keep asking about U6 is that it looks like it could be a SPI flash ROM. The VT6421 has both interfaces; it can use either SPI flash or a parallel FLASH like the SST49LF020A and W49V002AP via its LPC (low pin count) interface. Would be weird to use both, but I'd like to rule it out just in case...
 
obsolete said:
I admit, I got kind of overwhelmed by the barrage of posts on this and set it aside for a while, but I just dusted off my Digital Audio G4 today so I decided to give the flashed card a try there. Unfortunately, it doesn't seem to work in OS X either. In 10.0, it shows up in System Profiler the same as it did on the 5400 in 8.6, but there is no SCSI bus associated with it and no connected devices are visible to the system. In 10.3.8, it doesn't show up in System Profiler at all. Here's the .properties from Open Firmware:
View attachment 84254

Are you saying there's some reason the VT6421 is only making 64K of the 256K ROM visible to the system? If that's the case, how does the Mac version of the card work?

The reason I keep asking about U6 is that it looks like it could be a SPI flash ROM. The VT6421 has both interfaces; it can use either SPI flash or a parallel FLASH like the SST49LF020A and W49V002AP via its LPC (low pin count) interface. Would be weird to use both, but I'd like to rule it out just in case...
Click to expand...

Your card has a 64K ROM so it's probably missing the SIM that the ndrv tries to load.
The Mac version of the card probably has a bigger ROM chip.

Still, I think it should work in Mac OS X since Mac OS X doesn't use SIM?

Did the kext get loaded? run kextstat | grep XRack

Maybe you can try loading the kext manually (I haven't tested this pre Tiger though)
https://gist.github.com/joevt/a4ef4cd2e1485d0dd595893007bdfd6a

I think I included the kext at #34
 
You must log in or register to reply here.

Similar threads

finkmac
Mathey MSATA-02MAC SATA Card
Replies
4
Views
356
obsolete
obsolete
Back
Top