Turning PLATOTerm Lite into 8k

[_The Doctor__]

TBH the old TLP needed to be free from it's baud limit and memory constraints, the addition of the fill and and some other optimization aspects would certainly help the original TLP reach faster and better representation. He added back in the ability to use touch pads etc. It's a decent list of changes that his terminal has done. Quite a work in progress. TLP had terminal types hard-coded to it's original identity, which was wiped out for Macintosh or some such machine (I forget)... so initially he hacked it to run at 2400 with a new terminal ID (which worked pretty well ... )

 

Those roms and exe's are in another thread... It would be pretty nice to see the original TLP with the fill and optimizations tuned up to see how fast it could process it all among other things...

Edited December 31, 2018 by _The Doctor__

[tschak909]

The original TLP cartridge was based on the 1981 edition of the ASCII PLATO protocol, which was subsequently amended to add a few additional features, namely:

 

* Paint

* 24-bit color foreground/background

 

These features when encountered by TLP are erroneously not ignored, like they should be, but are interpreted as data in the current mode, which manifests as garbage.

 

TLP also had HARD-CODED handlers for the 850, 1030, and MPP modems, and by hard coded for the 850, I literally mean _850_ no P:R: connection, no APE support, nada.

 

So I addressed these issues head on. PLATOTerm works with any R: handler.

 

PLATOTerm interprets all current control codes for the most current revision of the ASCII protocol.

 

It supports a wide variety of touch devices.

 

At the expense of basically letting go of the Zoomed mode (because that requires a solid chunk of 24K of RAM, in addition to the 8K needed for the scaled display)

 

Once we get proper flow control support in our hardware, we'll be able to use much faster speeds, much more reliably.

 

Also, the PLATOTerm protocol decoder has hooks in it to support a Kermit implementation, so that can be added with minimal effort.

 

There were damned good reasons to do the Atari version of PLATOTerm, I hope it's now clear. The port took minimal effort, and was able to leverage the sheer portability of the codebase that also powers the C64, Apple2, C128, ZX Spectrum, MS-DOS, Amiga, Atari ST, Macintosh, Apple IIgs, Microbee, Memotech MTX-512, MSX, Coleco Adam, TI 99/4A, etc ports.. all from the same codebase

 

-Thom

[_The Doctor__]

Kermit

but didn't they also add other d/l protocol? (down the road) or are we sticking strictly with things at a certain cut off date.

 

most transfer protocols have their own form of flow control and correction as each block is sent and the response must be sent before the next one is pushed out. had to explain why turning OFF software flow control for transfers helped (since most transfer protocols limit and control flow by their very design) and picking appropriate sizing of the transfer proto choice helped depending on the network (a sort of match up tuning if you will).

 

I may call a bbs with soft flow on for online reading etc. but I will turn it off for X modem 1k - Y Modem and F-Modem etc.... sliding window transfers don't fare as well. But, reducing transfer block methods work great. (F or Y that reduces from 4k to 1k etc all the way down)

 

As usual hardware flow would always be left on since it is not seen in the data. The reason to turn off soft flow during transfers protocols is to prevent deadlocks and time outs. Often the data stream can contain the very characters that soft flow acts on. Sometimes it's best to just tell them try it and see. You get the inevitable wow that worked!

 

I had thought at one point there would be an emergency transfer mode added where plato would send terminal data via u/l d/l protocol for problematic connections on iffy networks. This would slow things slightly but would eliminate errors and regulate flow.

Edited December 31, 2018 by _The Doctor__

[tschak909]

sigh, no, you're confusing what's used for transferring files across to the system, with what's used for general data transfer.

 

If you read s0ascers, you will see precisely what is actually implemented verbatim in PLATOTerm. (minus section 4, which deals with Micro-TUTOR)

 

-Thom

[+Nezgar]

TLP also had HARD-CODED handlers for the 850, 1030, and MPP modems, and by hard coded for the 850, I literally mean _850_ no P:R: connection, no APE support, nada.

There was no 1030 in 81, maybe the 835?

[tschak909]

sigh. The released cartridge was completed in the summer of 1984. You forget, _I HAVE BEEN STARING AT THE SOURCE CODE FOR OVER A YEAR_

 

-Thom

[+David_P]

I think both the 835 and 1030 have similar handlers (and maybe the XM301 as well).

