[M100] Associated Press Option ROM

[Wayne Lorentz]

Here’s what was may have been in the Option ROM socket:

http://wayne.lorentz.me/computers/trs-80/this_trs-80/ 


There were other systems available, but the AP one was the most popular.  I 
dated a newspaper reporter from your region (different paper, though), and she 
used a BaSys system at work, which I believe had some kind of M100 interface.

Unfortunately, the name “BaSys” has been used multiple times by multiple 
companies, so an internet search has been worthless.

> On Sep 20, 2022, at 3:03 PM, m100-requ...@lists.bitchin100.com wrote:
> 
> All 3 were used at 'The Record', a newspaper in Hackensack New Jersey. I 
> purchased them from ebay many years ago as 'not working'. I thought they 
> would be great projects. But when I took out the old crusty batteries, 
> cleaned the contacts, and put new batteries in, they all worked! The 
> keyboards feel a little soft to me. I think I removed dental rings from the 
> keyboard on at least one of them, wish I had left it alone now. Nothing was 
> in the Option ROM sockets on any of these machines.

Re: [M100] Questions about tokenizing BASIC in UNIX

[Stephen Adolph]

you are right,  that never really got sorted out.  Would be good to pick
that up again, and try to sort out, using low cost components, how to make
that work.

On Fri, Sep 23, 2022 at 2:00 PM Mike Stein  wrote:

> When Steve and I were playing with M100 to M100 communication over the
> internet way back when, he spent a fair bit of time trying to overcome the
> small buffer in the Model Ts but I don't think he could ever get it to work
> 100%. IIRC reducing the buffer size in the ethernet 'modem' down to one did
> solve the problem but wasn't an option with all versions of the adapters.
>
> m
>
> On Fri, Sep 23, 2022 at 1:09 PM John R. Hogerhuis 
> wrote:
>
>>
>>
>> On Fri, Sep 23, 2022 at 2:59 AM Brian White  wrote:
>>
>>>
>>> I believe all the right chip does is help, and make more code more
>>> likely to make it through
>>>
>>
>> Chip/driver wise the two things I've observed:
>>
>> You can configure the FTDI driver buffering threshold on Windows all the
>> way down to 1 byte, which I think is what we want. This is really about
>> decreasing transmit latency on the Windows side in case of a sensitive
>> receiver on the Model T side... that is, TS-DOS.
>> The prolific drive has bugs under the Windows API, last I checked. There
>> is a facility under Win32 and the .Net Framework for reading a block of
>> data with a timeout. It works with the FTDI, it doesn't work with Prolific.
>> I believe it is a driver issue. I can work around it in software, and have,
>> but just generally spec it out of commercial projects because it is not
>> correct.
>>
>> On Linux, I've never really noticed a difference between Prolific and
>> FTDI. But my experience is the same as yours, that software flow
>> control does not work with our laptop. Linux is too slow to react to a
>> flow-off presumably since it is in-band in the data and gets buffered, and
>> overwhelms the tiny 64-byte, interrupt driven receive buffer on the Model
>> T. And as Mike mentions, USB, Wifi-Serial add create even more overhead and
>> burstiness.
>>
>> I could imagine some low level hardware scheme (specific
>> hardware+driver+configuration) overcoming the buffering of XON/XOFF
>> specifically, in the wired case... but this is the first I've heard of it.
>> And it really seems like it would have to be configured. Hardware isn't
>> normally involved in software flow control.
>>
>> -- John.
>>
>

Re: [M100] Questions about tokenizing BASIC in UNIX

[Mike Stein]

When Steve and I were playing with M100 to M100 communication over the
internet way back when, he spent a fair bit of time trying to overcome the
small buffer in the Model Ts but I don't think he could ever get it to work
100%. IIRC reducing the buffer size in the ethernet 'modem' down to one did
solve the problem but wasn't an option with all versions of the adapters.

m

On Fri, Sep 23, 2022 at 1:09 PM John R. Hogerhuis  wrote:

