Re: [M100] 100/102 to USB?

[John R. Hogerhuis]

On Fri, Mar 22, 2019 at 9:24 PM Willard Goosey  wrote:

>
> I wouldn't be surprised if modern MacOS has the same issues. Why not throw
> a couple Kbytes at the serial driver for buffer? RAM is cheap!
>
>
Well we either need more buffer on the Model T side or (counterintuitively)
less buffering on the PC side.

For FTDI devices on Windows you can set the buffers to trigger data-ready
events on 1 byte.

-- John.

Re: [M100] 100/102 to USB?

[Mike Stein]

At these low speeds I'd be surprised if the server needs to buffer anything but 
anything's possible.

I don't recall having any problems when connected over a 'real' RS-232 port 
using Hyperterm on WIN but I guess I'll have to revisit this one day. Back in 
the days when we first put the M100 on the internet ISTR that the issue was the 
fact that the 'modem' (or USB<>RS-232 adapter) sends packets instead of 
one-byte-at-a-time as with 'real' RS-232, and reducing packet length to 1 
character solved the problem.

There's also the issue of whether the USB adapter honors XON/XOFF...

In any case, a blanket statement that file transfer at any higher baud rate 
than 600 or 1200 bd is never reliable is a little misleading.

m

  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Friday, March 22, 2019 10:28 PM
  Subject: Re: [M100] 100/102 to USB?






  On Fri, Mar 22, 2019 at 6:56 PM Willard Goosey  wrote:


