Get ready for the buffer...

Well, I replaced the buffer but it didn't change anything. Here's below is shown how the POST screen is broken with Samsung mSATA SSD. It's interesting that not only whole characters are missing but also font is broken, I wonder how this can happen when the font is in ROM used by font generator. Other ISA controller that doesn't break like this is not too much different...

maybe PAL IDE port address decoding is leaky, and SSD replies with something even to non valid commands?
edit: or bios buffer overflow? 😀

rasz_pl wrote on 2022-12-03, 12:53:

maybe PAL IDE port address decoding is leaky, and SSD replies with something even to non valid commands?
edit: or bios buffer overflow? 😀

I suspect the BIOS, at least in parts.
A DOM hung my Schneider Tower AT with a 1988 Phoenix BIOS during POST.

After disabling HDD in Setup, installing XTIDE Universal BIOS in an EPROM hosted by a network card, it worked.

It might be related to ATA-2 (Fast ATA), which changed some bits of the original IDE specification.

http://www.os2museum.com/wp/how-to-please-wdctrl/

>Jo22
It makes sence, BIOS might contained some bug that was triggered by too high cylinder value reported by disk so it hung. After disabling HDD this buggy code was skipped and everything was fine. But it's not my case. It hangs before disk is initialized and doesn't matter if I have disabled all drives in BIOS. No difference if XTIDE is plugged in or not because it hangs also before XTIDE initialization.

The only way would be boot from a diskette with disabled power to mSATA SSD and plug power connector after boot. If it makes harsh to the bus it will hang too, if not I could run some diagnostic tools to try detect the SSD if it will communicate. As I told before this issue seems to be only with one type of IDE controller with another it doesn't hang this way. But still I can't imagine how it is possible to damage the font in textmode this way...

I made an interesting experiment - I booted DOS from a floppy and used my SMB tool to directly talk via IDE to SSDs. Transcend SSD responds to Identify Device but the reply is corrupted, checksum doesn't match. Device name string and S/N is empty but some other fields seems to be filled correctly. Then I tried to read MBR (sector 0) via LBA and CHS commands and both worked so there's no problem that SSD doesn't knows CHS commands.

With Samsung SSD I had to overcome the hang this way. I powered the system with unplugged power connector from SSD, booted froom floppy and then carefully connected power connector to SSD and I got a garbage on screen immediately. But the system remained responsive and I can blindly type command. I also store MicroManager on the floppy that surprisingly runs fine, displays both blue file panels without any corruption. I don't know if it draws via BIOS calls ot rather it probably writes to VRAM directly. When I swith to DOS screen I see still that garbage and switch back brings me clean file panels. So I run SMB redirected to file but I see it didn't detected the SSD. So then I replaced the IDE controller with second one that doesn't hang at boot and then it behaved same as Transcend SSD - Identify response was crippled but read sectors both LBA and CHS.

I also tested another IDE-SATA adapter with platter SATA HDD but the same.

So the question remains what is causing the data corruption on the bus when using SSDs while with platter PATA HDDs and CF cards it works fine. It makes sense that when XTIDE receive a crippled response to Identify Device it gives up with HDD so XTIDE is not involved any way in this issue. I belive when data corruption root cause would be revealed and fixed then XTIDE will works fine. This would need definitely a bus analyzer, I have only cheap 8-bit cypress-based from Ali...

I just remembered some standard confusion around byte order when returning drive_identify, have you tried dumping response and flipping bytes around? https://www.os2museum.com/wp/vague-standards-are-trouble/
also comparing bad raw response to one from working computer might give some clues

Hm, flipping bytes, i can do it. I can see raw buffer after any command. But why platter disks and CF doesn't flip and SSDs do?

>I got a garbage on screen immediately

😮 😀 fun fun
power spike is unlikely, SSDs use a lot less power, but maybe its super noisy?

>another IDE-SATA adapter

different chip?

>cheap 8-bit cypress-based from Ali

$5 CY7C68013A one is perfect, its actually 16bit ( might need opening up and modding additional 8 pin header if its salea clone and not just dev board) https://www.youtube.com/watch?v=c3HsBJWpB9Q
grab two captures, one all 16 data bits, another with 7 data bits (so we can later sync both captures up) and /r /w /a0 /a1 /a2 /dmar /dmaa /int /cs0 and we are in business assuming drive consistently returns same response

Oh, look at buffer data again, I oversight it. I display the data buffer as array of 16bit words so it's OK to be flipped due to little endian. BUT all the MSBs are zero! E.g. the last bytes of MBR should be 55, AAh or as a word AA55 but there's only 0055 in the buffer. This is the problem. Now I need to know, if the MSB was sent out of SSD to the controller and lost somewhere on the way or if SSD gave crippled data with only valid LSB but zero MSB. This also probably cause that device ID string starts with 00 is treated as empty string so it's not printed at all.

That bidirectional IDE-SATA adapter is based on some unknown TQFP chip marked IDE/SATA DQF 875S50041
http://rayer.g6.cz/hardware/gap67ds3/idesata1.jpg

The analyzer is USBee AX PRO, quite a small box, no other header space on PCB. There's just CY7C68013A and one HC245 buffer. I would need to solder directly on CY legs...

https://sigrok.org/wiki/MCU123_USBee_AX_Pro_clone yep ideal for modding, I dont even have 244 buffers on mine (Im using old usb IDE converter board https://serwis.avt.pl/manuals/AVT5096.pdf)