[Jeffrey Worley]

 

On 12/30/2018 at 11:49 PM, tschak909 said:

 

The original TLP cartridge was based on the 1981 edition of the ASCII PLATO protocol, which was subsequently amended to add a few additional features, namely:

 

* Paint

* 24-bit color foreground/background

 

These features when encountered by TLP are erroneously not ignored, like they should be, but are interpreted as data in the current mode, which manifests as garbage.

 

TLP also had HARD-CODED handlers for the 850, 1030, and MPP modems, and by hard coded for the 850, I literally mean _850_ no P:R: connection, no APE support, nada.

 

So I addressed these issues head on. PLATOTerm works with any R: handler.

 

PLATOTerm interprets all current control codes for the most current revision of the ASCII protocol.

 

It supports a wide variety of touch devices.

 

At the expense of basically letting go of the Zoomed mode (because that requires a solid chunk of 24K of RAM, in addition to the 8K needed for the scaled display)

 

Once we get proper flow control support in our hardware, we'll be able to use much faster speeds, much more reliably.

 

Also, the PLATOTerm protocol decoder has hooks in it to support a Kermit implementation, so that can be added with minimal effort.

 

There were damned good reasons to do the Atari version of PLATOTerm, I hope it's now clear. The port took minimal effort, and was able to leverage the sheer portability of the codebase that also powers the C64, Apple2, C128, ZX Spectrum, MS-DOS, Amiga, Atari ST, Macintosh, Apple IIgs, Microbee, Memotech MTX-512, MSX, Coleco Adam, TI 99/4A, etc ports.. all from the same codebase

 

-Thom

I'm having trouble with Platoterm.  The best I can get is:

 

Boot Sparta 3.2g from floppy (with Basic OFF)

load rs232 for P:R: connection

load Plato.exe

 

I can then, at 9600bps, issue an atdt96.226.245.179,8005

 

It will connect to the plato network and give me what is almost a readable screen for login.  The font is blown up so large it overlaps with lines above and below and is indecipherable, though once in a while you see something really intelligible if it is printed alone.  So it works, but I can't read it or use it.  What am I doing wrong?  I've tried an 800xl and an 800 with Incognito.  Both do the same things.

 

What's more, the software is finicky.  It doesn't want to run under SDX, it will hang if you try to run it with the Rverter handler, which last bit really sux due to the lost 19.2k mode.

 

Help!  I always wanted to use Plato.

 

Jeff

[tschak909]

Your WIFI modem must be set for RAW, not TELNET (no translation of any incoming or outgoing data)

 

Please do not run at 9600bps, it will not work, you will need to use either 1200bps or 2400bps due to the fact that the R-Verter handler is very brain damaged and only allocates a 256 byte ring-buffer (despite asking for a larger one during my concurrent mode open), and the fact that there is no real flow control with R-Verter devices to speak of.

 

There are reasons I am working on #FujiNet now, this is one of them.

-Thom

 

[Jeffrey Worley]

9 hours ago, tschak909 said:

Your WIFI modem must be set for RAW, not TELNET (no translation of any incoming or outgoing data)

 

Please do not run at 9600bps, it will not work, you will need to use either 1200bps or 2400bps due to the fact that the R-Verter handler is very brain damaged and only allocates a 256 byte ring-buffer (despite asking for a larger one during my concurrent mode open), and the fact that there is no real flow control with R-Verter devices to speak of.

 

There are reasons I am working on #FujiNet now, this is one of them.

-Thom

 

Well, whoda thunk it?!  I dropped the baudrate to 2400 and got on peachy.  How NEAT!

 

I'm not using the Rverter presently.  Since the Rverter handler causes the software to just freeze, I went to a P:R: connection.  That allowed the software to load, but gave junk at 9600.

 

Thanks!

 

Any hope of getting the ware's to play nice with SDX?

 

Best,

 

Jeff

[tschak909]

It does for me, there are two versions, the disk version and the lite version (which ironically, over time got almost every feature except the splash screen). Tried both?

 

I will not be doing any new versions of the R: PLATOTERM, as I have gone as far as I can with it. The 850 style interfacing needs to die, it has served its purpose, and trying to shoe-horn IP modems onto it (when you can't even do proper handshaking), is absolute lunacy. 

 

So for now, all of my attention is going towards #FujiNet.

 

-Thom