The protocol appears to be using the TPDD2 sector access (I say appears
because I have never seen any TPDD2 protocol information until now), and
interestingly it is using a "ZZ0" packet header write at the end of each
block of "ZZ1" header packets. Not sure what that is about.
The "ZZ1C" seeems to be the sector write packet header with 3 byte
following it to indicate the sector relative to the previous "ZZ1" 07 01
... packet, followed by 64 bytes of data and a checksum.
ZZ1C 00 00 00 ....
ZZ1C 00 00 40 ....
ZZ1C 00 00 80 ....
ZZ1C 00 00 C0 ....
ZZ1C 00 01 00 ....
ZZ1C 00 01 40 ....
etc.
That pattern is repeated for each ZZ1 07 01 ... packet. Not sure yet
what ZZ1 07 01 ... packet is because ZZ1 07 00 is normally "Report Drive
status".
Ken
On 5/30/16 1:10 AM, Gary Hammond wrote:
Hi All,
I have captured the communications between the Model 100 and the TPDD2
during the creation of a TPDD2 boot disk.
The capture file is at
http://trs80stuff.net/tpdd/tpdd2-boot-disk-create.txt
Com5 is Model 100 -> TPDD2
Com6 is TPDD2 -> Model 100
Time stamps are accurate as they are recorded on the same PC.
The capture is the writing to the TPDD2. The reading of the original
boot disk process is not required as the necessary data to write a new
disk is in the capture. If we can convert it to code (a project for
when I am a little less busy), it will need to be assumed that the
disk has already been formatted.
As the sequencing and timing is all in place, the right sort of Python
script could read the capture file directly and generate the
appropriate commands/data and know what to expect back from the TPDD2
and in what time frames.
Enjoy!
Ps. Maybe this could be hosted somewhere on the bitchin100 wiki?
