So far, I haven't had any issues with delay. At the moment, my emulator works with TS-DOS up until it starts reading data from DOS100.CO (because I haven't implemented that part yet!). I did notice that it sends multiple requests one after another, which will require me to revise my command buffer routine.
I'm doing all of my testing using a real Model 100 and a MAX3232 converter, so I should see any issues if they arise. Jimmy. On Wed, Jul 18, 2018, 10:17 Kurt McCullum <ku...@fastmail.com> wrote: > The TS-DOS delay issue will be your biggest problem. For testing, you may > want to load the TS-DOS or SARDOS ROM that I put together than has more > delay built in. By default, TS-DOS waits for 3ms before if tries to switch > down to 9600 baud. It's all part of the directory support that was added > for DeskLink. When I was playing around with Bluetooth connections I had to > tweak TS-DOS to wait a little longer for a response. Even some Android > devices have slow USB response time. A USB device emulating a true serial > port is going to have some lag and unfortunately there is no way to know > how much lag. But 3ms is a tiny window to get a response back to > TS-DOS. The ROM images are in the members file area. These have added delay > and I bypass the code that switches the baud rate down to 9600 for a > re-check. > > > http://www.club100.org/memfiles/index.php?&direction=0&order=&directory=Kurt > McCullum/TS-DOS With Added Delay > > http://www.club100.org/memfiles/index.php?&direction=0&order=&directory=Kurt > McCullum/SARDOS > > > Using TEENY, which has no delay issue, may be a good place to start. > > Keep us posted. > > Kurt > > > > On Tue, Jul 17, 2018, at 6:28 PM, c646581 wrote: > > I found the page on the wiki explaining DCD/DSR along with the other flow > control quirks. Once I corrected that, it started behaving correctly. > > I'll look into that TPDD Arduino project, since that happens to be the > same platform I'm using for my emulator. It kind of feels like I'm > re-inventing the wheel, but there are some features I'd like to add to my > emulator that that project lacks. > > Thanks for all of the extra info! I shouldn't have as much > reverse-engineering to do now. > > On Tue, Jul 17, 2018, 20:54 Kurt McCullum <ku...@fastmail.com> wrote: > > > Sorry guys, but I'm jumping up on the soap box for this one. I'm quite > stunned by this email. > > First, there is the official protocol put out by Tandy "Software Manual > For Portable Disk Drive" 26-3808 > http://manx-docs.org/mirror/harte/Radio%20Shack/TRS-80%20Model%20100%20Portable%20Disk.pdf > There is a full writeup on bitchin100.com > http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol > And if that's not enough there is the TPDD2 sector access protocol writeup > www.club100.org/memfiles/index.php?action=downloadfile&filename=TPDD2-Sector%20Access.txt&directory=Kurt%20McCullum/TPDD%20Client& > > To suggest that somehow those of us who have created TPDD emulators are > somehow hiding that information is silly. Ken and John have done a huge > amount of work and documentation and that has been for the 'benefit' of the > Model-T community. LaddieAlpha/mComm/Desklink and more are freely available > for the 'benefit' of the Model-T community. If others want to create a low > cost TPDD emulator, I'm all for it. > > We are not hiding any secrets here. Stepping down from the soap box now. > > Kurt > > > On Tue, Jul 17, 2018, at 4:37 PM, John Gardner wrote: > > How about those who've benefited from the research of others, > > or even the researchers themselves, publishing the protocol? > > Nah... "8) > > > >
