PLATOTERM - solving the screen redraw problem, need input.

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Tue Jun 11, 2019 6:09 am

It's starting to bear fruit.

Here we have 512K ST's running TOS 1.0, no enhancements. Getting the redraw routine right will be the major time sink.

platoterm_520st_mono.gif


platoterm_520st_lores.gif


And it doesn't need NVDI. :)

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

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12709
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby wongck » Tue Jun 11, 2019 7:53 am

tschak909 wrote:as I said, I've managed to come up with a redraw method that I can improve upon.


Fantastic!! That's great.
“Don’t bail; the best pieces of gold are at the bottom of the barrel of crap.”
— Randy Pausch
https://quotefancy.com/quote/975884/Ran ... el-of-crap
My Stuff: FB/Falcon CT63 CTPCI ATI RTL8139 USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1686
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby Cyprian » Tue Jun 11, 2019 8:00 am

ThorstenOtto wrote:
Cyprian wrote:Set "_v_bas_ad" pointer to your off-screen address (your buffer with 32000 bytes) before painting offscreen and restore "_v_bas_ad" after finishing painting.


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.

yep, this should work under TOS ROM, in case of NVDI there is "EdDI" off-screen functionalities since 2.5 version


tschak909 wrote:as I said, I've managed to come up with a redraw method that I can improve upon


great
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

joska
Hardware Guru
Hardware Guru
Posts: 4377
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby joska » Tue Jun 11, 2019 8:32 am

Cyprian wrote:Or there is an other solution for non-preemptive TOS (1/2/3/4) - "_v_bas_ad". GEM uses that vector for painting the screen.

Set "_v_bas_ad" pointer to your off-screen address (your buffer with 32000 bytes) before painting offscreen and restore "_v_bas_ad" after finishing painting.


I believe this is what Enhancer does (+ some manipulation of VDI/linea variables). As already pointed out, this only works on standard video hardware.

Cyprian wrote:TOS and other applications (only accessories in case of non-preemptive TOS) will wait with its painting process for releasing the CPU with event-multi by your application.


When using GEM all drawing operations must be inside wind_update(BEGIN/END) calls, this will prevent other applications/accessories from drawing to the screen in all AES implementations.

tschak909 wrote:I've got it mostly working by implementing a replay of the terminal buffer,


This is the only implementation that actually will work on any current and future implementations of TOS on any hardware, regardless of window size and status (background/foreground/iconified etc).

Actually, that's not entirely correct. There is another implementation that will work but it could potentially be slow. You can create an offscreen bitmap in standard VDI format and use vr_trnfm to transform this to screen format. This will work on all versions of TOS, but there are two drawbacks:

1. You must implement your own drawing functions, as you can't open a virtual workstation on an offscreen buffer without the NVDI extension. The upside is that this allows you to use faster drawing operations than VDI does.
2. It can slow down output compared to "real" offscreen bitmaps since the transformation can potentially be costly.

I believe vr_trnfm can transform and copy to screen in one operation if the destination buffer is on screen. I have never tried this though.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Tue Jun 11, 2019 6:20 pm

Looks like the AES glitches that showed up in the two GIFs above do not happen with any version of TOS that I have except 1.0..which is strange, it might indicate some tomfoolery on my end, probably does... i'll make another gif today... but I also made sure to wrap the draw calls with wind_update() if it's in "draw direct to screen" mode.
-Thom

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Sun Jun 16, 2019 4:50 am

I've recorded a current in-progress video showing the state of it.

Thus far, it's doing very well on my test environment of a 520ST running TOS 1.0, so I can call this rewrite a success.

Still a lot to do (such as drawing new data when window is not on top), but it is already very usable in this state:
https://youtu.be/hxP7DammNRQ

The code is, of course, here, merged into master:
http://github.com/tschak909/platotermst

-Thom

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Sun Jun 16, 2019 11:22 am

Changing the color of the menubar is a nogo, and it does not work at all on multi-tasking AES.

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Sun Jun 16, 2019 3:02 pm

I am simply setting the palette. Nothing else I can do.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Sun Jun 16, 2019 3:26 pm

I thought you wanted a clean GEM program. Messing with the palette, especially if it results in a blue menubar, does not work in multitasking os. So your program might work now on TOS 1.0, but not on anything that ppl actually use.

Sorry if that sounds a bit harsh, but you asked for advice here, then simply decided to ignore everything. Instead you concentrated on supporting TOS 1.00, a very buggy of version of TOS that hopefully noone uses anymore.

I really appreciate your efforts to support GEM, but the results are a bit disappointing.

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Sun Jun 16, 2019 3:51 pm

and your approach to critique sucks beyond belief.

Bad Critique: Don't Do that.

Good Critique: Don't do that, do this.

For the record, this works in every environment that I've thrown at it, except MiNT, because of something odd happening at start-up which I need to track down.

For any display 640x480 or less, it's a full screen window.

For anything else, as you see, it opens a new window.

The code is public, if anyone has any insight, code changes etc, please help.
http://github.com/tschak909/platotermst

-Thom

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1951
Joined: Sun Jul 31, 2011 1:11 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby Eero Tamminen » Sun Jun 16, 2019 9:13 pm

You should use at least TOS v1.04. Nobody uses older TOS versions because they're so buggy, unless some specific game needs an obsolete TOS version (e.g. several games done with Omikron basic do funky stuff with ROM code and that part is naturally specific to ROM version which it was developed with, which in this cases was TOS v1.00).

