Mathey MSATA-13UMAC IDE/SATA card

[finkmac]

Got this card a few months back.

Mathey MSATA-13UMAC. Combo IDE/SATA PCI card based on a common VIA ref design.

specs here:



firmware seems to originally made for this card by Projovian

that page claims 8.1 compatibility, which should mean sys7 compatibility

note, i was too lazy to actually verify booting. it did show up in the system profiler / tattletech though.

firmware ROM is a W49V002AP PLCC32

in theory you could flash a regular VIA VT6421L card with this firmware and it would just work.

wanna try? you know you want to...

 

[macuserman]

Whoah you found one! How the hey people have been on the hunt for this forever!

 

[macuserman]

This might be a game changer, get us out from under the thumb of the pompous $%@! that is sataman/firmtek. This opens up lots of possibilities.

 

[eastone]

@finkmac
Wow, you've done the impossible!!!! I have two cards based on this chip, one combo with USB. I've ordered new eeptoms and will see if that works. Thanks a lot for this find.

 

[ArmorAlley]

Does this card require drivers to be installed?

 

[joevt]

The 256K ROM has one PCI option ROM. The image is for Open Firmware (no BIOS image). The fcode includes an ndrv for classic Mac OS and a mkext for Mac OS X.

The fcode is interesting because most of the words are named. I think the ROM was still in development? A release version would probably remove all the names. There's also some test code for a specific device path which is valid only for specific Macs:
/pci@f2000000/pci-bridge/xsense-sata/disk
But the device name is "mathey-eSATA-ATA-Combo-Mac", not "xsense-sata", so that test code is meant for some other PCI card?

 

[Compgeke]

As it turns out, I have one of these too! I bought a card at a flea market to try and flash with this firmware, and as it turns out, it's already a Mac card.

Mine's showing up as an XRack SUA100. It's also got a VIA VT6421A instead of an L like the Mathey has. I can confirm it will boot under Classic Mac OS no problem. I'll try and get the ROM dumped as soon as I can get my hands on some hot air.

 

[supernova777]

nice one boys
yea this one supports IDE + SATA x 2 i think
anyone test the firmware on any other VIA cards?

VIA VT6421A chipset is actually a HW RAID controller chipset...
maybe theres a way to have a SATA 2 device raid aswell as a PATA 2 device raid with this card....
i dunno if it ever supported RAID tho probably not but it might have

If someone can figure out how to clone the firmware to a generic card this could make alot of macs boot again

 

[obsolete]

No one else has tried this yet?

Here is a SYBA SD-VIA-1A2S, the second cheapest VT6421-based PCI card on eBay. The cheapest is an unbranded green board that won't show up until Monday, so this one went under the knife first.


Under the SATA RAID sticker lies an SST49LF020A, same size as the W49V002AP on @finkmac's card, so we should be in business, right?


Chip removed, dumped, it contained V4.95 of the same BIOS that's already available here, so no need to preserve it. Erased and programmed with the MSATA-13UMAC ROM from @finkmac and popped back onto the board with a socket.


I tried the card in my 5400. It shows up!


Unfortunately, that's all it does. I tried a PATA HDD, a CF adapter, a SATA HDD, and a SATA DOM, and none of them showed up. Shouldn't there be a SCSI Bus 1 up there for the card? SCSI Bus 0 is the built-in controller on the 5400.

Here are some TattleTech screenshots just for fun:



Tattletech shows a SCSI Bus 1, but nothing about it under the SCSI section, regardless of what I have hooked up to the card. Does anyone have any ideas? @joevt, is there any poking around in OF that would be worth doing? @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.

 

[obsolete]

@Compgeke, I think yours might be a Macsense SUA-100E: http://www.macsense.com/product/storage/sua-100e.html

I'm also curious about the 8-pin SOIC at U6 on these cards. I can see it's an Atmel somethingorother, but can't make out what.

 

[DarthNvader]

No one else has tried this yet?

Here is a SYBA SD-VIA-1A2S, the second cheapest VT6421-based PCI card on eBay. The cheapest is an unbranded green board that won't show up until Monday, so this one went under the knife first.
View attachment 83173

Under the SATA RAID sticker lies an SST49LF020A, same size as the W49V002AP on @finkmac's card, so we should be in business, right?
View attachment 83174

Chip removed, dumped, it contained V4.95 of the same BIOS that's already available here, so no need to preserve it. Erased and programmed with the MSATA-13UMAC ROM from @finkmac and popped back onto the board with a socket.
View attachment 83175

I tried the card in my 5400. It shows up!
View attachment 83176

Unfortunately, that's all it does. I tried a PATA HDD, a CF adapter, a SATA HDD, and a SATA DOM, and none of them showed up. Shouldn't there be a SCSI Bus 1 up there for the card? SCSI Bus 0 is the built-in controller on the 5400.

Here are some TattleTech screenshots just for fun:
View attachment 83178
View attachment 83177

Tattletech shows a SCSI Bus 1, but nothing about it under the SCSI section, regardless of what I have hooked up to the card. Does anyone have any ideas? @joevt, is there any poking around in OF that would be worth doing? @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.

I'm thinking the 'ndrv' didn't load, can you jump into Open Firmware and display the .properties for the card?

Or use the Display Name Registry tool from Apple's PCI DDK to look at the properties of the card in the Mac OS?

PCI_DDK_3.0.sit.hqx

I'm not totally familiar with the 5400's PCI Bus, but something like.

dev pci ls
dev pci/@c( whatever @ the card shows in the ls )
.properties

 

[joevt]

The properties should show if the ROM chip is large enough for the Mac ROM.

 

[DarthNvader]

I'm thinking the 'ndrv' didn't load, can you jump into Open Firmware and display the .properties for the card?

Or use the Display Name Registry tool from Apple's PCI DDK to look at the properties of the card in the Mac OS?

PCI_DDK_3.0.sit.hqx

I'm not totally familiar with the 5400's PCI Bus, but something like.

dev pci ls
dev pci/@c( whatever @ the card shows in the ls )
.properties

What you are looking for is the driver,AAPL,MacOS,PowerPC property, it's a big long hex string.

If it's not there something went wrong with loading the 'ndrv' in the device-tree. An 'ndrv' is a native device driver for the classic Mac OS( not Classic mode in OS X ). The property is not used by Open Firmware, but it get's build there for devices that are used in boot up of the Mac OS. If it doesn't need to be used in booting then the 'ndrv' can be a disk based driver in the Extensions folder, still an 'ndrv'.

 

[joevt]

I looked at the ROM. It's weird. The Fcode is < 64K. It encodes a ndrv (driver,AAPL,MacOS,PowerPC) and an mkext (driver,AAPL,MacOSX,PowerPC) the normal way. The weird part is an ndrv at the 64K mark. The ROM is 256K but only requires 128K for the fcode and ndrv.

I'll compare the two ndrv.

 

[joevt]

The second ndrv is a SIM (SCSI Interface Module) that is loaded by the ndrv in the Fcode.

 

[DarthNvader]

The second ndrv is a SIM (SCSI Interface Module) that is loaded by the ndrv in the Fcode.

Didn't some company that made FCode ROMs for SATA card put a check for a specific EEPROM ID and the code would goto abort if it found the wrong ID?

Not sure that's what's going on here, we'll have to see if the 'ndrv' is loaded in the device tree, but I doubt it is, as it will show the drives if it does.

Joe, maybe run the code in Dingus and see id it goes to abort before the 'ndrv' is loaded into the device-tree?

 

[DarthNvader]

Right here it's trying to read the EEROM ID:

FFBC 0001

encode+
" "(7C08 02A6 9001 0008 9421 FF90 9061 0088 3861 0058 4800 09F5 8041 0014 3861 0048 3881 0058 4BFF FF6D 3800 0000 9001 0040 8001 0088 9001 0044 3861 0060 8081 0040 80A1 0044 80C1 0048 80E1 004C 4800 09ED 8041 0014 3861 0050 3881 0060 4BFF FF35 4800 001C 3861 0068 4800 09A1 8041 0014 3861 0048 3881 0068 4BFF FF19 8061 0048 8001 0050 7C03 0040 4180 FFDC 8061 0048 8001 0050 7C03 0040 4082 0014 8061 004C 8001 0054 7C03 0040 4180 FFBC 8001 0078 3821 0070 7C08 03A6 4E80 0020 0000 0000 0009 2041 8000 0000 0000 00BC 0015 2E57 6169 744E 616E 6F73 6563 6F6E 6473 5F5F 4655 6C00 0000 0000 0000 0000 0000 0000 93E1 FFFC 7C7F 1B78 3800 0000)" \ "|..¶ê...î!.êêa.à8a.XH..ıÄA..8a.H8Å.XK..m8...ê..@Ä..àê..D8a.`ÄÅ.@Ä°.DÄ¡.HÄ·.LH..ÌÄA..8a.P8Å.`K..5H...8a.hH..°ÄA..8a.H8Å.hK...Äa.HÄ..P|..@AÄ.‹Äa.HÄ..P|..@@Ç..Äa.LÄ..T|..@AÄ.ºÄ..x8!.p|..¶NÄ. ...... AÄ......º...WaitNanoseconds__FUl.............ì·.¸|..x8..."
encode-bytes
encode+

Likely that will need to be changed or bypassed for an EEPROM other than the

W49V002FA

If you look at the data sheet under "Product Identification" it clearly states FFBC 0001 is how to return the Product ID.

 

[DarthNvader]

Right here it's trying to read the EEROM ID:

FFBC 0001



Likely that will need to be changed or bypassed for an EEPROM other than the

W49V002FA

If you look at the data sheet under "Product Identification" it clearly states FFBC 0001 is how to return the Product ID.

Bad eyes again, that code was FFBC 8001 not 0001.

Would that make a difference?

 

[DarthNvader]

If it is an abort, the ID check is only in the 'ndrv' not the OS X driver, and they are not used by OF.

I'm not real sure, could be encoded different in the OS X driver and I just don't see it.

If the properties are there in OF, and not in the Mac OS or Mac OS X, then they are going to abort so the drivers never get loaded by the OS.

I ran into something similar toying with Rage128 emulation in Qemu. The Rage 128 'ndrv' has a specific check for an interrupt, if it doesn't find it in the device tree the code aborts. It's not copy protection in that case, it's just in need of that interrupt.

 

[joevt]

Bad eyes again, that code was FFBC 8001 not 0001.

Would that make a difference?

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.