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 16*9*50 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 <will.s...@gmail.com>
>>> *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 <hacke...@gmail.com>
>>> *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
>>>
>>>
>>>
