PLATOTERM ST: Need input on solving the redraw problem.

[tschak909]

Hey guys,

 

This is now my seventh rewrite of PLATOTERM for Atari ST.

 

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.

 

(3) create an off-screen color (or mono) bitmap; routines to draw into bitmap, blit rects onto VDI surface as directed by AES.

 

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:

 

7.10.24 v_opnbm Name: »Open bitmap« - Open an off-screen bitmap. Opcode: 100 (Sub-Opcode 1) Syntax: void v_opnbm ( int16_t *work_in, MFDB *bitmap, int16_t *handle, int16_t *work_out ); Description: The call v_opnbm serves for the creation of off-screen bitmaps. One can either specify the size of a bitmap that it should allocate, or pass a bitmap to it. The bitmap is managed in the same format as that of the screen, which makes fast copying between the two possible.The following apply: Parameter Meaning handle graf_handle work_in[0..10] See v_opnwk/v_opnvwk work_in[11] Width -1 (e.g. 1279) work_in[12] Height -1 (e.g. 959) work_in[13] Width of a pixel in 1/1000 mm work_in[14] Height of a pixel in 1/1000 mm work_in[15..19] Reserved, should contain 0

If the EdDI cookie has version number 1.1 or newer, v_opnbm takes additional arguments in work_in[15..19] into account: An attempt is made then to open a bitmap in the format described by these parameters. If there is no driver for the specified format, then the bitmap cannot be created. The following apply: work_in[15..16] Number of simultaneously displayable colours work_in[17] Number of planes work_in[18] Pixel format work_in[19] Bit order

Pixel format and bit order are described in greater detail in vq_scrninfo. With the following parameters, for instance, one can create an off-screen bitmap with 256 colours and interleaved planes:

work_in[15..16] = 256;  /* 256 colours           */work_in[17] = 8;        /* 8 Planes              */work_in[18] = 0;        /* Interleaved planes    */work_in[19] = 1;        /* Normal bit order      */

Attention: work_in[11] + 1 should be divisible by 16 without remainder. Otherwise the VDI driver will round up (work_in[11] + 1) to the next number which can be divided by 16 without remainder.

If pixel width and height are 0 the pixel size of the screen workstation is used.

Note: The use of off-screen bitmaps can be useful if one wants to avoid effects such as heavy flicker on the screen. In that case one builds up the parts of the graphic in the bitmap and transfers the bitmap with vrt_cpyfm or vro_cpyfm to the screen. Return value: Information is passed to the outside via the work_out array or the Memory Form Definiton Block (MFDB): Parameter Meaning work_out[0..1] See v_opnwk/v_opnvwk work_out[2] 0 work_out[3..38] See v_opnwk/v_opnvwk work_out[39] 0 (no hardware CLUT) work_out[39..56] See v_opnwk/v_opnvwk bitmap Pointer to MFDB

If bitmap->fd_addr is zero, the VDI will allocate memory for the bitmap and will clear it (in contrast to v_opnvwk).

To open a bitmap in device-specific format, bitmap->fd_nplanes should be zero, or the number of planes of the screen (work_out[4] from vq_extnd). If bitmap->fd_nplanes is 1, a monochrome bitmap will be created.

The elements of the MFDB (fd_addr, fd_w, fd_h, fd_wdwidth, fd_stand, fd_nplanes) are set by the VDI before returning from v_opnbm. If there is not enough memory to create a bitmap the handle will be zero and the MFDB will not be changed.

If bitmap->fd_addr is not zero, it will be used as pointer to a bitmap. If the bitmap is in standard format, it will be transformed into device-specific format. If the number of planes of the bitmap is not supported by the VDI, a zero handle will be returned. Availability: The function is available as of EdDI Version 1.00. From EdDI 1.1 onwards, v_opnbm can be called with additional parameters. Group: Control functions See also: Binding NVDI Off-screen bitmaps v_clsbm

 

So basically, limiting my program to those who install NVDI. This is a no-go, as NVDI will not work on 520ST or 1040ST's without RAM expansion.

 

I am at a loss here, what the hell can I do?

 

What I can not do, so don't even bring it up:

 

* Use GODLIB. This is not a game. It's a productivity app. GODLIB does not solve many of the problems that this terminal program needs to function.

 

* Bypass the OS - Again, THIS IS NOT A GAME.

 

-Thom

[ParanoidLittleMan]

And another one complaining about GEM programming documentation . We should make a list, and buying new hard disk, so it can fit

 

Sorry, but not clear is this: "7.10.24 v_opnbm Name: »Open bitmap«" with NVDI ?

 

I'm not for using diverse extensions if it can be solved with regular OS, or even with pure, direct on screen, in RAM drawing code.

Isn't logical screen address intended for off screen drawings ? I mean that what setting with XBIOS 5 call. I never tried it, because had no need for some off screen draw with my GEM SW.

Maybe to fool GEM with simple trick - setting screen address with XBIOS 5, then setting real address with direct write into HW registers to old content, so drawing is not visible ,,, ?

[tschak909]

I've managed to find an approach that will work (re-playing the protocol stream). The major time sink will be getting all of the edge cases taken care of (when to ignore bits of the protocol stream, or reconstruct missing bits that may have been set from before a screen clear, etc.)

 

The approach will mean that even a 512K ST with TOS 1.0 will be able to run PLATOTERM just fine, as demonstrated here:

 

 

 

And yeah, I do complain, the GEM API is fucking horrible! (the Amiga port, by contrast, took a week, http://github.com/tschak909/platotermamiga/)... but I'm getting stuff done.

 

-Thom

[ParanoidLittleMan]

Well, only what I can say is that nobody became fast and efficient on new platform, computer in short time. Plus, that someone did job in much shorter time in some API must not mean that it is so much better.

Maybe it was just better for you, with your previous experience, approach.

I would not say that GEM API is horrible. It has it's flaws, but overall I, and many others did their programming well, and without getting nervous breakdown

 

So, it will run on 512 KB, TOS 1.00 , from cartridge, but will need NVDI ???? Very f*ing confused ...

[tschak909]

no, not need NVDI.

 

And you seem very hell bent on defending what is a very poorly designed API. Sorry, it is. I've ported this program to over two dozen platforms in the last year. I can offer a very objective view on this.

 

What have you done?

 

-Thom

[ParanoidLittleMan]

You should really write more clear. And I'm the one among Atari people who criticized a lot Atari, DRI because of their poor documentation.

But you were not clear in your long first post here, neither in second (NVDI usage and other things). I guess more interesting was to use F* word and talking about Amiga superiority, bragging. We don't care, and we heard it zillion times.

Coming here, asking for help, then getting offensive - What have you done ? Grove up, pls.

[tschak909]

Virtually everything I have done, is public, my github goes back almost 5 years. Most recently, my singular focus has been on getting terminals written for IRATA.ONLINE. Going back further, I've been a member of the GNU and free software community since 1988, when I provided a patch to GNU Make, and have volunteered my time in many projects since.

 

I don't want to start a fight, sorry I barked, there is a ton of frustration with this specific 16-bit port that I simply haven't had to deal with in such a massive concentration (and this includes the Macintosh, 16-bit Windows, plain X11/xlib, Achimedes/RiscPC...all the ports to classic windowing systems. I do not include the X68000 or MS-DOS ports, as those do not use a windowing system.) and GIVEN that I have done these ports, in quick succession, and recently, it gives me a _VERY_ objective view on the different windowing toolkits and their design.

 

-Thom

Edited June 11, 2019 by tschak909