Is this an emulator issue, a ROM issue or an 'unavoidable thing'?

[Snickers11001001]

Ran into this playing with BASIC this past weekend. 

Particulars:

Running R38 on Windows 10.    Starting the program with Scale -2.

Using Screen$80 to pull up the bitmap, no pokes or other funny business with the registers, just using X16 basic.

Plotting a "VERA charset" text character to the bitmap with CHAR generates odd behavior whenever Y<6.     

Example (after SCREEN$80 to to go bitmap w/text overlay):

         CHAR160,6,4,"#"  - places purple hash character flush to the top at roughly the center of the screen.    This is expected behavior. 

         CHAR160,5,4,"#"  - places purple hash character with top slightly cut off several rows lower and maybe 64 (ish) pixels to the right.   Not expected behavior. 

Reducing the Y coordinate further still results in the same plotting offset down and to the right of expected coordinates, but with the character moving further up and more of the character's top being cut off. 

I see the examples on the Programmers Ref. Guide adding '6' as a starting base offset for the Y coordinate in the examples, so it seems folks are aware of this.    I wasn't sure whether this is a known issue that is corrected,  or if it is somehow 'expected, although inconvenient' behavior that cannot be altered.      Given that it appears the specified coordinate in an x16 CHAR command refers to the lower left of the character it makes sense there would need to be an offset.   (My personal preference might be to have the coordinate of the CHAR command refer to the top-left pixel of the character, but since characters are always bigger than pixels there still needs to be boundary behavior considered).   Still,  it seems to me that if the specified coordinate would put part of the character off the bitmap it should either ignore the characters in the CHAR command that would need to in part print offscreen (like what happens if you try to CHAR a character or string that would run off the right side).   It probably should not dump a partial character or sting at an unexpected place on the screen. 

Edited to add screenshot:    The up arrows point to the "Y" parameter, and the commands show the odd behavior when Y<6

  

 

 

[ZeroByte]

I don't know what the answer is, but it smacks of mixing signed and unsigned data. It seems like the routine is hitting a memory address somewhere in a different tile's char data / region of the bitmap data (I haven't played with the BASIC screens, so am not familiar much) - this sounds like a Kernal bug to me.

[kelli217]

Is it possible that the Y coordinate is for the baseline of the character? I know the CHAR font is a GEOS font, and I know that GEOS fonts take their position from the baseline. But I haven't gone looking through the documentation.

[Snickers11001001]

Yes, CHAR does Y as baseline as a norm for the CHAR command.  

But the issue is that there's something wrong with out of bounds handling at the top of the screen. 

If the character is 7 pixels tall, then setting a CHAR to put one onto the bitmap at  a Y<6 should either do nothing, place the character but cutting off the top, or raise an error.   

What it currently does is CHAR somewhere else on the screen completely, which is what I think is unexpected and appears to be some sort of fault

 

[ZeroByte]

Kelli is on to something. There’s code which uses top-left of char interacting with code that uses bottom left of char. That’s what this feels like.

[Snickers11001001]

1 hour ago, ZeroByte said:

There’s code which uses top-left of char interacting with code that uses bottom left of char. That’s what this feels like.

I might think so if it was just off vertically, or off by the height of the character.   

But it's  off by a lot and with other oddness.

I've added a screenshot in my opening post above to illustrate.    Notice that the boundary handling on the right side of the screen does well:   If you put something that's too long to print, it goes as far as it can in terms of printing whole characters and then stops.     Even the screwed up behavior in the Y parameter still has the string trimmed (brown example in my screen shot)  because the code is aware that with the X coordinate supplied by my commend the rest (should) be offscreen if the string printed where it was supposed to.  

But as you see, in the CHARs with a Y<6 ('light red', 'green,' and 'brown' examples in my added screenshot)  the deviations are (a) the top is cut off by the amount it WOULD need to be cut off to print a partial character had it appeared on the top of the screen where directed; and (b) it is mistakenly put at an entirely different location on the bitmap both in x and y, but at a location that multiple tests suggest may be some constant offset away in VERA memory. 

 

[desertfish]

I would think that it is just an optimization issue. Clipping things all the time to stay within screen boundaries is an expensive operation. I guess some addressing simply wraps around now when stuff is drawn outside screen borders.  

[Snickers11001001]

7 minutes ago, desertfish said:

I would think that it is just an optimization issue. Clipping things all the time to stay within screen boundaries is an expensive operation. I guess some addressing simply wraps around now when stuff is drawn outside screen borders.  

Yeah, but look at the screenshot. 

It DOES clip for text that would flow off the right side of the screen. 

But whatever its doing on the Y<6 parameter, its not simply a wrap around or overflow because of where the character is landing.     Look at the purple/green hashes in the screen shots.   Just weird.  

[kelli217]

I see what you're talking about now.

The clip is being calculated correctly, so that's good.

But the position is... interesting. Looks like integer overflow? Or underflow.

[desertfish]

Yeah I don't know exactly, I just assume undefined behavior when an underflow or overflow occurs.    And perhaps it's cheap to clip just the X-position, and is that implemented? Who knows -- use the source, Luke ?