Thanks Rich! We’re making some
progress! I added a couple of columns to the wiki page for devices that
pass TP-IDE and those that are CBIOS compatible. It is likely we’ll
have some devices which identify themselves properly but will require a CHS
CBIOS to use.
That error you are seeing in PIP is
suspicious. Why is it returning a corrupted file name? It may be a
CBIOS bug or something else entirely.
You may want to try using SAVE and/or
XMODEM to create files on the devices and see if that works. Also, do you
have the ECB bus monitor on the bus at the same time as the Disk IO board?
I wonder if that could be causing interactions.
The other idea Max mentioned is that maybe
/RD and/or /WR needs to be qualified for timing purposes. There are /IOR
and /IOW present on the Disk IO if they are needed. You can jumper them
from the 74LS32 that is feeding the i8272 (IC12). If this is related to a
timing issue qualifying /RD /WR with /IORQ may be enough of an improvement to
fix it.
6.3.6
DIOR- (Drive I/O read)
This is the Read strobe signal. The falling edge of DIOR- enables data from
a register or the data port of the drive onto the host data bus, DD0-DD7 or
DD0-DD15. The rising edge of DIOR- latches data at the host.
6.3.7 DIOW-
(Drive I/O write)
This is the Write strobe signal. The rising edge of DIOW- clocks data from
the host data bus, DD0-DD7 or DD0-DD15, into a register or the data port of
the drive.
I hope this helps! Thanks and have a
nice day!
Andrew Lynch
From: n8...@googlegroups.com [mailto:n8...@googlegroups.com] On Behalf Of Richard A. Cini
Sent: Tuesday, February 10, 2009
9:25 PM
To: N8VEM-Post
Subject: [N8VEM: 2491] Disk-I/O --
Tonight's Testing Progress
All:
Here’s my book report from tonight:
* I lifted the legs of R1 – R3
closest to the IDE connector and connected the flying lead of R3 to Vcc rather
than ground, resulting
in a
pull-up on /DMACK rather than a pull-down. The other resistors were left
floating.
* Re-enabled the IDE_RESET code in the
monitor ROM.
With a drive connected, it doesn’t delay boot-up by much and I thought
that
not resetting the drive might have something to do with the issues we’re
experiencing.
* Tried the interface with four drives I
have handy: Toshiba MK1403MAV (2.5”), CF->IDE adapter plus 1gb CF
card, WD AC11200,
and a
Quantum Fireball (HP-issued 2.55gb).
Both the WD and the Quantum drives failed the TP-IDE
test. The CF adapter and the Toshiba drive almost work. They identify
themselves properly (ID string appears in the buffer in RAM), but when
attempting to use PIP, I get the same error as last night (“Cannot close
file...device R/O”).
I just noticed that the device it reports as having the
error is “=A:tp-ide.com”. I’m trying to PIP from the RAM
drive to the C: drive — this should work. After the transfer (even though
it fails), the directory entry on C: for the program that was to be transferred
is garbled but can be restored with a wildcard erase.
I just checked UPS and I expect to have the Seagate
drive that matches the prototype tomorrow so I’ll give it a whirl and see
what happens.
More tomorrow...
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.altair32.com
http://www.classiccmp.org/cini