You've summed it up very well indeed.
Putting it another way:
If the 'server' handles it correctly (and apparently some versions of Linux do
not) then the actual XON/XOFF protocol is completely reliable if you are
connected directly or through compatible modems. The receiving client sends an
XOFF (CTL-S, CHR$(19)) to signal that it needs time to process the received
data and the sending server immediately stops and waits for an XON (CTL-Q,
CHR$(17)) to start sending again.
Note that XON/XOFF is not just used for communication; many programs also use
it locally, e.g. to pause scrolling while listing a large file.
Hardware handshaking works the same way, but instead of sending handshaking
characters it uses additional wires in the connecting cable to send and receive
equivalent electrical signals. Unfortunately the M100 does not natively
implement hardware handshaking, although there are programs that do, such as
John H's Hterm
Problems can arise when the M100 with its puny 64 byte buffer is connected
through a USB<>RS232 adapter or an Ethernet or WiFi 'modem'; these devices send
data in packets of multiple bytes at a time and will finish sending the packet
before they acknowledges the XOFF and pause. Unless the packet size can be
adjusted to a small enough size (e.g. 1) then the M100's receive buffer will
probably overflow and drop characters by then.
As you say, some adapters/modems do work well if properly configured, while
others do not and you have to run at a baud rate low enough that the receiving
program can process the characters as they come.
Reliable maximum download speeds on the M100 without handshaking are around:
BASIC: 600 bd to allow time to tokenize and store.
TERM: 2400 because of the slow LCD scrolling.
TEXT: 9600 since it does not display while loading.
YMMV of course.
Myself, I play with a number of vintage systems and prefer to use 'real' RS232
ports whenever practical.
m
----- Original Message -----
From: B 9
To: m...@bitchin100.com
Sent: Monday, October 31, 2022 1:03 AM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up
appreciated
On Sun, Oct 30, 2022 at 7:16 PM Mike Stein <mhs.st...@gmail.com> wrote:
That's odd; can't your terminal program just wait forever for the next
dump? If it times out, can't you override that?
Sure, it's actually even easier to just let it all accumulate in one file. It
just hadn't occurred to me to do it that way.
It probably won't matter with a small file like this but I've found that at
19200 even TEXT has trouble keeping up when downloading. The M100 doesn't have
hardware handshaking and only has XON/XOFF, which is not always reliable.
I used to believe the same things about XON/XOFF: I derisively referred to it
as an unreliable protocol that should have died with disco. I never understood
how people could have used serial connections before hardware handshaking. (Nor
did I understand disco.)
It turns out, I was wrong. On my Tandy 200, what I've discovered is that
XON/XOFF is 100% reliable at 19200, if you've got a good serial card on your
PC. The key thing is that latency has to be very low. That means, either Ⓐ
disabling all buffers, including the FIFO buffer on the serial port, or Ⓑ,
which is preferable if your UART chips support doing so, enabling
hardware-level XON/XOFF. (The Linux kernel automatically sets this up for you
if your hardware can handle it; I presume other systems are similar.)
Ⓐ Back in the days of yore, when the Model T was current, serial cards had a
1-byte buffer, which meant every single byte caused a system interrupt. (!)
That meant, they actually had less latency relative to speed of filling the
output buffer than our fast, modern computers. I haven't had one to test, but I
believe old PCs with an 8250 UART would not overwhelm a Model T, even at
19,200. Nowadays, every serial card comes with a minimum of 16-bytes for the
FIFO and it is not always easy (or possible) to disable it.
Ⓑ Despite XON/XOFF being called "software flow control", many chips actually
offer hardware implementations so they can stop the flow of communication the
instant the Model 100 holds up its hand and says, “Whoa!” Without
hardware-level support, you have to wait for the XOFF (^S) character to go
through all the buffers on the PC and get processed before data stops getting
sent. By the time that happens, the buffer of data going to the Model 100,
which has been filling up at 19,200 bps, is now so large that it will overwhelm
the M100, causing data loss.
Some cheap USB Serial adapters do not offer on-chip XON/XOFF and they are
unreliable at high-speeds. What serial card / USB adapter are you using? I
know the 16950 UART has on-chip xon/xoff, as do most (all?) FTDI chips.
ProLific's PL2303 *sometimes* has support, but they rarely label it on the box
so it's hard to know before you buy an adapter.
—b9
When uploading/saving from BASIC there doesn't seem to be much difference
between 9600 and 19200, since it has to detokenize as it goes. Try it and see
how it goes at 19200; TELCOM and text would probably be a little faster.
I've added an option to send the dump output to the com port; that seems to
work fine at 19200.
BTW, I don't think we'll do much better than 34 seconds/50 lines; as I
mentioned, LCD performance is pretty bad, especially scrolling.
For comparison, outputting to the com port halves the time to 17 seconds,
and of course you can scroll, save and print that on your PC as well.
m
On Sun, Oct 30, 2022 at 9:54 PM B 9 <hacke...@gmail.com> wrote:
That sounds like a nice workflow. This ought to be in a FAQ of tips and
hints for people new to the M100.
I might just try it out. I'm pretty rigorous about using SAVE
"COM:98N1ENN", but I have to tell my Unix box to receive the file each time (cp
/dev/ttyUSB0 foo.do). And every copy I save overwrites the previous one, unlike
the natural history you'll have in your log file if you find you need to go
back a few revisions.
One question though: why do you send at 9600 bps? I thought all Model T's
could do 19,200bps.
—b9
On Sat, Oct 29, 2022 at 10:26 AM MikeS <dm...@torfree.net> wrote:
Hi Will,
Too many times I've made some changes and either accidentally deleted
the file or messed it up so badly that I want to revert to the previous
version, so I've learned the hard way that it's a good idea to save the work
before making major changes.
One way is to SAVE it locally on the M100 as a .DO file ("Foo.do" or
"Foo",A) , changing the name as appropriate; note that BASIC will save a file
as .BA by default but will LOAD a .DO file without specifying the '.DO' or ',A'
if no .BA file with the same file exists. Of course if it's a very large file
you may not have room for both the .BA and .DO files in RAM at the same time.
What I do if I'm close enough to a PC to easily connect or stay
connected is to open a file (e.g. "backup.txt") on the PC for ASCII text
download with a terminal program and just leave it open.
On the M100 I've programmed F7 to 'Key 7, "COM:88N1E"', so when I want
to save the file I'm working on I press F3 to save, F7 in response to 'Save "'
and Return. It's a good idea to embed a version no. in the program and update
it every time.
This concatenates all the saved files in one file; if you actually need
to go back then you'd have to stop the transfer, edit the file on the PC and
send it back to the M100. Of course you can open a new file on the PC every
time if you don't mind typing on the PC every time.
To Load a .DO file from the PC, open TEXT, enter the File name, LOAD
(F2) and enter 'COM:88N1E' in response to 'Load from:'; on the PC terminal
program select Upload ASCII or whatever it's called and the file name (which
does not have to be the same as on the M100). You may not see anything
happening but the terminal program should indicate somehow when the transfer is
finished. Type a CTL-Z on the PC and the file should appear on the M100; switch
to BASIC and Load it, and Bob's your mother's brother.
This is mainly meant for folks who want to or have to just use the
M100's built-in functions, and to show how to avoid overruns when Loading BASIC
.DO programs as in a previous post here a few days ago.
Teeny, TS-DOS etc. certainly are very useful and in fact necessary if
you're working with .BA tokenized files or Machine language code.
Other than my phone I'm not an Apple kind of guy, so I can't give any
Mac-specific hints.
One other hint: to simplify switching from RUN to EDIT mode I've
programmed 'F6,"Edit"+chr$(13)'
Not too verbose, I hope...
m
----- Original Message -----
From: Will Senn
To: m100@lists.bitchin100.com
Sent: Saturday, October 29, 2022 10:16 AM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding
it up appreciated
Hi Mike,
I'm curious about the COM stuff. In a later note you said:
It's actually sorta been fun programming on the 'real' M100; I left a
download running on the PC and every time I wanted to backup an interim version
just in case, I just pressed F3 and F7 (which I'd programmed with the COM
stats).
and here, you say stuff about programming the function keys with
"COM:88N1E"...
It would be nice to be able to transfer / save from BASIC and/or my
terminal on the Mac without the overhead of dl/TEENY.CO. I know enough to be
dangerous and that the keys can easily be programmed to effectively type stuff.
I'm just not clear on is how this works mechanically. Are you in BASIC, typing
away, having just fixed some bit and are ready to SAVE it remotely, so you
press F3 and voila, it just does it, or do you press F3 and then do something
to get it transferring, or what?
I have the cables hooked up and usually, I:
1. SAVE from BASIC to .DO or .BA
2. Start up DL on the Mac side, if it isn't already running in my
~/m100 directory
3. Press F8 to get menu
4. Select TEENY.CO
5. Type S HEXIT .DO
6. Watch it complete without error (so long as HEXIT.DO doesn't
already exist, I think)
What I'm imagining happen is:
1. SAVE from BASIC to .DO or .BA
2. Press F3
3. Magically a file is sent and received on the Mac (where does it's
name come from?)
4. Celebration
or
1. F2 from BASIC
2. Start sending a file (how?) from the Mac
3. Celebration
Just curious!
Will
On 10/28/22 12:30 PM, MikeS wrote:
Yeah, that's a setup I used for a while, sort of a poor man's
tablet/clamshell 'convertible. ;-) No problem extending the cable to around 2
feet.
Never did use the disk drives very much although I did install a
second one; even today while playing with Will's dump program it's so simple
to plug in the cable to the PC, select download or upload on the PC and either
BASIC F3 (SAVE) to com: or TEXT F2 (LOAD) from com:, not to mention being able
to print on the PC and send/receive over the Internet.
Question for the experts: I have "COM:88N1E" stored in one of the
BASIC function keys; I don't suppose there's a way to do that for TEXT?
Back in the day IIRC the DVI and the M100 were both around $800;
probably still have the receipts somewhere; don't know what that'd be today..
And yes, the Model T and NEC BASICs are remarkably versatile,
especially considering the size constraints.
Definitely unique and, I don't know, friendly in a way...
m
----- Original Message -----
From: B 9
To: m...@bitchin100.com
Sent: Friday, October 28, 2022 12:39 AM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help
speeding it up appreciated
On Thu, Oct 27, 2022 at 8:51 AM MikeS <dm...@torfree.net> wrote:
It might not be so bad on a 200 but my main annoyance is
having to scroll up and down on the M100's 8 line screen; as a matter of fact
the larger screen was the main reason I bought a DVI when they came out.
When they came out? I wonder if they were more expensive when
they were new or now that they are rare and "vintage". Is that a picture of
your Disk/Video Interface setup? Looks nifty!
For a lot of stuff in the old days I actually used GWBASIC or
TBASIC to program on a PC; except for screen printing and graphics they're
almost completely compatible and with a few conditional lines many programs
could be run and tested on both the PC and the M100.
There's something I didn't know! I've been surprised at how
capable the Model T's 8-bit BASIC is. Was it the last one Microsoft made? Given
what I had expected after seeing the Apple ][ and C64, it's quite a bit more
advanced. (For example, ON COM GOSUB). And I read that the NEC 8201A version of
the DVI allowed not only color graphics, but extended the BASIC language with
graphics commands that I think may be from GW-BASIC.
I can understand that some folks want to relive the total
experience of doing everything on the old hardware [...]
Sure, and there's nothing wrong with reliving the past. But,
that's not me. I didn't get to experience the M100 when it was current. This is
my first time around with this technology, so part of the fun is trying to see
what it was like back then. I know, it's sort of like people who go camping for
a week to get in touch with their primitive hunter-gatherer ancestors. Not
likely to be terribly accurate, but still, it's fun.
Nevertheless, for just noodling around while relaxing on the
couch not much can beat the M100.
I'm beginning to learn that! I still haven't got a true Model
100. I only have a Tandy 200 because my neighbor was throwing it away and
wondered if I could use "an old laptop". I had no idea what it was. But, given
my experiences so far, maybe I should look into getting the real thing some day.
—b9
