1/20/2019

DVD packet attachement communications (ATA over IDE)

CDROM and Tape drives were common devices added to the IDE bus. Floppy Disk drives like the LSI optical laser guided floppy disk also made their way to the IDE bus.

The IDE bus was essentially "like" the SATA bus except it was "Parallel" and based upon treating the device as a "Logic Chip" with an established procedure to "signal" to the CPU or other chips on the bus that a "Parallel" byte or word was ready to be read on the IDE bus.

For the "controlling" or (host) device in the communication it would take control of the data lines and set their "state" to represent the data byte or data word it wanted to "send", it would then use a control line on the bus to signal "ready".

For the "device" or (client) device in the communications it would passively "read" the state of the data lines to determine the byte or word and copy that to its local memory space then raise another signal line on the bus to signal "done" or "transmission complete".

In this ratchety, lock step manner, bytes could be copied from host memory to device memory and byte "flipping" who was the (host) and the (client) data could be sent back. This procedure was ironically also called "Clocking" the data into and out of a device since it was assumed the devices on either side of the bus shared an asynchronous "clock" with wide enough "gaps" between communciations and running at approximately the same speed to not corrupt the data in transmission.

The contents of the bytes and what to do with them were "encoded" within as a kind of "data control language" and would indicate "where" to store the data on a disk for example, or ask for data at a specific location on a disk to be retrieved.

The first "data control language" was very simple, it was that used to control a hard disk.

Extending the "data control language" was known as "the Packet language" and consisted of an abreviated subset of the SCSI bus data control language. Just enough to communicate with a limited number of additional device types like the CDROM, Tape drives and Floppy Drives for IDE and later the DVDROM reader and burner.

Today it lives on in SATA form for controlling Blu-Ray multilayer optical disc reader and burners.

After an initial technical working group established the format for ATA communications, additional device manufacturers would come together and write "Specifications" for the control language which would control their devices over the IDE/EIDE/ATA data channel irrespective of the hardware specifications for the actual physical bus and connectors.

"Specification language" is hard to read. It rarely includes "examples" of what is actually being discussed. In part because at the time of the "Spec document writing" no real world example exist as a product.. so they can appear necessarily "vague" and un-tethered from "reality" once actual products come on the market.. at best.. they are "first approximations" or "guesses" as to how something "will work" regardless of the intentions of the document to specify "how they should work correctly".

Sometimes "Patent" filings reveal how a particular manufacturer "intends" to implement an actual working product based on their  interpretation of the Specification. However its more common to keep these as obscure trade secrets.

"FCC" filings sometimes provides a little more detail, but not much as the applicant can request certain details be removed from the public record.





1/07/2019

IDE interface for microcontrollers

IDE or EIDE is a hard drive via host controller interface generally used for connecting hard drive, cdrom drives and tape or floppy drives to an IBM style PC. Its kind of well documented but not succinctly. 

It emerged as a replacement for the ST506 or Shugart Technologies MFM drive and controller combination. Shugart was known for developing the 5 1/4 inch floppy disks of the 1980s among other things.

The idea for the interface was to "offload" the mangement of positioning the heads and control of the reading of the disk as much as possible to a microcontroller onboard a seperate "controller" for the hard drive.

To the PC however this is presented as a device connected to the 8 bit ISA bus.

The 8 bit ISA bus was capable of transmitting 16 bits at a time, but for early equipment 8 bits was the maximum. Address and decoder logic circuits to actuate and pulse control lines would indicate to the connected HDD controller when commands were ready on the bus to be read, and whether the PC were ready or had finished offloading data from the HDD controller memory "buffer". and into the PC memory. Write to the HDD wass accomplished much the same way by "presenting" data on the bus, and then pulsing or actuating control lines to indicate to the microprocessor on the HDD controller card that data was ready to be read.

Initially the PC understood or had to make it requests assuming the HDD were made of Cylinders, Heads and Sectors.. corresponding to the location of "blocks" of data of approximately 512 bytes of data per block. Due to the size of the data types used to access the HDD by the 8 bit (and later 16 bit) BIOS, limits on the Total size of "addressable" storage on HDD were imposed.

Physically however HDD had limits on the actual number of Heads in a drive, but the data type for this number was confiscated and reused as a "general" variable for a virtual drive with many more heads than physically possible. The HDD controller then could translate that into a method for accessing larger and larger HDD storage capacity. But to get away from proprietary "translations" it became common place to begin using all of the CHS "bit space" to represent a linear 24 bit adress call a "Logical Block Address" or LBA. Later LBA technology would get an upgrade to LBA-48 to access even more storage.

To a PC it has been said the HDD "looks like a chip" attached to its mini-ISA or IDE bus. It communicates to this "chip" using memory and address and control lines.

The speed at which the PC communicates when reading or writing data is an interpretation of the result of sending commands, waiting for the HDD to raise a "ready" line and then offloading that data into its memory. And vice versa for writing.

HDD limitations due to "seeking" or "retries" of sectors are hidden or delt with by the HDD controller but can be reported to the PC if queried.

PC limitations due to "calculation" time for locating a file in a virtual file system that exists as a consequence of storing a pattern on the hard drive with an indexing system are hidden or delt with by the PC.. but do add to time required to retrieve or write data.

A simple microcontroller that wishes to access an IDE hard drive merely needs to have enough 5 volt buffered ISA lines corresponding to the subset of the ISA bus lines that define an IDE interface.

Many microprocessors today have only 3.3 volt I/O lines, and these must be protected or buffered by sufficient interface circuits or buffer chips.

The protocol for actuating control lines and presenting data to an IDE connected drive are documented by timing diagrams, but in general PIO - Programmed Input Output access mode is under the control and speed of the host microprocessor.

Microprocessors with custom peripherals or FPGA defined co-controllers to offload the task of communicating over a built-in IDE interface were more common at one time from Freescale.. but have passed mostly into history. Today discrete chips to create a supporting IDE interface are less common but can still be done.. though SPI and software defined FPGA circuts to provide that function are becoming more common.

Its quite common in fact to redefine the IDE bus as a chip function as part of of a more general purpose USB attached peripheral, and that as a SATA device and then attach a SATA to IDE interface to complete the connection.

This minimizes the electrical demands and potential incompatibilites of custom designed circuits.