PLATOTERM is a terminal program. It does not simply render text, it does not scroll. It draws data as it comes in, and everything that PLATO does expects this instant draw, particularly with animation.

The problem here, is that terminal control protocols are HIGHLY STATE DEPENDENT. The usual model of just reconstructing the document from what's in memory becomes very unwieldy, because you essentially run into having to do it one of three ways:

(1) keep a copy of the received data, replay the entire buffer when asked to redraw, reset buffer pointers back to 0 when screen clears.

This works, and can even be made to work somewhat well, but it falls short when you have long running screens that update data (such as dashboards), because you eventually fill up your buffer, or your buffer runs out of room to grow. And as the amount of data that gets drawn on one screen increases, so does the time required to bring the display back up to date when asked to redraw. Also, you can't separate the protocol data to isolate parts that need redrawing, because of the highly state dependent nature of the protocol.

(2) decode the data, place in a list, replace drawing operations that have same drawing operation and coordinates

This can be made to work, as well. but the overhead of maintaining the list, and constantly traversing it to find replaceable items becomes exponentially slower as the whole thing increases. Whole program slows to a crawl. Can't find a hash table algorithm that would help me here.

This would ideally be the right move to make, IF IT WERE ACTUALLY POSSIBLE IN A COMPATIBLE MANNER!

But GEM as shipped via TOS has no facility to create an off-screen bitmap, nor does VDI have any way to draw to an off-screen bitmap. This is perhaps one of the most maddening aspects about GEM programming documentation, I find a function that would ultimately solve all of my problems:

Off-screen bitmaps are also added to VDI by Enhancer, a freeware program of the NVDI authors: see attachment. I'm aware that this isn't the perfect solution you were perhaps looking for, either. But being freeware, you can redistribute it with PLATOTERM.

You do not have the required permissions to view the files attached to this post.

I'd stick with offscreen bitmaps, it makes things a lot easier in this case. Not many people will use GEM applications without NVDI these days, and if they do there's always Enhancer which does not use much RAM.

I am using only clones (Milan, FireBee) and on that computers are usable mostly only GEM software. On "powerful" Ataris are mostly users using "productive" software while on ST computers with less that 4MB of RAM are by my opinion mostly gamers and coders trying to get out most of the low spec computers. I dont think they are that much interested into Platoterm. But I could be wrong. Just my opinion.

I am using only clones (Milan, FireBee) and on that computers are usable mostly only GEM software. On "powerful" Ataris are mostly users using "productive" software while on ST computers with less that 4MB of RAM are by my opinion mostly gamers and coders trying to get out most of the low spec computers. I dont think they are that much interested into Platoterm. But I could be wrong. Just my opinion.

We are interested in Platoterm aswell but don't need a GEM application. A fullscreen customtailored version would do nicely for us.

wongck wrote:Hard to believe Plato being a 70s application cannot be implemented on an ST that's with a decade of advancement.

soo true

Why? The way i understand it is that it's basically an emulator that has to run in a GEM window at a certain speed. I think that ignoring GEM is a better option though. After all plato was built before GUIs

I've got it mostly working by implementing a replay of the terminal buffer, zeroing out the received buffer on screen clear (if it isn't being redrawn)There are some glitches I have to work out (on some displays, the currently selected font memory is incorrect, causing garbage on redraw).

and it was an incredible accomplishment to be able to render this into a very portable manner.

As it stands right now, PLATOTERM will even run on 520ST's with TOS 1.0 (this was made possible by using libcmini, as the mintlib was chomping up way too much program space! I do not need MINT functionality at all.)

But with this, I can now fold in the required dialogs (settings, PLATO key chart, and phone book), and spend however long debugging it all.

It's critical for me that this program works on as many ST/TT/GEM systems as possible, so literally using nothing but VDI/AES is the only option for me.

(as for the refill buffer, I've aligned it so that it will simply clear itself when it gets full)

tschak909 wrote:But GEM as shipped via TOS has no facility to create an off-screen bitmap, nor does VDI have any way to draw to an off-screen bitmap. This is perhaps one of the most maddening aspects about GEM programming documentation, I find a function that would ultimately solve all of my problems:

but only works if NVDI is provided, which is a no-go for this program, as it needs to work on as many systems as possible.

From what i know, those functions refereed by the URL you posted are mostly available in TOS. NVDI specific functions are clearly marked and even stated with versions when they are available.Best that your program also checks for validity of AES version, to be on the safe side.

tschak909 wrote:It's critical for me that this program works on as many ST/TT/GEM systems as possible, so literally using nothing but VDI/AES is the only option for me.

(as for the refill buffer, I've aligned it so that it will simply clear itself when it gets full)

From what I know, ST/TT/Falcon all have a ST screen mode compatibility so it will work as long as it uses simple TOS calls and ST screen.The Hirez screen mode may be limited due to ST needing specific monitor ( but then again nowadays most ppl will have a cable for their LCD that works).

As for the buffer with limited memory.... you can implement a ring buffer. May or may not work for your system. I believe most serial comms buffer are these anyway.

I also already thought about to give that advice, but it has one drawback: it will not work with NVDI, when using a graphics card. It will also fail on most non-standard setup (like emulators).

I think the easiest thing is to test for availability of v_opnbm() function (via EdDI cookie), and if that is not available, tell the user to install that enhancer.prg. It is very short and won't consume much memory.