PLATOTerm full screen rendering snafus.

GFA, ASM, STOS, ...

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

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

PLATOTerm full screen rendering snafus.

Postby tschak909 » Thu Aug 23, 2018 6:47 am

Hey there, am working through porting PLATOTerm.

Code is currently living here:
http://github.com/tschak909/platotermst

This builds with the m68k gcc toolchain.

I've created a singly-linked list which is holding the draw commands to draw the currently visible screen. This is cleared whenever a screen clear happens. It seems to be filled correctly, however:

* subsequent redraw has massive corruption, text pointers are all off into weeds, and line draw has weird jaggy issues.
* and still a white square where the mouse re-appears after going into full screen.

Am I going in the right direction with creating the full screen window?
What could be causing the odd graphic corruption in the line draw?

-Thom

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

Re: PLATOTerm full screen rendering snafus.

Postby joska » Thu Aug 23, 2018 8:58 am

It's time to dig out the debugger :)

My experience with the gcc debugger on TOS is very limited, I used it briefly around 15 years ago but found it useless when debugging GEM-stuff. Things have hopefully improved since then.

PureC has a very good sourcelevel debugger, but it can only debug (at sourcelevel) binaries compiled with PureC.
Jo Even

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

ThorstenOtto
Captain Atari
Captain Atari
Posts: 400
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTerm full screen rendering snafus.

Postby ThorstenOtto » Thu Aug 23, 2018 9:32 am

joska wrote:My experience with the gcc debugger on TOS is very limited


If you mean gdb: that does not even work on plain TOS, it requires MiNT.

Things have hopefully improved since then.


Unfortunately not. It might even have getting worse, to the point that it is not usable at all. Maybe the current version does not even compile anymore.

You might try to let gcc spit out a DRI symbol table (with -Wl,--traditional-format), and use some other debugger instead, but that will be on the assembly level then.

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

Re: PLATOTerm full screen rendering snafus.

Postby joska » Thu Aug 23, 2018 10:47 am

ThorstenOtto wrote:If you mean gdb: that does not even work on plain TOS, it requires MiNT.


Yes, I mean gdb and I almost certainly used it under MiNT.

Pure Debugger is my favourite debugger on TOS/MiNT. It works well with MiNT too, but unfortunately it has some issues with CPU > 030. So on the Milan and Afterburner I mostly use the trusty old printf-debugger.
Jo Even

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

ThorstenOtto
Captain Atari
Captain Atari
Posts: 400
Joined: Sun Aug 03, 2014 5:54 pm

Re: PLATOTerm full screen rendering snafus.

Postby ThorstenOtto » Thu Aug 23, 2018 1:41 pm

joska wrote:Pure Debugger is my favourite debugger on TOS/MiNT. It works well with MiNT too,


Would be mine too, but i cannot get it to work reliable with MiNT. Maybe more related to fVDI, i have a lot of redraw problems there, mouse completely disappearing etc. The editor also has some serious issues with that. Really a shame, definitely still the best debugger i've seen.

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTerm full screen rendering snafus.

Postby tschak909 » Thu Aug 23, 2018 2:22 pm

Thanks for the tangental discussion.

-Thom

czietz
Hardware Guru
Hardware Guru
Posts: 765
Joined: Tue May 24, 2016 6:47 pm

Re: PLATOTerm full screen rendering snafus.

Postby czietz » Thu Aug 23, 2018 2:42 pm

To be honest, I don't even understand how your screen queue is supposed to work: You seem to always enqueue a block erase command even when processing a line or dot draw:
https://github.com/tschak909/platoterms ... een.c#L167
https://github.com/tschak909/platoterms ... een.c#L196
Assuming this is intentional, I don't see how redraw could work properly. You'd always read a list of block erases from your queue.

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTerm full screen rendering snafus.

Postby tschak909 » Thu Aug 23, 2018 2:52 pm

Wow, ok, egg on face. Yeah, did this to myself. :)

Wrong commands being shoved into drawing queue (line commands were also getting the same starting coordinate for both pairs) ;)

Now debugging why the text buffers for the text commands aren't being properly allocated.

czietz
Hardware Guru
Hardware Guru
Posts: 765
Joined: Tue May 24, 2016 6:47 pm

Re: PLATOTerm full screen rendering snafus.

Postby czietz » Thu Aug 23, 2018 3:01 pm

Although it's maybe not the source of the problem, I noticed something else with your code.

Code: Select all

void screen_char_draw(padPt* Coord, unsigned char* ch, unsigned char count, bool queue)