>
>
> On Fri, Sep 23, 2022 at 2:59 AM Brian White  wrote:
>
>>
>> I believe all the right chip does is help, and make more code more likely
>> to make it through
>>
>
> Chip/driver wise the two things I've observed:
>
> You can configure the FTDI driver buffering threshold on Windows all the
> way down to 1 byte, which I think is what we want. This is really about
> decreasing transmit latency on the Windows side in case of a sensitive
> receiver on the Model T side... that is, TS-DOS.
> The prolific drive has bugs under the Windows API, last I checked. There
> is a facility under Win32 and the .Net Framework for reading a block of
> data with a timeout. It works with the FTDI, it doesn't work with Prolific.
> I believe it is a driver issue. I can work around it in software, and have,
> but just generally spec it out of commercial projects because it is not
> correct.
>
> On Linux, I've never really noticed a difference between Prolific and
> FTDI. But my experience is the same as yours, that software flow
> control does not work with our laptop. Linux is too slow to react to a
> flow-off presumably since it is in-band in the data and gets buffered, and
> overwhelms the tiny 64-byte, interrupt driven receive buffer on the Model
> T. And as Mike mentions, USB, Wifi-Serial add create even more overhead and
> burstiness.
>
> I could imagine some low level hardware scheme (specific
> hardware+driver+configuration) overcoming the buffering of XON/XOFF
> specifically, in the wired case... but this is the first I've heard of it.
> And it really seems like it would have to be configured. Hardware isn't
> normally involved in software flow control.
>
> -- John.
>

Re: [M100] Questions about tokenizing BASIC in UNIX

[John R. Hogerhuis]

On Fri, Sep 23, 2022 at 2:59 AM Brian White  wrote:

>
> I believe all the right chip does is help, and make more code more likely
> to make it through
>

Chip/driver wise the two things I've observed:

You can configure the FTDI driver buffering threshold on Windows all the
way down to 1 byte, which I think is what we want. This is really about
decreasing transmit latency on the Windows side in case of a sensitive
receiver on the Model T side... that is, TS-DOS.
The prolific drive has bugs under the Windows API, last I checked. There is
a facility under Win32 and the .Net Framework for reading a block of data
with a timeout. It works with the FTDI, it doesn't work with Prolific. I
believe it is a driver issue. I can work around it in software, and have,
but just generally spec it out of commercial projects because it is not
correct.

On Linux, I've never really noticed a difference between Prolific and FTDI.
But my experience is the same as yours, that software flow control does not
work with our laptop. Linux is too slow to react to a flow-off presumably
since it is in-band in the data and gets buffered, and overwhelms the tiny
64-byte, interrupt driven receive buffer on the Model T. And as Mike
mentions, USB, Wifi-Serial add create even more overhead and burstiness.

I could imagine some low level hardware scheme (specific
hardware+driver+configuration) overcoming the buffering of XON/XOFF
specifically, in the wired case... but this is the first I've heard of it.
And it really seems like it would have to be configured. Hardware isn't
normally involved in software flow control.

-- John.

Re: [M100] Questions about tokenizing BASIC in UNIX

[Mike Stein]

Terminal sessions aren't usually a problem unless you're sending a file to
the Model T; manual typing in either direction isn't likely to overrun a
buffer and whatever the T is connected to will probably be able to handle
the data stream.

Even receiving a file is usually not a problem if you're connected through
'real' RS232 ports unless the T has to scroll the screen; you may be able
to avoid that.

The main issue is when the T has to spend time processing the incoming data
somehow and it's in packets as it is when using a USB, BT or WiFi<>serial
converter; by the time the sending computer sees an XOFF there are probably
enough characters already on the way to overflow the buffer. Some drivers
have the option to set the packet length, which may solve the issue.

m

On Fri, Sep 23, 2022 at 11:47 AM Brian Brindle  wrote:

