On Thu, Jun 30, 2016 at 12:51 PM, Kurt McCullum <[email protected]> wrote:
> Steve, > All my testing was done with hardware flow control on so I'll have to go > back and hard wire the flow control lines to know for sure. I agree that > 128bytes shouldn't be a problem. I think the serial buffer is 256 bytes but > I may be wrong on that. I never had a problem with the connection once I > got TS-DOS slowed down. Sadly I never got Sardine to work properly. Those > packets are 264 bytes (256 dictionary track + 8 for sector info) but I > suspect there was another timing loop that was causing the problem rather > than the packet size. > > Kurt > > Yeah TS-DOS only uses DSR/DTR for cable detect, never RTS/CTS. The problems between TS-DOS and Bluetooth or in some cases even wired serial is timeouts. TS-DOS makes requests and sometimes expects a response from the disk service sooner than it appears and it goes into its error mode. With Bluetooth, socat, or to a lesser extend USB Serial the link and protocol layer can insert enough delay to violate TS-DOS expectations. Don't know about SARDINE. I wonder how hard it would be to modify it to use the SEEK extension Ken and I came up with as an alternative for random access binary images. Instead of emulating the native TPDD-1 sector access it extends TPDD-2 file access with a random access SEEK command. So you can just use a regular file as your "image." Using the SEEK extension instead you would be at 128 byte packets. -- John.
