Duffman wrote on 2022-12-26, 08:47:
But there's no chip on that though, unlike the Sintechi ones on ebay that are known to work with 98SE.
Yup. So in theory you don't necessarily need a chip, since the SOM is handling it internally. If it doesn't connect via its internal methodology, it reverts back to IDE. Pretty clever stuff to be able to wire an SPI connection through the IDE channel like that, but it's done literally all the time in these other boards. I realize that there exists different circuitry for the one we both linked, but the basic idea is the same: some pull-downs, some caps for filtering, and some smaller resistors to prevent any damage to the SD card during eject/insert. The circuits you're linking to also do some other stuff like bus mastering, IDE port emulation, or other things that the modern SOM already can do for us I bet, but you'd need to look at the chip datasheet to know specifically what it's doing, along with knowing more about the SOM.
The thing is, this mechanism works plenty fine in DOS mode. More than fine - full speed fine. No slow down issues at all. The move to Win 9x is what slows it down, so it is highly likely to be a driver issue, one where Win 9x decides it needs to run in IDE compatibility mode. The question isn't then if the circuitry is the issue here - it's likely not (although there could be other issues like maybe you need other parts of the IDE channel grounded, but you will see that rasteri already has done that) - it's mainly why Win 9x suffers in performance and DOS 6.22 does not. There is something going on in the Win 9x driver for the IDE controller or file system PDR whatnot that is causing the issue and getting the system bugged out.
I mean, we believe we have the correct driver file, just Windows barking about it being "wrong." So in theory, even with the "right driver" we still are seeing Win 9x freak out over nothing. There is some sort of thing that the system does ever so slightly different that Win9x is not prepared for, and whatever that is is the thing causing our issue.
Because related to that issue is the issue of mounting virtual CDs, where accessing the data can lockup the system -- as well as for USB disks in disk drives (under certain circumstances). Not all CDs mind you, but quite a large number of images I have that I know work otherwise cause massive issues with hard lockup in Win 9x. What could possibly be going on to have this issue, the issue with the Refresh Devices button in Device Manager causing the same hard lockup, and the IDE controller being in compatibility mode... It has to be a problem with Win 9x somehow, and that's where I think we'll find our answer.
In the end, I wouldn't be too surprised if it turns out that it's some awkward off by 1 error, or something not being grounded, or some other easy-to-miss issue. Very likely software related, but possibly could involve a hardware fix such as you describe with an IDE emulation for a SPI based SD card.
(Oh and to answer the early question: SPI is serial programming interface, used extensively alongside I2C in embedded electronics -- if you ever do any Arduino you learn SPI and I2C pretty early on as short-distance embedded systems communication protocols.)