Stumped!!
potatohead
Posts: 10,261
Arrgh! I've been working with this video pixel loop for too long. I know it's something stupid, but I'm just not seeing it. Hoping some extra eyes will spot the problem and I can move on.
This is code from the next revision to the 8x8 character driver. I want to have the font table located in the COG, for a low memory footprint, and the option to snag 4 color chars from the HUB memory, if the user wants that. This is only the COG memory loop, no 4 color option logic yet.
I'm using the general purpose register variable model, so:
A = current screen memory byte pointer It is reset to start of screen memory, every frame loop
B = is current character definition byte, read from screen, using A for the pointer (The actual screen memory value one byte per char displayed)
B gets operated on. It's multiplied by two, then has the font table address added as well, along with either a 0 or 1, to address either the lower 4 lines of a character, or the upper one. In the HUB, byte addressing means each byte is a scanline of the char being displayed. In the COG, it's either one long, or the other one, thus the final add.
C = is the long in the COG, pointed to by the result of B, and is the group of pixels to be displayed in the current screen position
Only the lower most 8 bits are displayed in the waitvid. The upper ones are ignored and need to be shifted into the lower most position. It's an 8 pixel frame. The least significant bits
are shifted out, one by one.
D = temporary working register, where the value of font_line is operated on to impact both B (upper or lower long) and C (number of pixels to shift right for display)
r1 = number of waitvids per scanline, calculated from the constants higher up in the program.
Outside the loop, fontline gets added, modulo 8, as each scan line completes to form a sub-character offset counter. This value helps determine character long addressing, and shift amounts (I think).
I'm having trouble with the shifting of pixels (I think.) I've attached a screen shot, showing only the first scanline of any given character actually displaying pixels. This suggests the calculation for the COG font table access are good. Maybe not... I did check to see there was actually pixels in the font table! The screen memory just increments right now. 00, 01, 02, 03... modulo 16, as I only have 16 chars currently defined in the COG font table, for testing.
BTW: OpenOffice is a great bit manipulator tool, just represent the bits as strings and all sorts of quick and dirty tricks become possible.
That font table looks like this:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/7/2007 5:06:43 PM GMT
This is code from the next revision to the 8x8 character driver. I want to have the font table located in the COG, for a low memory footprint, and the option to snag 4 color chars from the HUB memory, if the user wants that. This is only the COG memory loop, no 4 color option logic yet.
I'm using the general purpose register variable model, so:
A = current screen memory byte pointer It is reset to start of screen memory, every frame loop
B = is current character definition byte, read from screen, using A for the pointer (The actual screen memory value one byte per char displayed)
B gets operated on. It's multiplied by two, then has the font table address added as well, along with either a 0 or 1, to address either the lower 4 lines of a character, or the upper one. In the HUB, byte addressing means each byte is a scanline of the char being displayed. In the COG, it's either one long, or the other one, thus the final add.
C = is the long in the COG, pointed to by the result of B, and is the group of pixels to be displayed in the current screen position
Only the lower most 8 bits are displayed in the waitvid. The upper ones are ignored and need to be shifted into the lower most position. It's an 8 pixel frame. The least significant bits
are shifted out, one by one.
D = temporary working register, where the value of font_line is operated on to impact both B (upper or lower long) and C (number of pixels to shift right for display)
r1 = number of waitvids per scanline, calculated from the constants higher up in the program.
Outside the loop, fontline gets added, modulo 8, as each scan line completes to form a sub-character offset counter. This value helps determine character long addressing, and shift amounts (I think).
:draw_pixels rdbyte B, A 'get a character from screen memory (A)
shl B, #1 'multiply by 2, for char offset
add B, #font_tab 'add font table address
mov D, fontline 'gonna operate on fontline
and D, #%100 wz, nr 'upper or lower char long?
if_nz add B, #1 'if upper, add one long
mov C, B 'get pixel group from COG
and D, #%0011 'mask off shift amounts
shl D, #3 'multiply by 8
shr C, D 'shift desired pixels into position (I think this is the problem area...)
waitvid colors, C 'draw them to screen
add A, #1 'point to next set of chars
djnz r1, #:draw_pixels 'line done?
jmp #end_graphics_scan_line 'on to the right border
I'm having trouble with the shifting of pixels (I think.) I've attached a screen shot, showing only the first scanline of any given character actually displaying pixels. This suggests the calculation for the COG font table access are good. Maybe not... I did check to see there was actually pixels in the font table! The screen memory just increments right now. 00, 01, 02, 03... modulo 16, as I only have 16 chars currently defined in the COG font table, for testing.
BTW: OpenOffice is a great bit manipulator tool, just represent the bits as strings and all sorts of quick and dirty tricks become possible.
That font table looks like this:
{ COG memory font table. Each char is 8 bytes high. So, there will be two longs per char defined
in the table. The chars are stored mirror image, due to waitvid shifting out to the right.
xxxxxxxx_xxxxxxxx_xxxxxxxx_xxxxxxxx Bits Display O=visible pixel,color 1
│ │ │ │
│ │ │ └──────── %0000_0000 = --------
│ │ └────────────────── %0010_0011 = OO---O--
│ │
│ └──────────────────────────── %1100_0100 = --0---00
│
└───────────────────────────────────── %0000_0000 = --------
}
font_tab long %00011000_00011000_00011000_00000000
long %00000000000110000000000000011000
long %01100110011001100110011000000000
long %00000011100000000111111111000000
long %01100110111111110110011000000000
long %00000000011001101111111101100110
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/7/2007 5:06:43 PM GMT
720 x 540 - 286K
Comments
Didn't get solid pixels.
I think font_tab is resolving to some address that does not make sense to the running COG. That addition just puts the pointer somewhere in the COG modulo $1ff
Goes off to desilva's tutorial on this matter...
...no joy just yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/7/2007 6:29:17 PM GMT
But I shall also help a little bit in person
does not do what you expect... It just .... copies; it does not fetch the scanline.
MOVS :deref, B NOP :deref MOV C, 0-0will do the trick..
Edit/BTW: you can also interleave "AND D, #%0011" in place of the useless "NOP"
Post Edited (deSilva) : 10/7/2007 6:46:26 PM GMT
edit: Solids work too, I see. [noparse]:)[/noparse]
I knew it was something stupid. Appreciated. I got into the mode where I was thinking other processors...
And here they are, running from the COG memory:
The code fix was:
:draw_pixels rdbyte B, A 'get a character from screen memory (A) shl B, #1 'multiply by 2, for char offset add B, #font_tab 'add font table address mov D, fontline 'gonna operate on fontline and D, #%100 wz, nr 'upper or lower char long? if_nz add B, #1 'if upper, add one long movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]ixel_pointer, B 'modify the mov pixel instruction directly and D, #%0011 'mask off shift amounts [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]ixel_pointer mov C, 0-0 'get pixel group from COG shl D, #3 'multiply by 8 shr C, D 'shift desired pixels into position waitvid colors, C 'draw them to screen add A, #1 'point to next set of chars djnz r1, #:draw_pixels 'line done? jmp #end_graphics_scan_line 'on to the right border▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/7/2007 6:53:53 PM GMT