On 8/7/24 11:31 AM, B 9 wrote:
On Wed, Aug 7, 2024 at 6:33 AM Kenneth Pettit <[email protected]> wrote:
Hi B 9,
No, pointers are defined as 8x9 images with a mask. And there is
only a single pointer, so it could only be used for the mouse (for
instance). I had considered this option. But I don't believe I
have a way of defining a custom cursor in AsciiPixels.
Okay. Is there an exclusive-or drawing method?
No. I thought about adding that, but trying to keep code space down, it
didn't make it in there.
I tried using an AsciiPixels STRING resource to draw the mouse,
cheese and cats. But for some reason, AsciiPixels kept erasing
the pixels on the wall below the image being drawn. I had defined
a 3x3 image, and it is supposed to stop drawing once it completes
the defined shape. I even tried other sizes like 4x4, 5x4, etc.
But each time it would erase the bottom wall in the cell. This is
now something on my list of things to debug.
I'm not seeing that problem on the Tandy 200. For example, here is a
5x5 AsciiPixels string I tried: "APf3((#L6$" which fits neatly inside
Lloyd's maze.
The 5x5 is still an issue in M100. I investigated this and it looks
like for M100, the code isn't reading / masking the original line
correctly before starting to draw the image. The M100 LCD controllers
have data arranged in columns with each byte representing a column of 8
pixels. The code is properly keeping the pixels "above" the image but
zero'ing out the pixels "below" it. In terms of the bye, this means it
is properly keeping the original display LSB bits but not the MSB bits.
Probably just an error in calculating the AND mask (similar to the
recent bug found in the T200 display routine).
Knowing the issue, it should be relatively easy to fix. The ASM code
has a specific routine to read-and-mask the currently drawn row, so it
narrows down the location of the bug quite a bit.
Ken