> One way under Linux I have gotten around the issues of software flow
> control is to use screen for my serial terminal sessions. It has software
> flow control support built in. A must if you want to use ssh or another app
> that doesn't play well with stty.
>
> Brian
>
>
> On Fri, Sep 23, 2022, 5:59 AM Brian White  wrote:
>
>> I don't believe this is enough to ensure clean data. I must have a dozen
>> real ftdi adapters from different manufacturers and I keep having to
>> increase the per-byte sleep in dlplus' bootstrapper and tsend.ps1 and
>> PDDuino as I discover new basic programs to feed in.
>>
>> Some programs will ingest fine at 5ms/byte, some will fail on some
>> particular part of one line, always the same spot, unless the sleep is
>> increased to 6ms.
>>
>> Then I discover some other code that fails at 6 but succeeds at 7.
>>
>> Some of the problem code I just found in the M100SIG, some were new
>> things like the REX setup utils, some I created the new problem by
>> refactoring existing tpdd client loaders to make them smaller. This made
>> them apparently more difficult to ingest, but they are still legal correct
>> BASIC, so any procedure needs to be able to handle the worst case or else
>> it's no good.
>>
>> For an example, one of the loaders I re-worked, used to work fine before,
>> and then the reworked version would always be missing a : in the middle of
>> one long line of code. Always the same byte missing. And it didn't cause
>> the transfer to fail immediately, it tokenized on the fly without apparent
>> error. But the program was broken and didn't work when you try to run it.
>>
>> This is all with real ftdi adapters and with xon/off enabled on both ends.
>>
>> It may work at 1200 or something where the low baud rate does the same
>> job as a sleep between bytes, but no way at 19200.
>>
>> I will put together a few test cases that expose the problem. And if this
>> method does somehow work then that would indeed be pretty interesting and
>> good to know.
>>
>> I believe all the right chip does is help, and make more code more likely
>> to make it through, but not actually guarantee it. It probably does make a
>> large improvement, and you can probably show numerous examples of data that
>> fails on one adapter and succeeds on an ftdi chip.
>>
>> --
>> bkw
>>
>> On Thu, Sep 22, 2022, 8:57 PM John R. Hogerhuis  wrote:
>>
>>>
>>>
>>> On Thu, Sep 22, 2022 at 5:32 PM B 9  wrote:
>>>

 Of particular note for troubleshooting is that, if some of the data
 gets transferred, but it is garbled or you get a ?DS ERROR, then the
 problem is that your PC's serial port does not support "ON CHIP SOFTWARE
 FLOW CONTROL".  One solution is to buy a serial card or USB cable with an
 FTDI chip in it. (Other companies make ICs that support on chip software
 flow control, I even have a cheap Prolific 2303 device that does, but FTDI
 is the only company I know of whose chips are supposed to always work. )


>>> I've never heard of this on-chip software flow control.All I knew was
>>> that software flow does not work under Linux. My experience is software
>>> flow control with a Model T *does* work on Windows.
>>>
>>> Is that something you have to enable? Seems awfully strange to have the
>>> chip interceding in-band. Automatic hardware flow control I have heard of.
>>>
>>> This failure on Linux is why I made HTERM to use hardware flow control
>>>
>>> If there's a consistent way to make it work on Linux, it would be good
>>> to know. Even just with FTDI chipset. Windows prolific drivers are trash. I
>>> don't know about Prolific on Linux.
>>>
>>> Is the stty command you put supposed to enable on-chip software flow
>>> control? Which part?
>>>
>>> *s**tty -F /dev/ttyUSB0 ixon ixoff  stop ^S start ^Q  -onlcr -icrnl
>>>  eof ^Z  19200*
>>>
>>> -- John.
>>>

Re: [M100] Questions about tokenizing BASIC in UNIX

[Brian Brindle]

One way under Linux I have gotten around the issues of software flow
control is to use screen for my serial terminal sessions. It has software
flow control support built in. A must if you want to use ssh or another app
that doesn't play well with stty.

Brian


On Fri, Sep 23, 2022, 5:59 AM Brian White  wrote:

> I don't believe this is enough to ensure clean data. I must have a dozen
> real ftdi adapters from different manufacturers and I keep having to
> increase the per-byte sleep in dlplus' bootstrapper and tsend.ps1 and
> PDDuino as I discover new basic programs to feed in.
>
> Some programs will ingest fine at 5ms/byte, some will fail on some
> particular part of one line, always the same spot, unless the sleep is
> increased to 6ms.
>
> Then I discover some other code that fails at 6 but succeeds at 7.
>
> Some of the problem code I just found in the M100SIG, some were new things
> like the REX setup utils, some I created the new problem by refactoring
> existing tpdd client loaders to make them smaller. This made them
> apparently more difficult to ingest, but they are still legal correct
> BASIC, so any procedure needs to be able to handle the worst case or else
> it's no good.
>
> For an example, one of the loaders I re-worked, used to work fine before,
> and then the reworked version would always be missing a : in the middle of
> one long line of code. Always the same byte missing. And it didn't cause
> the transfer to fail immediately, it tokenized on the fly without apparent
> error. But the program was broken and didn't work when you try to run it.
>
> This is all with real ftdi adapters and with xon/off enabled on both ends.
>
> It may work at 1200 or something where the low baud rate does the same job
> as a sleep between bytes, but no way at 19200.
>
> I will put together a few test cases that expose the problem. And if this
> method does somehow work then that would indeed be pretty interesting and
> good to know.
>
> I believe all the right chip does is help, and make more code more likely
> to make it through, but not actually guarantee it. It probably does make a
> large improvement, and you can probably show numerous examples of data that
> fails on one adapter and succeeds on an ftdi chip.
>
> --
> bkw
>
> On Thu, Sep 22, 2022, 8:57 PM John R. Hogerhuis  wrote:
>
>>
>>
>> On Thu, Sep 22, 2022 at 5:32 PM B 9  wrote:
>>
>>>
>>> Of particular note for troubleshooting is that, if some of the data gets
>>> transferred, but it is garbled or you get a ?DS ERROR, then the problem
>>> is that your PC's serial port does not support "ON CHIP SOFTWARE FLOW
>>> CONTROL".  One solution is to buy a serial card or USB cable with an FTDI
>>> chip in it. (Other companies make ICs that support on chip software flow
>>> control, I even have a cheap Prolific 2303 device that does, but FTDI is
>>> the only company I know of whose chips are supposed to always work. )
>>>
>>>
>> I've never heard of this on-chip software flow control.All I knew was
>> that software flow does not work under Linux. My experience is software
>> flow control with a Model T *does* work on Windows.
>>
>> Is that something you have to enable? Seems awfully strange to have the
>> chip interceding in-band. Automatic hardware flow control I have heard of.
>>
>> This failure on Linux is why I made HTERM to use hardware flow control
>>
>> If there's a consistent way to make it work on Linux, it would be good to
>> know. Even just with FTDI chipset. Windows prolific drivers are trash. I
>> don't know about Prolific on Linux.
>>
>> Is the stty command you put supposed to enable on-chip software flow
>> control? Which part?
>>
>> *s**tty -F /dev/ttyUSB0 ixon ixoff  stop ^S start ^Q  -onlcr -icrnl  eof
>> ^Z  19200*
>>
>> -- John.
>>
>>>

