Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Sonnet Tempo ATA133 and ATA100 PCI - PROMISE cards flashing quest
- Thread starter 666sheep
- Start date
- Sort by reaction score
Yes but all these chips should be 20268 compatible, with the EEPROM integrated in the PDC chip.
@Ataman Honcho Honchev , Can you offer any insight into how to get around the seeming 16k lock on PC PDC20268/269/270 cards eeproms?
Flashing the Mac ROM to the card with a hacked Sonnet flasher always seems to result into changing the Device IS to that of the 20268 and we have to use our hacked 16k ROM.
Even the TX 100 Fasttrak card that came with a 66k PC Bios won't take the full Mac ROM.
Also OS9Lives is having some issue with login from the main forum list:
Hopefully DieHard can get that fixed, I sent him a message.
Flashing the Mac ROM to the card with a hacked Sonnet flasher always seems to result into changing the Device IS to that of the 20268 and we have to use our hacked 16k ROM.
Even the TX 100 Fasttrak card that came with a 66k PC Bios won't take the full Mac ROM.
Also OS9Lives is having some issue with login from the main forum list:
Hopefully DieHard can get that fixed, I sent him a message.
Last edited:
The 268-269-270 cards have a custom lock / unlock sequence. Eons ago I had the code from Promise and of course was able to unlock all of them. Than, just before the COVID I tried it again - and it did not work anymore.
If I remember, I did all the unlocking on the "Old World" ("beige") machines, so maybe that's the problem.
Currently I don't have a working "Old World" and this problem is postponed until I am done with re-making the Silicon Image and Sil3124 driver for MacOS 9. Than I can tell what it was, but not all the details.
And maybe this entire issue is moot because the SImage / CMD 680 is easier to deal with than with Promise.
No issues with CMD 680 and it's a later design than what we had from Promise.
Is it OK to upload disk images with binaries?
The fourth "beta" of the Silicon Image 3112 SIM for MacOS 9 is ready to be tested.
There is no flashing, it's just a system extension to be dropped into the System:Extensions folder and re-boot.
Others (3114, 3512) to follow.
The fourth "beta" of the Silicon Image 3112 SIM for MacOS 9 is ready to be tested.
There is no flashing, it's just a system extension to be dropped into the System:Extensions folder and re-boot.
Others (3114, 3512) to follow.
I think you just need to zip the disk image to upload it.
Is a SIM the same as a NDRV?
How is your SIM different than the NDRV included in the sil3112 Mac firmware that @dosdude1 recently modified?
I think dosdude1 did binary modifications (change some bytes) but I didn't try a compare to see what changed. You are compiling the entire SIM from source code?
If firmware contains an NDRV, and macOS 9 contains an NDRV, which gets used?
SIM = "SCSI Interface Module". It is normally distributed either as a stand-alone extension (a special kind of NDRV) or that NDRV is embedded in the OF ROM.
In "Beta" phase (and prior) it is foolish to embed in the ROM because it means running the flash utility (what I obviously have) many times a day. It is also slower to make a fix. The ultimate form is of course as a part of flash utility.
----
Since I made quite a few ATA and SATA "SIM"-s (most likely including the one dosdude1 patched) - this one is of course not a "patch" of any existing SIM. I don't need to do that ;-)
Indeed, zip-ing the disk image worked, so the "beta4" of the SIM for 3112 is here.
The disk image is the one used in macOS X. Inside there is a single file called "SImagic2Demo".
When you drop that file into the System folder the macOS 9 will ask you to move it into System:Extensions folder (which is the proper place for that extension).
After the reboot you will see a virtual SCSI bus (ignore it's properties - they are meaningless) corresponding to a (hopefully installed) generic Silicon Image 3112 SATA card.
The drives won't mount automatically, you have to mount them "by hand".
It is not a patch because unlike any release of SeriTek/1S2 (and all the unofficial patches) this extension does support drive hot-swap, similar way as the SeriTek/1SE2 which never ever was "pirated" (as it is tied to a secure ROM).
The extension is of course not tied to anything - it's just displays as being non-commercial demo and of course it is not ready for prime time because it wasn't tested rigorously and I know quite a few bugs to be fixed.
I may post "SImagic4Demo" soon, that will be the same thing, only for Silicon Image 3114 (which never was released for "9").
The disk image is the one used in macOS X. Inside there is a single file called "SImagic2Demo".
When you drop that file into the System folder the macOS 9 will ask you to move it into System:Extensions folder (which is the proper place for that extension).
After the reboot you will see a virtual SCSI bus (ignore it's properties - they are meaningless) corresponding to a (hopefully installed) generic Silicon Image 3112 SATA card.
The drives won't mount automatically, you have to mount them "by hand".
It is not a patch because unlike any release of SeriTek/1S2 (and all the unofficial patches) this extension does support drive hot-swap, similar way as the SeriTek/1SE2 which never ever was "pirated" (as it is tied to a secure ROM).
The extension is of course not tied to anything - it's just displays as being non-commercial demo and of course it is not ready for prime time because it wasn't tested rigorously and I know quite a few bugs to be fixed.
I may post "SImagic4Demo" soon, that will be the same thing, only for Silicon Image 3114 (which never was released for "9").
And here is the same thing - for Silicon Image 3114.
Did not test it much - but ALL FOUR channels do show up in macOS 9.2.2 on my MDD FW400.
It also supports hot-swap, SeriTek/1SE2 (or SeriTek/1VE4) UI-style. Other UI-style for macOS 9.2.2 is probably way to much work but still thinking.
The version was bumped to 6.0.0beta5, just because it is a new card to support.
The performance of SImage 3114 is much worse than of 3112.
And I can't do much about it. As we say: "if there is shortage of fish - than the crayfish is declared to be a fish"
("на безрыбье и рак рыба")
But at least there is plenty of 3114 around and it is cheap.
Did not test it much - but ALL FOUR channels do show up in macOS 9.2.2 on my MDD FW400.
It also supports hot-swap, SeriTek/1SE2 (or SeriTek/1VE4) UI-style. Other UI-style for macOS 9.2.2 is probably way to much work but still thinking.
The version was bumped to 6.0.0beta5, just because it is a new card to support.
The performance of SImage 3114 is much worse than of 3112.
And I can't do much about it. As we say: "if there is shortage of fish - than the crayfish is declared to be a fish"
("на безрыбье и рак рыба")
But at least there is plenty of 3114 around and it is cheap.
Do not know how come "GoDaddy" missed "ragemac" (since there was ATI Rage for the Mac and "ragemac" is a short name). Anyway since few weeks the www.ragemac.com is not free anymore. ;-)
You will find "RaGeMac" and "RetroMac" all over inside of these SIM drivers.
Unfortunately "retromac.com" was reserved (and of course who reserved it does nothing, just occupies that name).
So it will be "ragemac.com".
And what you see are two SIM-s built from self-made sources...
After a nearly 20 year pause SIM-s for MacOS 9 are built again. Not by ATTO, Sonnet, ACard (you name them).
You will find "RaGeMac" and "RetroMac" all over inside of these SIM drivers.
Unfortunately "retromac.com" was reserved (and of course who reserved it does nothing, just occupies that name).
So it will be "ragemac.com".
And what you see are two SIM-s built from self-made sources...
After a nearly 20 year pause SIM-s for MacOS 9 are built again. Not by ATTO, Sonnet, ACard (you name them).
Last edited:
I think that 'NDRV's contain a production date, so if you have one in ROM and one one disk, the one with the later production date will be used.
They have nothing to do with each other. The one in the ROM applies to the OF. The one in KEXT applies to the macOS X / whatever new numbering scheme is. The one in the SIM applies to macOS 9. These could be different and the newer one will have the priority. But: if the source of the driver is different, that may not apply.
For instance the current SIM is 6.0.0b5. Which is clearly "superior" to FirmTek 5.3.x. However since the 6.0.0b5 comes from RaGeMac and not from FirmTek, (hopefully!) they won't conflict. By intent I did everything not to "match" the SeriTek cards: "do not fix what is not broken".
If someone later would want to replace the FirmTek SIM with the RaGeMac SIM - there will be a special flash utility by demand.
In their "INFINITE WISDOM" (ROFL) the local utility company decided to have a maintenance black-out during working hours tomorrow. Thus, while having nothing better to do - will go from the home #1 to the home #2 tomorrow.
That means: a full day in the train. Luckily, got a "new" Titanium G4 today and have time to kill while setting everything up for these SImage 3112 / 3512 PCMCIA cards.
And there won't be a new SIM release in coming 1-2 days.
That means: a full day in the train. Luckily, got a "new" Titanium G4 today and have time to kill while setting everything up for these SImage 3112 / 3512 PCMCIA cards.
And there won't be a new SIM release in coming 1-2 days.
The one I patched was part of the FirmTek SeriTek/1S2 ROM, which I believe you wrote or at least had part in, if I'm not mistaken. Of course I don't have the source, so I simply used a disassembler to analyze the binary, and patched it to remove that worthless EEPROM ID check. I of course did the same with the OS X driver (kext), and also wrote and added an LZSS decompression routine into the FCode ROM, allowing me to store the now-patched OS 9 NDRV ("SIM") in a compressed form, which allows the entire ROM to fit onto a 128K EEPROM.
Makes it WAY easier to flash the SeriTek/1S2 ROM onto normal Sil3112 cards, though of course an updated version built and released by yourself would be even better.
You are 100% correct regarding LZSS. It was a hell to make it in FCode (and I think, I have a bug there: it does not work with Sun...
). One day I may figure it out, why is that. The LZSS is there more because the Intel / Vitesse chip has only 128KB ROM space, less for obfuscation. Still, sometimes the SeriTek/1Vxxx cards won't start on Mac (and never start on the Sun).As for the SIM and KEXT: the 1SE2 is far more advanced than the 1S2 because it supports hot-swap.
But by today's standards both are pretty much outdated... I am looking at what I did back than - and shaking my head.
Correction: I use LZARI or whatever is it's name.
I've attached my Forth implementation of the LZSS decompression algorithm. Feel free to use it if you want, it was actually not too bad to implement. (This is actually a second implementation, based off another, but broken, Forth LZSS implementation I found online).You are 100% correct regarding LZSS. It was a hell to make it in FCode (and I think, I have a bug there: it does not work with Sun...
As for the SIM and KEXT: the 1SE2 is far more advanced than the 1S2 because it supports hot-swap.
But by today's standards both are pretty much outdated... I am looking at what I did back than - and shaking my head.
Correction: I use LZARI or whatever is it's name.
I may consider patching the 1SE2 ROM as well, but I really don't see a need, as I don't think I've ever had a need to hotswap a SATA device.
Thanks - will try that later. As far as either 1S2 or 1SE2: neither knows much about SSD-s and back than the faulty Marvell bridge chip was the norm. So I had to slow down from UDMA-133 to UDMA-100.
That's right: neither 1S2 nor 1SE2 does support UDMA-133, they set up the speed to UDMA-100.
In the theory this should not matter because SATA-150 runs always at 150MB/Sec. However these times the SATA drives were in the fact fake SATA drives, implementing that faulty Marvell bridge on the PCB.
The only exception was Seagate - but their "Avalanche" drives have a nasty habit of fail when the write transfer is 15x + 1 blocks. The Linux code for 3112 / 3152 / 3114 has a quite bad fix... mine was better (but of course such fix can't be perfect). Just google at the Seagate Errata with 3112 / 3152 / 3114 and Linux.
Interestingly, the Linux info is not perfect - we got better details from SImage back than, so I could implement a better workaround.
Regardless: the Avalanche drives and the faulty Marvell PATA <--> SATA bridge are long history, so even from that perspective the original driver set of 1S2 / 1SE2 is also a history.
That said, there are (quite) some synchronization problems with the SIM, so the rest is not perfect either.
I still think that if someone is OK with the old driver: do not fix what is not broken.
Otherwise see the beta4 and beta5 from today.
The different question: of course, no copy protection is perfect and ideally there shouldn't be any.
But how can I make living than? Asking for donations?
Recently someone wanted to get from me the license for an "amazing" $5 / ROM. No comment about this.
Unless of course the $5 / ROM driver set does not support 48-bit LBA, does not support hot-swap and has other limitations (like nagging window).
Ahh, well that explains the max 100 MB/s speeds, then. Interesting about the Marvell SATA-IDE bridge, these days the 88SA8040 and 88SA8052 seem amazing compared to the horrible garbage JMicron JM20330 chipset seen on a lot of cheap Chinese SATA to IDE adapters these days.
With regard to making a living off these cards... That just simply isn't a realistic expectation, no matter which way you put it. There is a very small market for SATA cards for vintage Macs. Adding needless copy protection only hurts hobbyists, and in the end only serves as a minor inconvenience for a determined individual. The only way I can see to actually make SOME money off a project like this is designing, building, and selling a custom card with your ROM pre-flashed. People WILL pay for that, but not some astronomical cost ($100+), as again these are for vintage machines.
These days, with these machines getting on 20+ years old, such projects should be treated more as a hobby, and not something to make large sums of money off of. This is exactly how I treat such things; for example, the IDE SSDs I've designed I do sell, but I also open-soured the entire board design, and all resources needed to build and produce them yourself. Because, like PCI SATA cards, the market for IDE SSDs is small, and it's worth more to me to have my design open and accessible for others to use and modify as they'd like, rather than keep it locked down and get on people for trying to "steal" my stuff. Again, treating it as a hobby, not a business, because as a business, it is not feasible, nor makes any sense.
In my experience, 3112 (1S2's firmware) and 3512 (WieBeTech's firmware) both have problem (system hang) in OS X when I connect two Seagate drives or even one WD and one Seagate drives to the card. May be that is the reason?
To use two Seagate drives in OS X, I have to use two 3112 cards, one for each drive.
Strangely, such problem doesn't occur in OS 9.
I am talking about the Marvell 88i8030 bridge. You can find it on the Maxtor DiamondMax Plus 9.
My drive is from Aug. 14 2004. The later Marvell bridges are better. But back these days both WDC and Maxtor used the same 88i8030.
The JM20330 is OK, if you are lucky to find the proper manufacturer. Most sold on the fee-Bay are made at the same bad place. Ultimately I bought (quite a) few good ones. But not before got burned by some of horrible design.
The 3112 and it's siblings aren't to make much money today: the performance is quite bad.
However they are good enough to spread the word.
For now I think at least the enabler(s) (both "SIM" and KEXT) for PowerBooks will be full-featured and free.
What do you think is a reasonable amount of money people should pay extra compared to "regular" PC cards?
$100 is of course ridiculous, but IMO so is $5.
Or maybe the best solution could be a "nagging-ware"? No lock in any form, just a window appearing every "X" number of minutes politely nagging to donate "Y" amount of Bucks via PayPal? Once the money is donated, the driver is updated to a non-nagging version.
Custom cards should be made with other chips (like 3124 and similar) where performance is better.
And of course there should be a PCI-X to PCI-e bridge. On a G5 with PCIe slots I did achieve over 700 MB/Sec with an NVMe drive running Leopard.
NVMe on Tiger or earlier is a challenge - but on MacOS 9 I think NVMe is easier than on Jaguar, Panther or Tiger.
On Leopard it is pretty straightforward.
Same about SAS controllers - but without a proper PCI-X bridge we are stuck at PCIe G5 or later.
I'd say somewhere around $40 or $50, maybe $60 is reasonable for a completely custom, pre-flashed card with your firmware. I REALLY would not resort to any sort of nagging or feature removal with a "free" version. Make your money with the hardware, and by having a good source where someone can simply buy a plug-and-play card to use in their Mac hassle-free. But do NOT make it an unnecessary pain for a DIY user/enthusiast. If your cards are good and reasonably-priced, anyone looking to buy a pre-flashed card will buy YOUR card, and anyone who would prefer to make one DIY-style wouldn't be purchasing your card anyways. So don't hurt the very few DIY users by adding unnecessary feature removal, nagging, or copy protection; rather, cater to the much larger user-base that would prefer to buy a card pre-flashed.
Thanks, going to look into that when the focus is on the "X" driver. For now the priority is to complete the new SIM.
Which would:
- provide all known workarounds for blacklisted drives (kind of done)
- provide workaround for Errata #3 of the 3512 and 3114 (done!)
- complete investigation, why back in 2005 only one channel could be used simultanousely on disk writes with the PCMCIA card I have (maybe because of the Errata #3 and the card is 3512-based? Talking about SeriTek/1SM2).
That fact was successfully hidden back than, but the 3512 Errata #3 wasn't known in 2005.
- Ensure, multiple 3112 cards can be used in the same machine the same time. There is an interesting "something" I have in mind (PCI-X RAID cards with two or three 3112 chips and Intel 960 - derived bridge).
- Using proper locks instead brutally disabling the interrupts
- Properly deal with Marvell 88i8030 bridge. The drives having it do not report being SATA drives at all - there the UDMA-100 limitation is reasonable. The SATA standard evolved and the drives made today report everything properly. If a drive reports being 6G SATA-compliant than there is no reason to deal with faking the UDMA-100 like on drives which look like a SATA (for uninformed) - but in the reality are converted PATA drives without reporting being SATA. That's exactly the case with ancient DiamondMax-9 drives, but they should not hold back Samsung 840 SSD-s as they do it now.
Ideally there should be a solution to lift the 4TB drive size limitation on MacOS-9. The HFS+ file system itself - as we know well - is capable to deal with 64-bit LBA transfer.
But I am unsure, the SCSI Manager 4.3 does issue SCSI commands dealing with 64-bit LBA.
AFAIK, no later, than in "G4 / Gigabit Ethernet" the ATA Manager of MacOS 9 does support 48-bit LBA commands. But AIM (ATA Interface Module) API-s were never made public. Similar problems exist with Open Firmware: I don't recall, I ever received an LBA over 32 bit. G4-s have internal ATA calls within OF, but these are never made public.
All this can be addressed... just not within next few months.
Good point and fair price.
The only problem is to find a proper manufacturer. For now: the only manufacturer I found is willing to pay $5. And it is IMO an offense. Do not want to mention who is that manufacturer - but I am reluctant (mildly speaking!) to provide a full-featured solution (SIM + OF + KEXT) for $5 / card. If he would keep the price closer to your range than it won't be any question.
The other problem are the manufacturers of 3112, 3114 and 3512. Even if they know that in order to be compatible with "Digital Audio" and "Quicksilver" Macs these cards require a slightly more expensive 3.3V regulator. All the manufacturers (even the one who manufactured for us the SeriTek cards) resort to cheaper regulator which won't allow the involved machines to wake up from sleep.
And in order to save additional few Cents, the ROM used now in 3112 / 3114 / 3512 is merely 128KB, forcing me to be very cautious with the code size.
All this makes me wonder, maybe the VIA6421A chipset is more convenient, than Silicon Image. True, the ROM size is a mere 64KB, but I can deal with a minimal bootstrap driver and the rest is loaded from the disk. Here the "9" would be the highest priority, having a minimal KEXT in the ROM and using it just to load a full-featured one from the disk is not a problem.
Well, if you do want to go this route, I can make a PCB design for you, based on the chipset of your choice. I have many of these SATA cards I can disassemble and reverse-engineer to derive a schematic from. Manufacturing-wise, many PCB manufacturing facilities, such as JLCPCB, PCBWay, etc. offer SMD assembly as well, where you can simply provide them a BOM and source for the parts, and they will assemble the boards for you using a pick-and-place machine after manufacturing them.