TI99: SCSI devices

From: Allison J Parent <allisonp_at_world.std.com>
Date: Tue Jan 5 21:45:42 1999

<<Brainstorming mode on:>
<Is IDE geared in any way to the MS-DOS filesystem?

No. It's a device level interconnect similar to SCSI or other busses.
In practice it's a 16bit data bus, several control lines and a few address
bits. It was a result of putting the early PCbus MFM(or rll) card in the
MFM hard disk to make it a single unit. The WD1003 MFM ISA16 (PC) bus
card is a very similar interface when viewed from the ISA16(PC AT and
later 386/486 sytems) bus. What IDE did was allowed the PC to offload one
board (Disk controller) onto the disk drive (IDE= Integral drive
electronics) and created a simple disk interface connector/cable that
was cheaper than SCSI but offered many similar features of SCSI interfaced
disks sans the greater cost.

The drive and it's IDE interface is a series of registers for parameters
and data transfer and it cares less what operating system is in effect.
About the only difficulty is interfacing the 16bit wide(for data, 8bit for
commands) bus to whatever the local CPU/BUS is in use. that logic is nearly
the reverse of the 99/4a 16bit->8bit for the PEB. One could do a kluge
and not use the high order bits as they are data only. However that means
the default 512byte sector size would only hold 256bytes of data (with large
drives dirt cheap this is not so bad!). I personally don't like that but
it'd work.

The interface is basically a series of registers that set up the transfer
with data like command, head, sector, cylinder and number of sectors
(transfer length). The interface does not have to keep up with the
physical media as even the smallest ones have a 32k (up to 512k) cache
ram on board so that if can feed data fast (or slow) as the host desires
it. Most of the 60-100meg and later drives (quantum is known for it)
have a LRU cache so that the drive can try to anticipate the next likely
sector to transfer to avoid rotational latentcy. While the drives are
hyped and speced for fast transfer rateds to their host system there is
no requirement to use that speed as there is no lower limit. Because of
the cache a polled interface is easy to do and there are no requirements
for critical fast loops to avoid loosing data.

I happen to use IDE with FreeBSD(on PC hardware) and also a Z80 CP/m system.
Both are about as unDOS as they can get.

DSR level issues are things like are there logical limits to how big a
TI99/4a file system can be. Also how does one write a DSR that uses any
one of several hundred differnt IDE drives of differnt sizes and
configurations? IE: 20mb as 4 heads 615 cylinders of 17 sectors or 306
cylinders and 8 heads? PCs (CP/M and others) have the idea of a bios that
translates differnt physical devices to look like one logical interface.
Sadly most DSRs were not written that way. Having a differnt DSR for a WD
240mb and a shugart 340mb would be a real problem. Also the older drives
are dumber and cannot tell the system what they are (configuration), the
later (mostly over 200mb) drives added that functionality. So there would
also have to be configuration tools and some amount of NVram(EEPROM) on the
board to allow for whatever drive was available from the older 40mb up to
the current 19gb drives. I'd point out that the drives in the 80-400mb
range seem to be more inconsistant than the larger ones. Also drives over
512mb have additional fuctionality so that they can be addressed as block
instead of cylinder, head, sector. So the driver (DSR)
has to be a bit smart so that it know what class of IDE drive and what
capabilities are available. That's a real tall order! So that is why I
say the physical interface is trivial compared to the DSR. It can be done
as many of the same problem occur with SCSI but the DSR will have a lot of
differences at the lower levels of code. Judging from the SCSI dificulties
reported here that wasn't easy either.

Allison
Received on Tue Jan 05 1999 - 21:45:42 GMT