... gets passed a pointer to the character(s) to be drawn and the count.
(https://github.com/tschak909/platoterms ... een.c#L203)

Since you explicitly pass the count, I wonder: Is ch guaranteed to be always zero-terminated? If not, then using strdup on it (https://github.com/tschak909/platoterms ... een.c#L311) to get a buffer to enqueue is certainly wrong.

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTerm full screen rendering snafus.

Postby tschak909 » Thu Aug 23, 2018 3:03 pm

That's a good question. I wanted to use strndup, but it doesn't seem to be available, will look for another way to do it.

-Thom

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTerm full screen rendering snafus.

Postby tschak909 » Thu Aug 23, 2018 7:13 pm

I have managed to get it working by providing my own strndup routine (and flipping things around a little, as the character pointer was being prematurely freed),

so now I am looking to replace my naive dot-by-dot routine with a vrt_cpyfm(), and it is almost working, except it is retrieving not only the first character in the set, but the next character, and squeezing both into the same 8x12 space:

pt-snafu-1.png


The relevant code:

Code: Select all

/**
 * screen_char_draw(Coord, ch, count) - Output buffer from ch* of length count as PLATO characters
 */
void screen_char_draw(padPt* Coord, unsigned char* ch, unsigned char count, bool queue)
{
  unsigned char* queued_ch;
  short color_index[2]={1,0};
  unsigned char* curfont;
  char offset;
  short x,y;
  unsigned char i;
  MFDB screen_mfdb = {0};
  MFDB char_mfdb;
  unsigned char current_char;
  unsigned char* current_char_ptr;
  short pxyarray[8];

  if (queue==true)
    {
      queued_ch=screen_strndup(ch,count);
      screen_queue_append(screen_queue,SCREEN_QUEUE_CHAR,Coord->x,Coord->y,0,0,queued_ch,count);
    }

  switch(CurMem)
    {
    case M0:
      curfont=font;
      offset=-32;
      break;
    case M1:
      curfont=font;
      offset=64;
      break;
    case M2:
      curfont=fontm23;
      offset=-32;
      break;
    case M3:
      curfont=fontm23;
      offset=32;
      break;
    }

  // Flip color settings for inverse.
  if (CurMode==ModeInverse)
    {
      color_index[0]=0;
      color_index[1]=1;
    }

  x=scalex[(Coord->x&0x1FF)];
  y=scaley[(Coord->y)+14&0x1FF];

  for (i=0;i<count;++i)
    {
      current_char=*ch;
      ++ch;
      current_char+=offset;
      current_char_ptr=&curfont[fontptr[current_char]];

      char_mfdb.fd_addr=current_char_ptr;
      char_mfdb.fd_w=0;
      char_mfdb.fd_h=0;
      char_mfdb.fd_wdwidth=1;
      char_mfdb.fd_stand=0;
      char_mfdb.fd_nplanes=1;
      char_mfdb.fd_r1=char_mfdb.fd_r2=char_mfdb.fd_r3=0;

      pxyarray[0]=0;
      pxyarray[1]=0;
      pxyarray[2]=7;
      pxyarray[3]=11;
      pxyarray[4]=x;
      pxyarray[5]=y;
      pxyarray[6]=x+7;
      pxyarray[7]=x+11;
      x+=FONT_SIZE_X;
      vrt_cpyfm(app.aeshdl,1,pxyarray,&char_mfdb,&screen_mfdb,color_index);
    }

  return;

}


Some values are hard-coded until I can get this working.

The font data is encoded as a set of 8 bit values, one for each row, for 8 pixels across, so also 1 bitplane.
There are twelve bytes, for each character. like this:

Code: Select all

/**
 * Font definitions for font memories M0 and M1
 */

#include <stdint.h>

uint8_t FONT_SIZE_X=8;
uint8_t FONT_SIZE_Y=12;

uint8_t font[]={
  0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,     /* SPACE 0x20 */

  0x00,0x00,0x10,0x10,0x10,0x10,
  0x10,0x00,0x10,0x00,0x00,0x00,    /* ! 0x21 */

  0x00,0x00,0x00,0x28,0x28,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,    /* " 0x22 */

  0x00,0x28,0x7C,0x28,0x7C,0x28,
  0x00,0x00,0x00,0x00,0x00,0x00,    /* # 0x23 */

  0x00,0x00,0x10,0x7C,0x90,0x7C,
  0x20,0x7C,0x10,0x00,0x00,0x00,    /* $ 0x24 */

  0x00,0x00,0x42,0xA4,0x48,0x10,
  0x24,0x4A,0x84,0x00,0x00,0x00,    /* % 0x25 */

  0x00,0x00,0x20,0x50,0x20,0x62,
  0x92,0x8C,0x72,0x00,0x00,0x00,    /* & 0x26 */

  0x00,0x00,0x10,0x10,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,    /* ' 0x27 */
...


I know i'm missing something fundamental here, the stride (number of words in MFDB) is specified in words, but my block data is less than one word in length, will I need to reformat this as a block of 16-bit values?

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

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTerm full screen rendering snafus.

Postby tschak909 » Fri Aug 24, 2018 3:56 pm

anybody have an idea?? vrt_cpyfm is faster, and can leverage optimizations in the VDI driver...

-Thom

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 762
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: PLATOTerm full screen rendering snafus.

Postby mfro » Fri Aug 24, 2018 6:17 pm

why do you set char_mfdb.fd_w and char_mfdb.fd_h both to zero?

They need to be set to the width and height of your font data source raster form (8 and 12).

tschak909
Atari maniac
Atari maniac
Posts: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: PLATOTerm full screen rendering snafus.

Postby tschak909 » Fri Aug 24, 2018 6:19 pm

I was setting those to 8 and 12, respectively. It didn't seem to make a difference.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 7 guests