TPDD-2 Sector Access Protocol - Revision history

99.6.119.22: /* ReadÂ Fragment Request (RFReq) */

2009-02-20T15:48:17Z

ReadÂ Fragment Request (RFReq)

← Older revision		Revision as of 08:48, 20 February 2009
Line 75:		Line 75:
	\|}		\|}

	=== ~~ReadÂ~~ Fragment Request (RFReq) ===		=== Read Fragment Request (RFReq) ===

	{\| style="text-align: left; background-color: rgb(255, 255, 204); width: 100%; height: 113px" border="1" cellspacing="2" cellpadding="2"		{\| style="text-align: left; background-color: rgb(255, 255, 204); width: 100%; height: 113px" border="1" cellspacing="2" cellpadding="2"

99.6.119.22: /* Checksum Algorithm */

2009-02-20T15:46:51Z

Checksum Algorithm

← Older revision		Revision as of 08:46, 20 February 2009
Line 131:		Line 131:
	=== Checksum Algorithm ===		=== Checksum Algorithm ===

	Total = ~~SumÂ~~ of all bytes from TypeID..Last byte of Payload<br /> Checksum = (Total & FFh) XOR FFh		Total = Sum of all bytes from TypeID..Last byte of Payload<br /> Checksum = (Total & FFh) XOR FFh

	[[Category:Model T Developer Reference]]		[[Category:Model T Developer Reference]]

99.6.119.22: /* Read Fragment Response (RFResp) */

2009-02-20T15:46:34Z

Read Fragment Response (RFResp)

← Older revision		Revision as of 08:46, 20 February 2009
Line 120:		Line 120:
	\| /RFReq/Payload/Rsvd A		\| /RFReq/Payload/Rsvd A
	\| /RFReq/Payload/Offset		\| /RFReq/Payload/Offset
	\| /RFReq/Payload/Length Â bytes of data		\| /RFReq/Payload/Length bytes of data
	\|}		\|}
	\| Checksum		\| Checksum

99.6.119.22: /* History */

2009-02-20T15:45:08Z

History

← Older revision		Revision as of 08:45, 20 February 2009
Line 21:		Line 21:
	=== History ===		=== 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.<br /> 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 ~~doesn't~~ actually use the sector access commands directly, but instead depend upon FLOPPY from the TPDD-2 Utility Disk.<br />		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.<br /> 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.<br />

	=== Disk Layout ===		=== Disk Layout ===

99.6.119.22: New page: == 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 mo...

2009-02-20T15:44:20Z

New page: == 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 mo...

New page

== 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 doesn't 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) ===

{| style="text-align: left; background-color: rgb(255, 255, 204); width: 100%; height: 113px" border="1" cellspacing="2" cellpadding="2"
| Preamble
| Request ID
| Payload Length
| Payload
| Checksum
|-
| 5A 5A
| 30
| 05
|
{| style="text-align: left; width: 100%" border="1" frame="box" cellspacing="2" cellpadding="2" frame="box"
| 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) ===

{| style="text-align: left; background-color: rgb(255, 255, 204); width: 100%; height: 113px" border="1" cellspacing="2" cellpadding="2"
| Response ID
| Payload Length
| Payload
| Checksum
|-
| 38
| 01
|
{| style="text-align: left; width: 100%" border="1" frame="box" cellspacing="2" cellpadding="2" frame="box"
| Response Code
|-
| 00 => Success
|}
| Checksum
|}

=== ReadÂ Fragment Request (RFReq) ===

{| style="text-align: left; background-color: rgb(255, 255, 204); width: 100%; height: 113px" border="1" cellspacing="2" cellpadding="2"
| Preamble
| Request ID
| Payload Length
| Payload
| Checksum
|-
| 5A 5A
| 32
| 04
|
{| style="text-align: left; width: 100%" border="1" frame="box" cellspacing="2" cellpadding="2" frame="box"
| 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) ===

{| style="text-align: left; background-color: rgb(255, 255, 204); width: 100%; height: 113px" border="1" cellspacing="2" cellpadding="2"
| Response ID
| Payload Length
| Payload
| Checksum
|-
| 39
| /RFReq/Payload/Length 3
|
{| style="text-align: left; width: 100%" border="1" frame="box" cellspacing="2" cellpadding="2" frame="box"
| 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

[[Category:Model T Developer Reference]]