If one is debugging things, it nice to use EmuTOS because sources are available and debug symbols file is included with the 512k version that can be loaded to Hatari.

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Sun Jun 16, 2019 9:19 pm

I have every known version of TOS, and I test against them. (so not kidding, there are keyboard mapping issues that I also have to check against)
-Thom

mikro
Hardware Guru
Hardware Guru
Posts: 2004
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby mikro » Mon Jun 17, 2019 6:28 am

tschak909: AES has its own (one would say standard but it's not 100% true) palette which are you not supposed to change. That goes definitely for the first 16 colours otherwise the menu, dialogs, desktop colours etc get corrupted.

So what you can do is to either interpolate using existing colours or at least give the user an option to override this behaviour, if it leads to better (faster) results.

Your app wouldn't be the first to change the palette but it's incredibly annoying for the user, esp. in 256+ colours environment.

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Mon Jun 17, 2019 6:35 am

The color palette is important for the Plato terminal itself. If someone wants to help him prove this, the code is public. With that said I am adding code to restore the pallet when the window is no longer on top.

joska
Hardware Guru
Hardware Guru
Posts: 4377
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby joska » Mon Jun 17, 2019 7:05 am

mikro wrote:AES has its own (one would say standard but it's not 100% true) palette which are you not supposed to change.


That's true, but especially when you only have four or 16 colours available it's a bit hard to avoid sometimes. But I agree that if you have more colours available you should try to find the closest match (and possibly change those colours when the window is on top) instead.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Mon Jun 17, 2019 8:25 am

When using code like
https://github.com/tschak909/platoterms ... een.c#L193

you should have better stick to GODLIB. That is definitely not GEM conform. Not to speak about the color issues, which you just ignore (and no, restoring the palette when the window is not on top won't help either)

joska
Hardware Guru
Hardware Guru
Posts: 4377
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby joska » Mon Jun 17, 2019 8:44 am

ThorstenOtto wrote:Not to speak about the color issues, which you just ignore (and no, restoring the palette when the window is not on top won't help either)


As I said above, while not ideal this is unavoidable sometimes. E.g. how would you implement a usable paint program in GEM if you can't change the palette? Stick to the default 16 colours?

ThorstenOtto wrote:When using code like
https://github.com/tschak909/platoterms ... een.c#L193


Hmm... Indeed, not very clean to put it mildly. Looks like he should use WF_WORKXYWH on the desktop instead.

http://toshyp.atari.org/en/008002.html# ... p_20window
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Mon Jun 17, 2019 9:12 am

joska wrote:how would you implement a usable paint program in GEM if you can't change the palette? Stick to the default 16 colours?


To be honest: i have no idea. But at least it would be a bad idea to change WHITE & BLACK, making the menu unusable. If you can't avoid that, then it might be better to just not use GEM (or at least not AES windows). Remember that you don't get a message that your window was untopped, if all you did was to open an accessory that displays a modal dialog.

mikro
Hardware Guru
Hardware Guru
Posts: 2004
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby mikro » Mon Jun 17, 2019 10:13 am

joska wrote:As I said above, while not ideal this is unavoidable sometimes. E.g. how would you implement a usable paint program in GEM if you can't change the palette? Stick to the default 16 colours?

Actually there is a real world example - Pixart. It allows you to choose whether to use local palette (and remap/dither when loading pictures) or to set its own. Very flexible and works for everybody.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Mon Jun 17, 2019 2:10 pm

Two other things i found:
https://github.com/tschak909/platoterms ... #L119-L125:

Your draw_menuline function will then use an invalid VDI handle, because the workstation was already closed again. Even worse, the open_vwork function trashes your vdi_handle.

https://github.com/tschak909/platoterms ... .c#L90-L92:

That is a nogo. The value returned by Iorec() is (if at all) informative only. You are writing to kernel memory there, and that might as well be the reason why your program crashes under MiNT.

And some other things:
https://github.com/tschak909/platoterms ... menu.c#L49
https://github.com/tschak909/platoterms ... #L292-L295
https://github.com/tschak909/platoterms ... enu.c#L323

Why don't you use the constants created by the resource editor instead of hardcoded values? Whenever you change the resource, you have to change also all your sources now.

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Mon Jun 17, 2019 2:51 pm

thanks, draw_menuline isn't being used, so I will rip it out.

I'll fix the Iorec issue, I pulled this from a document showing how to change the input buffer value, which I desperately need to do.

The hard-coded constants aren't that big of a deal for me, am using RSM, and it doesn't seem to generate constants...is there a resource editor I should be using?

-Thom

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Mon Jun 17, 2019 3:25 pm

You could use ORCS, but RSM can also generate constants. Its just the *.rsm file that seems to be empty, did you use Interface first?

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Mon Jun 17, 2019 3:32 pm

Nope, I did not... I'll try ORCS.

-Thom

tschak909
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby tschak909 » Mon Jun 17, 2019 3:56 pm

also, million dollar question, how am I _supposed_ to increase the size of the serial receive buffer? the information I can find on setting up the serial port literally told me to do what I did.

-Thom

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 661
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTERM - solving the screen redraw problem, need input.

Postby ThorstenOtto » Mon Jun 17, 2019 4:08 pm

tschak909 wrote:how am I _supposed_ to increase the size of the serial receive buffer?


You aren't. That's task of the driver. You should better use HSMODEM when dealing with real serial devices, the routines built into TOS (up to all known TOS versions) have too many bugs.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests