Stephen Adolph | 10 Feb 03:32
Picon

the pervasiveness of TPDD protocol

Furthermore, it seems that since TPDD protocol will work well over
wide area, and is by nature unable to overflow the RX buffers on the
M100, then it could be further expanded like was done by TS (the
desklink extensions), to support

* terminal sessions
* file downloads within terminal

And, since we are likely to use terminal to run web apps, then we have
a generalized solution for bi-directional data transfer with the M100.

So, I guess my proposal is to further expand TPDD protocol to handle
other forms of data transfer, so it is the underlying transport
protocol for data to and from the wide-area network gateway.

..Steve

On Tue, Feb 9, 2010 at 8:36 PM, Stephen Adolph <twospruces@...> wrote:

> I've been thinking about bluetooth and the M100. It seems to me that > the best "achitecture" for mobile net enabled apps would be as > follows- > > 1)  M100 with an RS-232 bluetooth dongle (hardware flow control!), and > REX of course. > 2)  a smartphone, with WiFi support > 3)  optional - a NADSbox with an RS-232 bluetooth dongle > 4)  a better terminal program for M100, as an option ROM, including XMODEM > > It is easy to instruct bluetooth to connect to either NADSbox or > smartphone.. This can be scripted basically.  We know that TPDD > protocol runs well on bluetooth now.  Also, a version of Desklink > could be made for Blackberry. > > Then, all we are doing is writing apps for Blackberry, to adapt text > email, bulletin board, downloads etc. > > I think this would do it all, and avoid any further custom hardware. > The Blackberry and NADSbox can sit out of sight, and all you'd need is > an RS-232 Bluetooth dongle on the M100. >
John R. Hogerhuis | 10 Feb 03:48
Picon
Favicon

Re: the pervasiveness of TPDD protocol


On Tue, Feb 9, 2010 at 6:32 PM, Stephen Adolph <twospruces@...> wrote: > Furthermore, it seems that since TPDD protocol will work well over > wide area, and is by nature unable to overflow the RX buffers on the > M100, then it could be further expanded like was done by TS (the > desklink extensions), to support > > * terminal sessions > * file downloads within terminal > > And, since we are likely to use terminal to run web apps, then we have > a generalized solution for bi-directional data transfer with the M100. > > > So, I guess my proposal is to further expand TPDD protocol to handle > other forms of data transfer, so it is the underlying transport > protocol for data to and from the wide-area network gateway. >
Yeah Ken and I have talked a bit about that TS-DOS extensions so you could tunnel shell access through it among other things. It wouldn't be hard to do. Note though that TS-DOS is request/response, and terminal sessions are generally not request/response. So either you have to simulate an interactive session by constantly polling, or you have to break the request/response abstraction and permit asynchronous/unsolicited data. -- John.
Stephen Adolph | 10 Feb 02:36
Picon

proposal

I've been thinking about bluetooth and the M100. It seems to me that
the best "achitecture" for mobile net enabled apps would be as
follows-

1)  M100 with an RS-232 bluetooth dongle (hardware flow control!), and
REX of course.
2)  a smartphone, with WiFi support
3)  optional - a NADSbox with an RS-232 bluetooth dongle
4)  a better terminal program for M100, as an option ROM, including XMODEM

It is easy to instruct bluetooth to connect to either NADSbox or
smartphone.. This can be scripted basically.  We know that TPDD
protocol runs well on bluetooth now.  Also, a version of Desklink
could be made for Blackberry.

Then, all we are doing is writing apps for Blackberry, to adapt text
email, bulletin board, downloads etc.

I think this would do it all, and avoid any further custom hardware.
The Blackberry and NADSbox can sit out of sight, and all you'd need is
an RS-232 Bluetooth dongle on the M100.

J Bickhard | 9 Feb 14:24
Picon

TEENY and UltraStar100

I loaded up UltraStar100 with TEENY, and it's great albeit a little
slow. However, when I hve USC100.co loaded and try to use TEENY, I end
up with a whole lot of garbled characters whereever I'm supposed to
have 'smell text'. Anyone know why this is?

--

-- 
Jake (dats me)

VANDEN BOSSCHE JAN | 9 Feb 15:16
Picon

RE: TEENY and UltraStar100


Hallo,

> -----Original Message-----
> From: J Bickhard
>
> I'm supposed to have 'smell text'. Anyone know why this is?

I don't know, but this stinks!

> Jake (dats me)

Greetings from the TyRannoSaurus
Jan-80             """""
@ work            ( >=< )
--------------.ooo--(_)--ooo.---

DISCLAIMER: This e-mail, together with its annexes, is 
confidential.If you are not the addressee or an authorized 
recipient of this message, any keeping, distribution, copying, 
publication or use of its contents for any purpose is prohibited. 
Please notify the sender immediately by e-mail and then delete 
this message.

Stephen Adolph | 9 Feb 04:05
Picon

new terminal program needed ...

This problem of not buffering incoming serial data properly at full
speed is a problem indeed.  Working with things that don't obey
software flow control is a pain!

Perhaps we need to develop a new terminal ROM or something.

..Steve

John R. Hogerhuis | 9 Feb 04:32
Picon
Favicon

Re: new terminal program needed ...


On Mon, Feb 8, 2010 at 7:05 PM, Stephen Adolph <twospruces@...> wrote: > This problem of not buffering incoming serial data properly at full > speed is a problem indeed.  Working with things that don't obey > software flow control is a pain! > > Perhaps we need to develop a new terminal ROM or something.
Well I did create HTERM for just this purpose... it implements hardware flow control. It even discards annoying ANSI color escape codes and allows you to disable scrolling to speed things up when that is useful. A full OptROM may or may not be necessary. HTERM is pretty small. It does need a reliable file transfer implementation... xmodem would be good, or some integration with TS-DOS. Also it could use a capture mechanism. Another possible solution is to squeeze HTERM into the main ROM, possible replacing TELCOM. -- John.
Stephen Adolph | 9 Feb 04:36
Picon

Re: new terminal program needed ...

I'm annoyed at the moment because the good old M100 cannot keep up
with a burst of 19.2 kbaud characters.  The bluetooth device has a
control interface that can give a report of text detailing all the
settings.   This data streams to the M100 at 19.2 and is more than 100
bytes.  At some point, the buffers overflow on the M100 and you lose
data on the screen, making it unreadable.

I suppose hardware flow control would fix that.

Where do you store HTERM?  I will check your personal folder.

thanks, Steve

On Mon, Feb 8, 2010 at 10:32 PM, John R. Hogerhuis <jhoger@...> wrote:

> On Mon, Feb 8, 2010 at 7:05 PM, Stephen Adolph <twospruces@...> wrote: >> This problem of not buffering incoming serial data properly at full >> speed is a problem indeed.  Working with things that don't obey >> software flow control is a pain! >> >> Perhaps we need to develop a new terminal ROM or something. > > > Well I did create HTERM for just this purpose... it implements > hardware flow control. It even discards annoying ANSI color escape > codes and allows you to disable scrolling to speed things up when that > is useful. > > A full OptROM may or may not be necessary. HTERM is pretty small. > > It does need a reliable file transfer implementation... xmodem would > be good, or some integration with TS-DOS. Also it could use a capture > mechanism. > > Another possible solution is to squeeze HTERM into the main ROM, > possible replacing TELCOM. > > -- John. >
John R. Hogerhuis | 9 Feb 04:50
Picon
Favicon

Re: new terminal program needed ...


On Mon, Feb 8, 2010 at 7:36 PM, Stephen Adolph <twospruces@...> wrote: > I'm annoyed at the moment because the good old M100 cannot keep up > with a burst of 19.2 kbaud characters.  The bluetooth device has a > control interface that can give a report of text detailing all the > settings.   This data streams to the M100 at 19.2 and is more than 100 > bytes.  At some point, the buffers overflow on the M100 and you lose > data on the screen, making it unreadable. > > I suppose hardware flow control would fix that. > > Where do you store HTERM?  I will check your personal folder. >
http://bitchin100.com/files/m10x/HTERM.CO http://bitchin100.com/files/m10x/HTERM.lst -- John.
Stephen Adolph | 9 Feb 05:00
Picon

Re: new terminal program needed ...

Found it!  old emails.
I could not get it to work though. Notwithstanding 38400 vs 19200.  It
just beeps and exits.
..Steve

On Mon, Feb 8, 2010 at 10:50 PM, John R. Hogerhuis <jhoger@...> wrote:

> On Mon, Feb 8, 2010 at 7:36 PM, Stephen Adolph <twospruces@...> wrote: >> I'm annoyed at the moment because the good old M100 cannot keep up >> with a burst of 19.2 kbaud characters.  The bluetooth device has a >> control interface that can give a report of text detailing all the >> settings.   This data streams to the M100 at 19.2 and is more than 100 >> bytes.  At some point, the buffers overflow on the M100 and you lose >> data on the screen, making it unreadable. >> >> I suppose hardware flow control would fix that. >> >> Where do you store HTERM?  I will check your personal folder. >> > > http://bitchin100.com/files/m10x/HTERM.CO > http://bitchin100.com/files/m10x/HTERM.lst > > -- John. >
John R. Hogerhuis | 9 Feb 06:07
Picon
Favicon

Re: new terminal program needed ...


On Mon, Feb 8, 2010 at 8:00 PM, Stephen Adolph <twospruces@...> wrote: > Found it!  old emails. > I could not get it to work though. Notwithstanding 38400 vs 19200.  It > just beeps and exits. > ..Steve >
Beeps and exits? I assume you cleared space? Don't know what to say other than, it worked fine last time I used it... are you using the latest version? Maybe it's ORGed at the wrong spot and hanging over into variable space? I had a version at some point with that problem. -- John.

Gmane