Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Guide to flashing PC SIL3112 SATA cards for Mac

DearthnVader said:
SeriTek/1S2 5.1.3

Inside the package you can find the /Volumes/1S2_513/SeriTek1S2Flasher.app/Contents/Resources/ROMFILE.1S2

If we can use your tools to extract the 'NDRV' from the file and make it a hex data fork?
Click to expand...
The rom chip is huge (256K?) so they didn't need to use any compression tricks like in the FirmTek UltraTek133 example.
I've attached the results of the extraction.
There's a couple kexts and an ndrv.

DearthnVader said:
Didn't you do this for SixtySix? Only you extracted the 'NDRV' form the 4MB BootROM of the 8600 and placed it into the AppleNDRV folder in OS X to make video out work on the 8600?

I forget where a read it, likely in the PDF you linked, but classic MacOS 'NDRV's only needs a data fork( you know that start with Joy!peffpwpc ) Same format used in the OS X AppleNDRV folder for video cards.

Presumably one need only drop one of the 'NDRV' files from that folder into the OS 9 Extension folder and it work just work, tho I've never really been able to get that to work, I just hacked the ATI Driver Update Extension to include an 'NDRV' of my choosing for OS X for ATI cards. Or I placed the 'NDRV' into the New World Mac OS ROM's that include a generic display 'NDRV'.
Click to expand...
It's been almost a couple decades since I worked on Sixty6 for OS X. I think it was a disassembly from ndrv resource from the System file. Then I applied patches to make it compatible with OS X. One version is compiled by MPW and another by CodeWarrior (I don't remember why I tried both). Then the ndrv is copied to my OS X install "Misc1:System:Library:Extensions:AppleNDRV:sixty6.ndrv" (this was in an MPW script so folder delimiter is ":" instead of "/".

The file contains a resource fork with just a cfrg resource:
Code: 
derez /Volumes/Work/Programming/CWProjects/sixty6/sixty6\ from\ 9.1/mysixty6/sixty6.ndrv
data 'cfrg' (0, "Generated cfrg") {
	$"0000 0000 0000 0000 0000 0001 0000 0000"            /* ................ */
	$"0000 0000 0000 0000 0000 0000 0000 0001"            /* ................ */
	$"7077 7063 0000 0000 0000 0000 0000 0000"            /* pwpc............ */
	$"0000 0000 0000 0001 0000 0000 0000 0000"            /* ................ */
	$"0000 0000 0000 0000 0038 0B73 6978 7479"            /* .........8.sixty */
	$"362E 6E64 7276 0000"                                /* 6.ndrv.. */
};

derez /Volumes/Work/Programming/CWProjects/sixty6/sixty6\ from\ 9.1/mysixty6/sixty6.ndrv /Volumes/Devs/MPWStuff/Interfaces\&Libraries/Interfaces/RIncludes/CodeFragmentTypes.r
resource 'cfrg' (0, "Generated cfrg") {
	{	/* array memberArray: 1 elements */
		/* [1] */
		kPowerPCCFragArch,
		kIsCompleteCFrag,
		kNoVersionNum,
		kNoVersionNum,
		kDefaultStackSize,
		kNoAppSubFolder,
		kImportLibraryCFrag,
		kDataForkCFragLocator,
		kZeroOffset,
		kSegIDZero,
		"sixty6.ndrv"
	}
};

There's more AppleNDRV examples at https://github.com/elliotnunn/x-ndrv . But I don't know about OS 9 ndrv compatibility / requirements.

Anyway, I added a cfrg resource to the ndrv just in case it helps but I don't know if it will.
 

Attachments

  • SeriTek1S2_513_extracted.zip
    724.9 KB · Views: 134
  • Like
Reactions: Petri Krohn and Amethyst1
joevt said:
Anyway, I added a cfrg resource to the ndrv just in case it helps but I don't know if it will.
Click to expand...
Any time you deal with resource forks you should always use a stuffit achieve or something that preserves the resource fork.

Anywho, thanks @joevt, that sure made things a lot easier.

I made up a quick and dirty Mac OS extension and zeroed the driver,AAPL,MacOS,PowerPC property from Open Firmware's device tree on my card, then booted the Mac OS (9) and the driver did work, discs mounted under OS 9.

However that was with the SeriTek firmware, I'll flash the Webitech firmware to the card and see if the 'NDRV' is still compatible.
 
DearthnVader said:
However that was with the SeriTek firmware, I'll flash the Webitech firmware to the card and see if the 'NDRV' is still compatible.
Click to expand...
Sadly, and not shockingly, that didn't work. I think my disk based 'NDRV' tried to load and then went to abort when it found one or some of the cards .properties wasn't what was expected.

The easiest thing to do would be to reduce the Seritek firmware and try to remove the EEPROM ID check, but I don't know if anyone else is interested in this so I don't want to invest much more time in it if other people are not going to use it or find it useful?

What we did so far was kind of fun, it was interesting to figure some of this stuff out, tho @joevt did most of the heavy lifting for us.
 
DearthnVader said:
tho @joevt did most of the heavy lifting for us.
Click to expand...
Joe already included a reduced ROM for us, but it doesn't have the OS X driver either.

I got to run off to work for a while, when I get back I'll try and flash the reduced ROM to the card and see if my disk based driver is still going to abort.........
 
DearthnVader said:
Sadly, and not shockingly, that didn't work. I think my disk based 'NDRV' tried to load and then went to abort when it found one or some of the cards .properties wasn't what was expected.

The easiest thing to do would be to reduce the Seritek firmware and try to remove the EEPROM ID check, but I don't know if anyone else is interested in this so I don't want to invest much more time in it if other people are not going to use it or find it useful?

What we did so far was kind of fun, it was interesting to figure some of this stuff out, tho @joevt did most of the heavy lifting for us.
Click to expand...
I would. I have a Sil3512 card in my MDD. It only boots OSX and my OS9 volume on an ATA port doesn't see the SATA card or any disks on it. That setup might be enough for most people as few are inclined to get a soldering iron to get SATA support for System 7.6-OS9.
 
  • Like
Reactions: mustagcoupe and Amethyst1
DearthnVader said:
Any time you deal with resource forks you should always use a stuffit achieve or something that preserves the resource fork.
Click to expand...
The macOS Archive zip utility does preserve resource forks. Maybe you need to use a newer version of macOS. I used Monterey to create the archive. Anyway, all the commands used to create the resource fork were included (in the BBEdit worksheet file) so you could recreate the work. You need a location for the .r resource headers. I used a set from MPW. Other sources include macOS SDKs and frameworks (the required file is CodeFragments.r or CodeFragmentsType.r)

DearthnVader said:
I made up a quick and dirty Mac OS extension and zeroed the driver,AAPL,MacOS,PowerPC property from Open Firmware's device tree on my card, then booted the Mac OS (9) and the driver did work, discs mounted under OS 9.

However that was with the SeriTek firmware, I'll flash the Webitech firmware to the card and see if the 'NDRV' is still compatible.
Click to expand...
DearthnVader said:
Sadly, and not shockingly, that didn't work. I think my disk based 'NDRV' tried to load and then went to abort when it found one or some of the cards .properties wasn't what was expected.

The easiest thing to do would be to reduce the Seritek firmware and try to remove the EEPROM ID check, but I don't know if anyone else is interested in this so I don't want to invest much more time in it if other people are not going to use it or find it useful?

What we did so far was kind of fun, it was interesting to figure some of this stuff out, tho @joevt did most of the heavy lifting for us.
Click to expand...
Well, the OpenFirmware code can be easily changed since tokenization and detokenization are 100% reversible. But the ndrv would take more effort. The Jasik Nosy disassembler produces assembly that can be compiled with a few minor changes and some macros which is what I did with the sixty6 ndrv. Assembly is not easy to work with. But if you just need to change some IDs then you don't need to disassemble and recompile.

DearthnVader said:
Joe already included a reduced ROM for us, but it doesn't have the OS X driver either.
Click to expand...
You can put the code for either driver back into the OpenFirmware code easily. The OpenFirmware code is 11K. The mkext is 71K. The ndrv is 56K. How much space do you have?
 
  • Like
Reactions: Amethyst1
DearthnVader said:
I made up a quick and dirty Mac OS extension and zeroed the driver,AAPL,MacOS,PowerPC property from Open Firmware's device tree on my card, then booted the Mac OS (9) and the driver did work, discs mounted under OS 9.
Click to expand...
I spoke too soon, must have made a mistake when zeroing the 'NDRV' from the device-tree, the driver I made doesn't work.

It would be interesting to know what is needed in the resource fork to make a disk based 'NDRV' load for the classic Mac OS. I thought I knew, but it doesn't work, back to the documentation I suppose, you know what they say, when all else fails, read the instructions.

One thing that has me puzzled, this string from the 'NDRV':

Code: 
@mtej........pci1095,3112

Generally whatever comes after @mtej is a text string to help the driver match the hardware in the drive tree or IODispalyNameReg, it is normally the " name" property or the " compatible" property built by the FCODE ROM.
 
joevt said:
The macOS Archive zip utility does preserve resource forks. Maybe you need to use a newer version of macOS. I used Monterey to create the archive. Anyway, all the commands used to create the resource fork were included (in the BBEdit worksheet file) so you could recreate the work. You need a location for the .r resource headers. I used a set from MPW. Other sources include macOS SDKs and frameworks (the required file is CodeFragments.r or CodeFragmentsType.r)



Well, the OpenFirmware code can be easily changed since tokenization and detokenization are 100% reversible. But the ndrv would take more effort. The Jasik Nosy disassembler produces assembly that can be compiled with a few minor changes and some macros which is what I did with the sixty6 ndrv. Assembly is not easy to work with. But if you just need to change some IDs then you don't need to disassemble and recompile.


You can put the code for either driver back into the OpenFirmware code easily. The OpenFirmware code is 11K. The mkext is 71K. The ndrv is 56K. How much space do you have?
Click to expand...
I have a full EEPROM, likely 256k, but most of these cards come with a 128k EEPROM I think. The goal would be to remove the classic Mac OS 'NDRV' from the ROM while leaving the OS X kexts if that will fit the EEPROM the generic 3112 cards most likely have, but there is still the issue of the EEPROM ID check that has been reported to make the FCODE go to abort when one of three "whitelisted" EEROM ID's are not found.

I'll order one of the generic cards, they only run about $15 and see if I can gain some more insight.
 
DearthnVader said:
Here is a disk based 'NDRV' for the SCSI AVA-2906 that has no EEROM, for the classic Mac OS.

2906_v13_driver.hqx

We can likely learn what we need to know from it to make our disk based 'NDRV' for the PCI 1095,3112.
Click to expand...
The cfrg in that driver appears to match what I ceated.

Code: 
derez "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver" /Volumes/Devs/MPWStuff/Interfaces\&Libraries/Interfaces/RIncludes/Carbon.r > "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver.r"
bbedit "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver.r"

Did you set the file type to 'ndrv' and the creator to '????' or whatever the default createor should be...
Code: 
xattr -px com.apple.FinderInfo "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver" | xxd -p -r | xxd
00000000: 6e64 7276 4164 2531 2100 0000 0000 0000  ndrvAd%1!.......
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
What Finder flags does that 0x21 byte represent?
 
joevt said:
The cfrg in that driver appears to match what I ceated.

Code: 
derez "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver" /Volumes/Devs/MPWStuff/Interfaces\&Libraries/Interfaces/RIncludes/Carbon.r > "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver.r"
bbedit "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver.r"

Did you set the file type to 'ndrv' and the creator to '????' or whatever the default createor should be...
Code: 
xattr -px com.apple.FinderInfo "Adaptec SCSI Card 2906 Driver/Adaptec SCSI Card 2906 Driver" | xxd -p -r | xxd
00000000: 6e64 7276 4164 2531 2100 0000 0000 0000  ndrvAd%1!.......
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
What Finder flags does that 0x21 byte represent?
Click to expand...
Yes I did see this, we should be able to just replace the data fork in the Adaptec driver with our's from the SerilTek and it should just work.

It seems to do something, but it has some sort of conflict with the 'NDRV' in the device tree from Open-Firmware. I thought I could just do this:

Code: 
0000 encode-int " driver,AAPL,MacOS,PowerPC" property

But that prevents the disk based 'NDRV' from loading at all. I could just flash the reduced rom back to the card, but do you know a way to just delete this property from Open Firmware for testing?
 
I have an authentic firmtek 1v4 card in my mdd, did you guys want the firmware off of that? along with pics of the eeprom chips?
 
DearthnVader said:
Code: 
dev pci1/@e
" driver,AAPL,MacOS,PowerPC" delete-property
device-end

Disk based driver still doesn't load the 'NDRV' tho..........

Frustrating?
Click to expand...
The native driver package is a CFM code fragment that may reside in the Macintosh ROM, in an expansion ROM, or in the data fork of a Preferred Execution Format (PEF)file. File-based generic and family driver fragments do not need a resource fork, have a file type of 'ndrv', and have an unspecified file creator. ROM-based PCI drivers may be replaced by disk-based versions of the driver located in the Extensions folder. PEF and the CFM are described in Inside Macintosh: PowerPC System Software.
Click to expand...
Is the 'NDRV' @joevt extracted the the FirmTek ROM not a PEF file?

Also, I don't understand how a file without a resource fork can have a file type of 'ndrv'?
 
Last edited:
DearthnVader said:
Is the 'NDRV' @joevt extracted the the FirmTek ROM not a PEF file?

Also, I don't understand how a file without a resource fork can have a file type of 'ndrv'?
Click to expand...
The Adaptec ndrv and the ndrv I extracted have a cfrg resource so it's not true that it doesn't have a resource fork.

But file type/creator and Finder flags are not part of the resource fork. In Mac OS X, they are accessible as the com.apple.FinderInfo extended attribute and the resource fork is accessible as the com.apple.ResourceFork extended attribute. In Mac OS 9, file type/creator and Finder flags are accessible using file system APIs (which exist in Carbon for Mac OS X as well). In either case, the file type/creator and Finder flags are part of the HFS file system. On a FAT partition, they may use the AppleDouble format. https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats
I suppose arbitrary extended attributes that are not com.apple.FinderInfo and not com.apple.ResourceFork are stored differently.
 
  • Like
Reactions: Amethyst1
Great. It's a lot more than anyone else has managed to do. Even if it only functions as a proof of concept. Hopefully I can drag my MDD out sometime in the next week and give it a whirl.
 
weckart said:
Great. It's a lot more than anyone else has managed to do. Even if it only functions as a proof of concept. Hopefully I can drag my MDD out sometime in the next week and give it a whirl.
Click to expand...
The driver appears to be compatible with the WiebeTech firmware, really it should be firmware independent. I maybe able to make it work with unflashed PC Cards.
 
  • Like
  • Love
Reactions: lepidotós, G4fanboy and weckart
I am very deeply impressed with the work you guys have done. I never expected the classic driver to gain so much traction when i asked if it was possible. Whenever you release the driver file i will give it a test on my blue and white rev a and see what happens. Can you see a bootable sata drive from the classic startup disk control panel now?
 
  • Like
Reactions: lepidotós
Semi-necro bump, but does anyone have the zip file linked in the original post? OP deleted it and isn't accessible anymore.
 
so i bought an ebay flashed card and originally it didn't want to boot. so i was mucking around and tried the seritek 5.1.3 flash and it did flash, but didn't boot.

I then tried the wiebe3112 flash on mac and now the card boots but it takes forever to load into OS X.

when i try the seritek 5.1.3 or the 5.3.1 flash, it says that there is no card.

now the chips on my sata card are as follows...

*main chip*
Silicon Image
SATALink
Sil3112ACT144
Q21930.1
0247
1.1

*rom chip*
PCM Flash
0527
Pm39LV040-70JC

i am trying to flash this on a B&W G3. should i try different pci slots including the graphics slot?
am i doing something wrong and maybe have no idea what i'm doing?

any info would be appreciated
 
ok, so the card wouldn't flash at all in my B&W but i put it in slot 5 in my QS 2002 with leopard and the card flashed saying successful with seritek 5.1.3 firmware.

now i put the card into my B&W and will run the fscapp for tiger and see if that helps with anything

*EDIT*
so far, i get the flashing folder with the classic icon first for about 10 seconds then i get the osx logo and it just hangs there, no gear, just the logo. been sitting here for 5 min at least

*EDIT 2*
put the card into my QS in slot 5 and i get the same thing trying to boot off of the card. just the apple logo and nothing else. will revert back to the wiebe3112 firmware to see what that does

Well, the QS KP'ed. will flash the wiebe firmware in the B&W
 
Last edited:
So, to make my beige G3 somehow "complete", i wanted to have real SATA too and ordered one of these cheapo-cards from China for 10 Euros.

It's not 3112 but 3114 based. But that has not been much of a problem. Had to use the latest available version of Updflash, which is 3.36 as the one from this thread does not support 3114. Also the winbond EEPROM on the card was not in the list of supported chips. But flashing worked fine with choosing the first 1MB-part from the list.

I used the WiebeTECH-firmware which does not support OS9. But that's ok for me. Also the two additional ports on top of the card not working. Card boots fine with the ones on the rear end.

But, what really is bit of a disappointment, is the performance in a few glorious moments i got to see around 50MB/s read/write, which schould be the absolut minimum for a card like that. But since then it fell back below 30 and didn't give better results ever since. I use it with a 7.200rpm HD as the card turned out to be very picky on SSDs. But testing SSD made no difference performancewise.

So what do others get from these card's? I have another one in a G4 tower, which at least reaches steady around 50 read/write. But the one in the G3 is stuck below 30, which at least IMHO is a bit poorly for SATA.
 
  • Like
Reactions: Amethyst1
flyproductions said:
So, to make my beige G3 somehow "complete", i wanted to have real SATA too and ordered one of these cheapo-cards from China for 10 Euros.
Click to expand...
I just ordered a 2 port card from eBay that claims OS 9 capability. I paid closer to $70 with shipping. I have a feeling it is not going to work for me.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back