TPDD-2 Sector Access Protocol

From Bitchin100 DocGarden
Jump to: navigation, search

Overview

The TPDD-2 drive protocol has been documented to varying degrees of completeness and accuracy over the years. The intent of this document is to (when complete) provide a more complete picture than what has come before, including documentation of the TPDD-2 Sector Access protocol, which to my knowledge has never been completed or has not been made generally available.
At present, it just has some notes on my present project of reverse engineering the TPDD-2 Sector Access Protocol.

Terminology

(TBD) Client
Request
Response
Cache
Buffer
Load
Save
Read
Write
Track
Sector

Protocol Structure

Request Format

All requests consist of a Preamble of ZZ (5Ah 5Ah), followed by a Request ID byte, a Payload Length byte, 0 or more payload bytes, terminated by a checksum.
When values are listed with no explicit radix, you can assume hexadecimal.

Response Format

Reponse format is identical to the request format, except that no preamble is sent.

Sector Access Commands

History

The sector access command set was introduced with the TPDD-2. The TPDD-1 had an alternative "FDC Emulation" mode which offered direct sector access. The TPDD-2 integrated this functionality into the "Operation Mode" command set, and apparently removed the FDC Emulation mode altogether.
The structure of this command was inferred using a HP 4951B Protocol Analyzer. The subject of analysis included BACKUP.BA, as well as monitoring TD2MON.BA by Phil Wheeler. Neither BACKUP.BA nor TD2MON.BA actually use the sector access commands directly, but instead depend upon FLOPPY from the TPDD-2 Utility Disk.

Disk Layout

A TPDD-2 disk is comprised of 80 tracks, numbered 0 through 79. Each track has two sectors. Each sector holds 1,280 bytes.

Load Sector Request (LSReq)

Preamble Request ID Payload Length Payload Checksum
5A 5A 30 05
Rsvd A Track Rsvd B Sector
00 00 00-4F 00 00 or 01
Checksum


Load Sector seeks the drive head to the requested track, and loads the contents of the requested sector into the disk drive's sector RAM cache.
The purpose of "Rsvd A" and "Rsvd B" are unknown at this time.
It is possible that these were reserved for extending the number of tracks and sectors in a future product.
It is conceivable that the drive permits multiple sector buffers. Either Rsvd A (which may in fact be two different fields) or Rsvd B could serve this purpose. More experimentation is warranted.

Load Sector Response (LSResp)

Response ID Payload Length Payload Checksum
38 01
Response Code
00 => Success
Checksum

Read Fragment Request (RFReq)

Preamble Request ID Payload Length Payload Checksum
5A 5A 32 04
Rsvd A Offset Length
00 0000-04C0 00-??
Checksum

Whereas "Load Sector" causes a sector of the disk to be loaded into the TPDD-2's cache, Read Fragment transfers a fragment of the loaded sector to the client. The largest read I have seen specified a /RFReq/Payload/Length of 0x40. I suspect larger reads could be done, which would presumably speed things up a bit.

Read Fragment Response (RFResp)

Response ID Payload Length Payload Checksum
39 /RFReq/Payload/Length 3
Rsvd A Offset Data
/RFReq/Payload/Rsvd A /RFReq/Payload/Offset /RFReq/Payload/Length bytes of data
Checksum

Write Sector Data

(more research needed)

Checksum Algorithm

Total = Sum of all bytes from TypeID..Last byte of Payload
Checksum = (Total & FFh) XOR FFh