Generating button on screen with internal ROM font, using NTSC?
RinksCustoms
Posts: 531
so i came across a thread with a similar query, that member was told to check out the VGA_Demo.spin object, so i followed suit.. some makes sense, some does not.
I realize that "boxchr($ ) accesses the button making characters in ROM. I also understand the basic method of making the button with the "box" method above. "screen" is the virtual screen in RAM, word aligned. I'm fairly sure this code snippet just wont translate to tv terminal or graphics.spin.
The "PRI boxchr(c): i" method looks like its performing a mix of math with "c" then shifting everything left by 10 into screen, then advancing "ptr".. but why? Is there an easier (read - more readable and understandable) way of printing the run time only characters in ROM to the screen using graphics.spin or tv terminal? ie; by specifying the ROM addresses of the pieces of buttons to use? Any help or clarification here would be a big help.
boxcolor := $10
box(25,5,4,2)
col := 26
row := 6
print($114)
print("M")
print("e")
print("o")
print("w")
'....
PUB box(left,top,width,height) | x, y, i
ptr := top * cols + left
boxchr($0)
repeat i from 1 to width
boxchr($C)
boxchr($8)
repeat i from 1 to height
ptr := (top + i) * cols + left
boxchr($A)
ptr += width
boxchr($B)
ptr := (top + height + 1) * cols + left
boxchr($1)
repeat i from 1 to width
boxchr($D)
boxchr($9)
PRI boxchr(c): i
screen[ptr++] := boxcolor << 10 + $200 + c
I realize that "boxchr($ ) accesses the button making characters in ROM. I also understand the basic method of making the button with the "box" method above. "screen" is the virtual screen in RAM, word aligned. I'm fairly sure this code snippet just wont translate to tv terminal or graphics.spin.
The "PRI boxchr(c): i" method looks like its performing a mix of math with "c" then shifting everything left by 10 into screen, then advancing "ptr".. but why? Is there an easier (read - more readable and understandable) way of printing the run time only characters in ROM to the screen using graphics.spin or tv terminal? ie; by specifying the ROM addresses of the pieces of buttons to use? Any help or clarification here would be a big help.
Comments
It gets away with 10 bits for the address because the ROM font is aligned in a way so that the lower 6 bits of each character are all zero...
In any case, i think i'm closer to what it is that I want to do with the ROM font, make buttons on screen in NTSC. I'm going to experiment with the ROM font and palette color, i think that is the road i'm trying to go down.
Regular characters are made of two sequential 16x16 tiles in ROM, meant to be shown in 2-color. You use two sets of colors to pick one of the two interleaved characters.
One set of colors with show the even character, the other set the odd character.
The way the ROM font is used to show characters is really a trick to accomodate both 4-color and 2-color data.
We trick the driver to display the ROM font correctly as 2-color by selecting one of two colorsets in a special way...
IMHO: Things would have been a lot simpler if the ROM font wasn't coded in this wierd way. I think the creators sacrificed simplicity for a little more functionality...
Reading more about just how the TV driver does its rendering with respect to ROM fonts has alot to do with how you use your color palette for the tiles, specifically the color palette tells the TV driver which part of the overlayed characters (even/odd pixels) to display. I think i get it now, but i believe the TV driver will automatically stack the lower half of the character from ROM to form the whole character definition (ie- char @ $8000-$803F = top half of beveled corners box character). I'm guessing there's a bit of clever "screen tile memory math" to manipulate the TV driver into displaying only half of a character (upper/lower), in order to display the button correctly on the screen, which is where the line of code:
come into play.