/IOCS16 indicates to the host system that the 16-bit data port has been
addressed and that the device is prepared to send or receive a 16-bit
data word.

Upgrading and Repairing PCs, 21st Edition
"Pin 32 was defined as -IOCS16 in ATA-2 but is no longer used."

your sata-pata converter is not asserting /IOCS16?

also another anecdote from os2museum https://www.os2museum.com/wp/learn-something- … ry-day-part-ii/ Michal Necasek is a goldmine of ATA knowledge 😀

Hey, does anyone want to take on a *actual* Sata Isa card project? (Don’t look at me)

It seems to me like if you guys can get it working on a bread board and work out the bugs that making them really wouldn’t be that hard. parts are easily available Just need A bridge chip basically maybe a basic ide controller chip. If even that. And some Resistors/regulators and capacitors to make it work. Working out the bugs like you guys apparently are already doing is probably the biggest challenge. Many of the parts can be harvested from cheap adapters.

Sphere478 wrote on 2022-12-07, 14:48:

Hey, does anyone want to take on a *actual* Sata Isa card project? (Don’t look at me)

What is wrong with using a working PATA-SATA bridge? ISA is sort of a superset of ATA-1 from a wiring perspective, so for all intents and purposes, a PATA to SATA bridge is essentially an ISA to SATA in every way that matters. Stick a PATA-SATA on your existing IDE card and you are good to go.

What are you looking to gain with an ISA Sata card?

Yes, I know. But having a actual isa sata card would be pretty cool. 😀 This would basically be the only point. “Because it is cool”

rasz_pl wrote on 2022-12-07, 12:47:

/IOCS16 indicates to the host system that the 16-bit data port has been addressed and that the device is prepared to send or rec […]
Show full quote

/IOCS16 indicates to the host system that the 16-bit data port has been
addressed and that the device is prepared to send or receive a 16-bit
data word.

Upgrading and Repairing PCs, 21st Edition
"Pin 32 was defined as -IOCS16 in ATA-2 but is no longer used."

your sata-pata converter is not asserting /IOCS16?

Seems you hit a hammer to a nailhead! I found a discussion with this comment:
After some basic diagnosis with a volt meter on the IDE cable and visual inspection of the SATA adapter boards today, I think I have an idea about why the MSB is missing. None of the SATA adapters control the -IOCS16 line, so they’re really designed for DMA transfer only where the line is ignored. RiscPC doesn’t support DMA, only PIO, so it’s expecting -IOCS16 to be pulled low if 16bit data is presented on the bus.

https://www.riscosopen.org/forum/forums/4/topics/9634?page=1

Goingt to measure it. But how can I restore this signal?

Try a 100 ohm resistor to ground

Yeah, that was my 1st idea to just ground it but I don't know how it's wired on the controller, if it's not going directly to AT bus, then it would be bad idea to destroy all other 8-bit transfers...

When I arrive at home I'll check the circuits how it's wired.

UPDATE:
Well, both Transcend PATA SSD and mSATA adapter doesn't have IOCS16# pin (32) wired (floating). And on both IDE controller cards the IOCS16# pin 32 of IDE connector is directly connected to ISA bus IOCS16# pin D2. So it cannot be permanently grounded.

I tried to generate IOCS16# via diode from CS0# or CS1# or 2 diodes from both but doesn't work (SSD still missing MSB or doesn'r respon at all).

Holy f0k, IDE device does combined 8b/16b access, only data register is 16b so I need to decode all A2:0, CS1:0 to generate IOCS16 properly only when data accessed. Plus IOCS16 should not be generated when doing DMA transfers...
The PATA device, when any register other than the data register is accessed, tells the ISA bus to use 8 bit transfers (on the low address lines, D0-D7) by leaving the /IOCS16 line unasserted. When the data register is addressed, the PATA device asserts the /IOCS16 line, telling the bus that this address is capable of a 16 bit transfer.

Hi,
I succeed to make a simple IOCS16# decoder using 2 log. gates IOs 7432 and 7403 (simple grounding of IOCS16# is no go as only data register requires 16-bit access and other regs. needs 8-bit). Now the SSD is identified properly and works fine on that ancient 386 with XTIDE BIOS. I plan to make some compact PCB with SMD parts that could be “glued” to backside of old IDE controller 40-pin header. Thanks to rasz_pl for valued posts helping to solve this puzzle.
Here are some photo and schematic diagram of decoder:

Oho, very nice ~

RayeR wrote on 2022-12-13, 15:39:

I succeed to make a simple IOCS16# decoder using 2 log. gates IOs 7432 and 7403 (simple grounding of IOCS16# is no go as only data register requires 16-bit access and other regs. needs 8-bit). Now the SSD is identified properly and works fine on that ancient 386 with XTIDE BIOS.

fantastic!

RayeR wrote on 2022-12-13, 15:39:

I plan to make some compact PCB with SMD parts that could be “glued” to backside of old IDE controller 40-pin header.

Im a big fan of this method of mounting mods on back of headers:
https://www.reddit.com/r/thinkpad/comments/gd … _it_is_ot_easy/

https://voultar.com/index.php?route=product/p … t&product_id=50

ps: did it also fix that weird case of Samsung mSATA SSD corrupting video?