I don't know if either the drive or ts-dos are checking for overall connected/ready at all times including while (all during) processing a packet, but they aren't used for ordinary flow control.
But they are used for device-connected-and-ready, which on the TS-DOS side prevents TS-DOS from hanging, and on the TPDD side is used to detect bootstrap conditions. It depends what you mean by what you "should do". If you are ok with just getting the basic traffic working to send a file, then you can just fake everything. You lose nothing in the way of overrun protection, because there already isn't any anyway. That is taken care of by brute force, by the fixed max packet size and the send/ack nature of the protocol. But if you want full most-correct operation, where TS-DOS can gracefully detect the drive is not ready, and the drive can detect that BASIC actually has the port open and listening and ready to receive data, and will only send the bootstrap when it should and not when you didn't intend, connect dsr/dtr between devices. On Fri, Jan 8, 2021, 11:03 PM Stephen Adolph <[email protected]> wrote: > They aren't used dynamically though are they? The protocol itself takes > care of flow. > > I'm unable to have a real m100 talk via serial with VT. That seems odd. > Must be a hardware pin issue. > > Interestingly the same hardware works if VT is swapped for teraterm. > > So I guess that virtualT must be flowing off while teraterm is flowing > on.... > > > > > On Friday, January 8, 2021, Brian White <[email protected]> wrote: > >> Ideally dsr/dtr should actually be connected since they are actually >> used, by both TS-DOS and the drive. >> >> On Fri, Jan 8, 2021, 8:47 PM Stephen Adolph <[email protected]> wrote: >> >>> at the end of the day, for TPDD access, seems that all hardware flow >>> control should be disabled in all directions. >>> >>> so at each end of a cable >>> RTS=CTS >>> DTR=DSR >>> >>> is this the right way to think of it? >>> >>> >>> >>> >>> On Fri, Jan 8, 2021 at 7:38 PM Stephen Adolph <[email protected]> >>> wrote: >>> >>>> I did see that and tried it. no luck so far but I will keep plugging >>>> away. I seem to recall this worked for me in the past. >>>> >>>> What I am trying to do is drive a real TPDD in FDC mode, and use VT to >>>> observe the transactions. >>>> >>>> >>>> On Fri, Jan 8, 2021 at 7:23 PM Ken Pettit <[email protected]> wrote: >>>> >>>>> Hardware flow control? I think VT has a checkbox to ignore CTS / >>>>> RTS. >>>>> Did you try that? >>>>> >>>>> Ken >>>>> >>>>> On 1/8/21 4:19 PM, Stephen Adolph wrote: >>>>> > Hey Folks, >>>>> > I'm having some trouble getting bi-directional serial port working >>>>> on >>>>> > virtualT. >>>>> > >>>>> > * Windows 10 >>>>> > * VT 1.7 (and also tried 1.6) >>>>> > * using a real serial port COM 1, or also COM2 FTDI USB serial port >>>>> > * Model T connected to COM1. >>>>> > >>>>> > I can send out from VirtualT no problem, but nothing seems to flow >>>>> in >>>>> > the return direction. >>>>> > >>>>> > I thought this worked.. struggling to understand why it is jammed up. >>>>> > >>>>> > On the same physical setup, if I kill VirtualT and start TeraTerm >>>>> > instead, it works bi-directionally no problem. >>>>> > >>>>> > I may try Linux next. >>>>> > >>>>> > thx >>>>> > Steve >>>>> >>>>>
