PLATOTerm full screen rendering snafus.

[tschak909]

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]

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.

[ThorstenOtto]

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]

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.

[ThorstenOtto]

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]

Thanks for the tangental discussion.

-Thom

[czietz]

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]

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]

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]

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]

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

[tschak909]

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

-Thom

[mfro]

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]

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