John,
I'm not sure about the service side. But by cutting part of the baud
rate routine out, two things happen. First, there are fewer calls that
require delays. I think the number is 4 but I'll have to count. So
instead of having 9 delay calls you have 4 or 5. That's significant
because the delay routine has to be increased to 20ms instead of 3ms.
The second benefit is that it CAN'T auto baud down to 9600. This works
for anything except a Brother drive that runs at 9600. But if you are
running that drive, you have no need for these changes.
Doing some math, the original TS-DOS routine takes under 30ms to test
the drive and pull the current directory. Just adding a longer delay
puts that delay at 1.8 seconds. Cutting part of the baud rate config out
drops it down to less than a second. About 3 times longer than the original.
I found the address for all the changes that need to be made to the
100/200/NEC TS-DOS roms. I'll put the patches in place and see what
happens. The one unknown is how various Bluetooth devices effect the
delay. Some may be more prone to lag than others.
As a side note, Virtual-T has a problem with the NEC 8201 and 8300. I
can't get TS-DOS to write to a real serial port. TELCOM works but for
some reason TS-DOS is a no go. It works with the 100/102 and 200 though.
Kurt
On 4/17/2016 9:46 AM, John R. Hogerhuis wrote:
Do you think there's anything that could be done on the service side
to keep it from autobauding down or when it does to recover quickly?
Good sleuthing!
-- John.
