Good point Ken. I was watching the logs when the capture occurred and the response coming back from the TPDD2 were ‘bursty’ in nature i.e., as per the logs. This could be an artefact of buffering of the data on the PC side. Something to have a look at and see if there are any buffer size/timeout options in the capture app.
I have had to combine the output of 2 separate logs from 2 instances of the capture app running at the same time as I haven’t figured out how to get the capture app to combine them into a single capture. From: M100 <[email protected]> on behalf of Ken Pettit <[email protected]> Reply-To: Model 100 Discussion <[email protected]> Date: Tuesday, 31 May 2016 at 4:31 AM To: Model 100 Discussion <[email protected]> Subject: Re: [M100] Comms capture of TPDD2 boot disk creation While the timestamps may be accurate, the listing doesn't actually show proper protocol packet interleaving between the two ports. The 2nd COM5 block shows 23 "ZZ1" protocol packet headers with no interleaved ACK packets, and the following COM6 block shows 23 ACK packets with no interleaved "ZZ1" protocol packet headers. It is easy enough to figure out that these two are actually interleaved in time, but just wanted to point this out to anyone looking through the file. Ken On 5/30/16 1:15 AM, Gary Hammond wrote: If you are trying to work out the command structure, it might help to know that when the disk is being written, the backup utility shows it is writing from track 13 to track 0. From: M100 [mailto:[email protected]] On Behalf Of Gary Hammond Sent: Monday, 30 May 2016 8:11 PM To: 'Model 100 Discussion' <[email protected]> Subject: [M100] Comms capture of TPDD2 boot disk creation 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?
