Stuff I'm learning:
1) 80 pin cables work fine.
2) any data value written to any IO address from 301-307 shows up at the data port (300).
This is unusual behavior, but probably doesn't effect anything, since on writes, the data is written separately, and on reads, the data comes in after writing all the other registers. The upshot of this is that it gives us a really, really good method of auto-detecting the base address of our card in the BIOS. Just write a known value or two out to base+3 and base+4 and read the same values back at base+0. easy!
3) There's fishy stuff going on with the drive parameters. Some of it may be happening if the BIOS is unable to read the Device Identification data properly. that makes sense (garbage in, garbage out) but there's at least a little stuff going on with the translation itself, and I'm investigating that. For now, use a drive bigger than 8.4G. heck, use a drive bigger than 137G and you'll really avoid the issue. (big drives have all the internal parameters maxed out, so there's no calculations or rounding to be done)
4) Drives set to cable select don't work. Single drives show up on the secondary position, 2 drives won't ID at all during POST. Setting drives as master and slave properly fixes all that. This is not a BIOS issue.
5) I've got 2 old WD drives that return status error and error code of simply "abort" when trying to do PIO reads and writes. On my modern VIA machine, doing the exact same transfer doesn't cause the error to occur. the drives are WD 21200 and 21000, circa 1995-1998. (~2Gig in size) At first I thought it was a timing issue, since the error returned via INT 13 is timeout, but increasing the timeout made no difference. It's the abort flag that is causing int 13 to bail. It's not the above mentioned drive parameter bugs that are causing this. About the only thing I can figure is that the VIA BIOS is issuing a "set features" or similar command to the drive to setup the PIO transfer rates, which modern drives must be defaulting to. Need to investigate more, but I suspect this might be causing other people problems too. The symptoms are INT 13 read or write commands returning immediately with CY set and Ah=80h. Running FDISK results in an "error reading fixed disk" error.
6) using debug on my zenith8088 machine and tracing through INT13 into the BIOS code causes the eeprom to corrupt. I suspect debug is writing something in memory whereever it is running, and since our eeproms act like dram, something is getting written. Dunno, but that's a real pain. Looking forward to write protected eeproms!
7) and two more cards were built late last week. Both seem to be working well. I have 1 more card which needs to be built up, but I've run out of eeproms, since 3 of the SEEQ parts are now bad. Must find a better solution than SEEQ.
And here's 2 new utilities:
http://www.waste.org/~winkles/id_dump.zip
this program displays the device ID data out to the screen. Works only on this card. Probably only works on the C: drive.
This will eventually be rolled into the int13 test program I wrote earlier to help discover differences in parameters between us and them.
http://www.waste.org/~winkles/ATA.zip
this one requires vga and a mouse driver to be installed. Only works on our card. This is a program written for another application at work, but it allows us to issue any ATA based command out to any drive attached to the machine.
It can do a lot of stuff (scripts, log files, etc) and will be useful for a lot of things going forward, so keep this one in your back pocket.
