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.