There's a Linux program called sniffer or snooper. It acts as a man in the middle. You need a computer with two serial ports. They can be USB serial ports. It works well and will show the packets interleaved properly.
-- John. On Monday, May 30, 2016, Gary Hammond <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> on > behalf of Ken Pettit <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Reply-To: *Model 100 Discussion <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Date: *Tuesday, 31 May 2016 at 4:31 AM > *To: *Model 100 Discussion <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] *On > Behalf Of *Gary Hammond > *Sent:* Monday, 30 May 2016 8:11 PM > *To:* 'Model 100 Discussion' <[email protected]> > <javascript:_e(%7B%7D,'cvml','[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? > > >