Re: [M100] Questions about tokenizing BASIC in UNIX

[Brian White]

I don't believe this is enough to ensure clean data. I must have a dozen
real ftdi adapters from different manufacturers and I keep having to
increase the per-byte sleep in dlplus' bootstrapper and tsend.ps1 and
PDDuino as I discover new basic programs to feed in.

Some programs will ingest fine at 5ms/byte, some will fail on some
particular part of one line, always the same spot, unless the sleep is
increased to 6ms.

Then I discover some other code that fails at 6 but succeeds at 7.

Some of the problem code I just found in the M100SIG, some were new things
like the REX setup utils, some I created the new problem by refactoring
existing tpdd client loaders to make them smaller. This made them
apparently more difficult to ingest, but they are still legal correct
BASIC, so any procedure needs to be able to handle the worst case or else
it's no good.

For an example, one of the loaders I re-worked, used to work fine before,
and then the reworked version would always be missing a : in the middle of
one long line of code. Always the same byte missing. And it didn't cause
the transfer to fail immediately, it tokenized on the fly without apparent
error. But the program was broken and didn't work when you try to run it.

This is all with real ftdi adapters and with xon/off enabled on both ends.

It may work at 1200 or something where the low baud rate does the same job
as a sleep between bytes, but no way at 19200.

I will put together a few test cases that expose the problem. And if this
method does somehow work then that would indeed be pretty interesting and
good to know.

I believe all the right chip does is help, and make more code more likely
to make it through, but not actually guarantee it. It probably does make a
large improvement, and you can probably show numerous examples of data that
fails on one adapter and succeeds on an ftdi chip.

-- 
bkw

On Thu, Sep 22, 2022, 8:57 PM John R. Hogerhuis  wrote:

>
>
> On Thu, Sep 22, 2022 at 5:32 PM B 9  wrote:
>
>>
>> Of particular note for troubleshooting is that, if some of the data gets
>> transferred, but it is garbled or you get a ?DS ERROR, then the problem
>> is that your PC's serial port does not support "ON CHIP SOFTWARE FLOW
>> CONTROL".  One solution is to buy a serial card or USB cable with an FTDI
>> chip in it. (Other companies make ICs that support on chip software flow
>> control, I even have a cheap Prolific 2303 device that does, but FTDI is
>> the only company I know of whose chips are supposed to always work. )
>>
>>
> I've never heard of this on-chip software flow control.All I knew was that
> software flow does not work under Linux. My experience is software flow
> control with a Model T *does* work on Windows.
>
> Is that something you have to enable? Seems awfully strange to have the
> chip interceding in-band. Automatic hardware flow control I have heard of.
>
> This failure on Linux is why I made HTERM to use hardware flow control
>
> If there's a consistent way to make it work on Linux, it would be good to
> know. Even just with FTDI chipset. Windows prolific drivers are trash. I
> don't know about Prolific on Linux.
>
> Is the stty command you put supposed to enable on-chip software flow
> control? Which part?
>
> *s**tty -F /dev/ttyUSB0 ixon ixoff  stop ^S start ^Q  -onlcr -icrnl  eof
> ^Z  19200*
>
> -- John.
>
>>