It's basically bufferbloat on the other side. The PC/Mac/whatev recieves
an XOFF and sticks it in a large recieve buffer and goes on with blasting
bytes at the M100. By the time it gets around to actually *processing* the
XOFF it's already overrun the M100's buffer. :-(

Faster serial transfers work best with things like old DOS term programs
that don't know about 16650 FIFOs. ;-) 

I never had any trouble with Procomm under msdos on a 386. Minicom under
Linux is nothing but trouble!




  My experience is the same. I've found it to be Linux specific. That's why 
hardware flow control, or inserting some delays is the only way to avoid 
overrun.

  Also the USB-Serial drivers add some buffering so that's another variable.

  Windows doesn't seem to have the problem based on most reports.


  I think the fix would be for Linux to read ahead in its buffers for XOFF 
character to see if it needs to flow-off.  But I doubt the maintainer will fix. 
At some point it was Alan Cox. I don't think there's any way to fix this 
outside the kernel.


  -- John. 

Re: [M100] 100/102 to USB?

[Willard Goosey]

In article
,
   John R. Hogerhuis  wrote:

> My experience is the same. I've found it to be Linux specific. That's why
> hardware flow control, or inserting some delays is the only way to avoid
> overrun.

I wouldn't be surprised if modern MacOS has the same issues. Why not throw
a couple Kbytes at the serial driver for buffer? RAM is cheap!

> -- John.

Willard

-- 
Willard Goosey  goo...@sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  --Robert E. Howard

Re: [M100] 100/102 to USB?

[John R. Hogerhuis]

On Fri, Mar 22, 2019 at 6:56 PM Willard Goosey  wrote:

>
> It's basically bufferbloat on the other side. The PC/Mac/whatev recieves
> an XOFF and sticks it in a large recieve buffer and goes on with blasting
> bytes at the M100. By the time it gets around to actually *processing* the
> XOFF it's already overrun the M100's buffer. :-(
>
> Faster serial transfers work best with things like old DOS term programs
> that don't know about 16650 FIFOs. ;-)
>
> I never had any trouble with Procomm under msdos on a 386. Minicom under
> Linux is nothing but trouble!
>
>
My experience is the same. I've found it to be Linux specific. That's why
hardware flow control, or inserting some delays is the only way to avoid
overrun.

Also the USB-Serial drivers add some buffering so that's another variable.

Windows doesn't seem to have the problem based on most reports.

I think the fix would be for Linux to read ahead in its buffers for XOFF
character to see if it needs to flow-off.  But I doubt the maintainer will
fix. At some point it was Alan Cox. I don't think there's any way to fix
this outside the kernel.

-- John.

Re: [M100] 100/102 to USB?

[Willard Goosey]

In article
,

> I thought this too, but I couldn't get sustainable transfer using
> anything above 58e1e (I also tried without the parity check but it
> didn't work better).

> It seems the serial buffer of the M100 is too small for reliably use
> xon-xoff.

It's basically bufferbloat on the other side. The PC/Mac/whatev recieves
an XOFF and sticks it in a large recieve buffer and goes on with blasting
bytes at the M100. By the time it gets around to actually *processing* the
XOFF it's already overrun the M100's buffer. :-(

Faster serial transfers work best with things like old DOS term programs
that don't know about 16650 FIFOs. ;-) 

I never had any trouble with Procomm under msdos on a 386. Minicom under
Linux is nothing but trouble!

Willard

-- 
Willard Goosey  goo...@sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  --Robert E. Howard

Re: [M100] 100/102 to USB?

[Eric LK]

Mike Stein wrote:
> That's something you read in many places, but as long
> as you've selected XON/XOFF handshaking at both ends
> there shouldn't be an issue using 19,200 baud, especially
> when uploading from the M100.

I thought this too, but I couldn't get sustainable transfer using
anything above 58e1e (I also tried without the parity check but it
didn't work better).

It seems the serial buffer of the M100 is too small for reliably use xon-xoff.

However you do have a very good point about uploading the data.
Assuming that the Mac on the other end has a a proper xon-xoff support
you should be able to go full speed in this direction (you probably
don't even need xon-xoff since this would be a very slow speed by
today standards, but it shouldn't hurt to use it :o)).

> You'll also find it will go faster if you use TEXT to load/save
> (using "COM:98N1E" as the file name) instead of TELCOM
> because the M100 won't have to scroll the screen which
> really slows things down.

Thanks for this trick. I'll try to remember it next time I cannot use TS-DOS.

Eric

[M100] DB API for M100 BASIC (was Re: 100/102 to USB?)

[Eric LK]

John R. Hogerhuis wrote:
> I suggest for data entry just use TEXT. You can use tabs or commas as field
> separators, CRLF as record separator and then import using tab separated
> CSV on your desktop. Very little overhead this way, maximizing use of your
T's RAM.

Thanks for the advice. That was the first version I made, but it had a
few problems for my case.
- Not all data I wanted fitted in the 32KB
- Loading it in a basic program to do data reports took about one
minute (and also limited the data volume since they had to fit twice:
once in the file and once in basic's RAM)

I ended up using CO files to store my data in binary. It's very
interesting for integers since they take only two bytes each instead
of 1-5 bytes + 1 byte for the separator.
Also I stored my strings in a separate CO file, so the main data file
has "fixed length records". This allowed me to implement a simple
random access file support.
And most important, I no longer load the files in basic RAM, but
instead parse the directory structure to find the file's address in
storage RAM and peek/poke directly in it.

>If you want to get really fancy you could make a BASIC program that
> would process the DO file and format search results on screen.

I actually re-implemented the "DO files forms" from Lucid-Database as
I found it was a very clever way to do this.
I cheated a little with "formula fields" by basically using them as
"hooks entry points" for basic subroutines (so it's more an DB API for
BASIC than a stand alone DB engine) but it does the job.

At the moment I have 809 records and 15430 bytes of data + 1682 bytes
of index and the "loading" takes about one second (the slower part is
the loading of the form.do which uses basic files functions).
Finding a record by record number is too quick to me measured, and
searching a record by string search takes between 0 and 4 seconds
(I'll probably try rewriting this part in assembly as soon as I read a
good book about it).

This is a fun project so far and since it's really a pet project and I
have no deadline I tried to do the maximum only using the M100 instead
of using the PC to pre-process the data files for the fun of it :o)
Because of this, when I calculated the index files used for alphabetic
research it took the M100 about 7 hours (it's a good thing I had an AC
power adapter).

It's not totally finished yet but if someone is interested in how I
did this I'd be happy to share the code and share things I've learn in
the process.

Eric

PS: Before starting this, I also tried T-Base but it wasn't as nice to
use as Lucid, and also entering/editing data was very slow

Re: [M100] Replacement belts for TPDD and other parts

[Brian K. White]

The belt is a standard size code, you just search the size code on ebay 
or google, and then ignore any results that cost more than about $10


Search "FRW-8.5 belt"

--
bkw

On 3/22/19 1:52 PM, alex d wrote:

Hello,

Where would one order replacement belts for the TPDD from and backup batteries? 
I see them listed on the club100 site at a cost of $7.00. The 3.6v backup 
battery is also listed.

It wasn't readily apparent on how I could order them on the site. If anyone 
could provide any pointers it would be greatly appreciated.

thanks

--
alex

Re: [M100] Replacement belts for TPDD and other parts

[Rick Shear]

I got my belts from cablesandconnectors.com  just go there and search for
frw8.5  They were cheaper than ebay at the time I bought mine.  They are
only $4.59 with reasonable shipping.


On Fri, Mar 22, 2019 at 1:01 PM Jeffrey Birt  wrote:

> Arcadeshopper has batteries, https://www.arcadeshopper.com/ and I do to:
> https://www.soigeneris.com/memory-backup-battery-mbat1
>
> I'm not sure about the belts. I picked up a TPDD months ago but have not
> gotten around to getting it working so have not tried to source a new belt
> yet.
>
> Jeff Birt (Hey_Birt!)
>
> -Original Message-
> From: M100  On Behalf Of alex d
> Sent: Friday, March 22, 2019 12:52 PM
> To: m...@bitchin100.com
> Subject: [M100] Replacement belts for TPDD and other parts
>
> Hello,
>
> Where would one order replacement belts for the TPDD from and backup
> batteries? I see them listed on the club100 site at a cost of $7.00. The
> 3.6v backup battery is also listed.
>
> It wasn't readily apparent on how I could order them on the site. If
> anyone could provide any pointers it would be greatly appreciated.
>
> thanks
>
> --
> alex
>
>
>
>

Re: [M100] Replacement belts for TPDD and other parts

[Ian Eure]

alex d  writes:


Hello,

Where would one order replacement belts for the TPDD from and 
backup batteries? I see them listed on the club100 site at a 
cost of $7.00. The 3.6v backup battery is also listed.



I got a replacement belt off eBay:
https://www.ebay.com/itm/Tandy-Portable-Disc-Drive-1-Replacement-Belt/302988073836

It worked fine.  The original belt was melty goo and a big hassle 
to
remove and clean up.  High-strengh isopropyl alcohol did the 
trick,

but the bits of belt got everywhere.

 -- Ian

Re: [M100] Replacement belts for TPDD and other parts

[Jeffrey Birt]

Arcadeshopper has batteries, https://www.arcadeshopper.com/ and I do to: 
https://www.soigeneris.com/memory-backup-battery-mbat1 

I'm not sure about the belts. I picked up a TPDD months ago but have not gotten 
around to getting it working so have not tried to source a new belt yet.

Jeff Birt (Hey_Birt!)

-Original Message-
From: M100  On Behalf Of alex d
Sent: Friday, March 22, 2019 12:52 PM
To: m...@bitchin100.com
Subject: [M100] Replacement belts for TPDD and other parts

Hello,

Where would one order replacement belts for the TPDD from and backup batteries? 
I see them listed on the club100 site at a cost of $7.00. The 3.6v backup 
battery is also listed.

It wasn't readily apparent on how I could order them on the site. If anyone 
could provide any pointers it would be greatly appreciated.

thanks

--
alex

Re: [M100] Replacement belts for TPDD and other parts

[Kevin Becker]

https://www.arcadeshopper.com/  has batteries.  
I’ve only seen the belts for sale on eBay.



> On Mar 22, 2019, at 1:52 PM, alex d  wrote:
> 
> Hello,
> 
> Where would one order replacement belts for the TPDD from and backup 
> batteries? I see them listed on the club100 site at a cost of $7.00. The 3.6v 
> backup battery is also listed.
> 
> It wasn't readily apparent on how I could order them on the site. If anyone 
> could provide any pointers it would be greatly appreciated.
> 
> thanks
> 
> --
> alex

[M100] Replacement belts for TPDD and other parts

[alex d]

Hello,

Where would one order replacement belts for the TPDD from and backup batteries? 
I see them listed on the club100 site at a cost of $7.00. The 3.6v backup 
battery is also listed.

It wasn't readily apparent on how I could order them on the site. If anyone 
could provide any pointers it would be greatly appreciated.

thanks

--
alex

Re: [M100] 100/102 to USB?

[Mike Stein]

- Original Message - 
From: "Eric LK" 
To: 
Sent: Friday, March 22, 2019 12:31 AM
Subject: Re: [M100] 100/102 to USB?

> If you use TELCOM, I'd recommend you keep the speed at 1200 or 2400 bauds. 
> While the M100 can do 19200, I had a few issues using faster speed until I 
> got a proper cable and started using mComm/TS-DOS.
--
That's something you read in many places, but as long as you've selected 
XON/XOFF handshaking at both ends there shouldn't be an issue using 19,200 
baud, especially when uploading from the M100.

You'll also find it will go faster if you use TEXT to load/save (using 
"COM:98N1E" as the file name) instead of TELCOM because the M100 won't have to 
scroll the screen which really slows things down.

Sounds like a cool project; too bad those planes don't have bar codes ;-)

m