creative commons noncommercial.
Well, I am open to any text anyone feels proper.
Fighting with Jaguar - Panther - Tiger at this moment, there is a long outstanding bug in the ATA storage driver (Apple did re-write it for Leopard... Catalina).
That bug causes the ATA / SATA channel being blocked if the controller driver immediately returns the result.
I.e.
- I get the driver identify anyway (internally), no matter what Apple ATA storage driver does.
- I also set the drive speeds and workarounds according the published quirks (good pastime to read FreeBSD or Linux code and see, what kind of drives misbehave).
- Hence, at the time Apple ATA storage driver "sees" the drive, everything is already done... and it may set the requests improperly.
Under Leopard (PPC / Intel) up to Catalina I just ignore their requests, telling the mass storage driver "I am fine, thank you".
For Drive Identify 0xEC or 0xA1 command I just copy the internally cached 512 bytes to the buffer Apple provides and return.
This is also necessary for "virtual" drives which aren't drives (port multipliers, for instance).
Pre-Leopard situation: Apple expects the request formally finish first, that get the result in the call-back.
They wanted to optimize the mass storage code... which is actually over-engineered with callbacks over callbacks.
The earlier solutions are without result caching, that started to be implemented in SeriTek / 2SE-2 first, than with 2ME4 and so on.
These cards were rarely if ever used in pre-Leopard environment, now everything will be like that, so I have to "schedule" a call-back routine for these old OS-es. Kind of pain in the neck... and playing with eon-old versions of Xcode is not fun either.
I guess, it will be done in 2-3 days but now it's 4:43AM on the "other" side of the Rhine and I am living on espresso infusions.