VBXE - programming, examples, programming queries

Rybags · January 19, 2010

Just thinking... maybe we can use the ADD facility of the blit somehow.

Drawing a line, you always have the situation where either X or Y is always inc/decrementing by one each point. The other co-ordinate's change is controlled by the COLAC=COLAC+DELTAC, then you compare to ENDPT to decide whether that co-ordinate gets changed.

Just forget long lines for a bit... we might be limited to 255 pixel long lines.

We could use blits to prepare a list of all the COLAC values that will be encountered during the given line draw. Then we just do a bunch of compares. Of course, the blit hasn't done the COLAC=COLAC-ENDPT operation that's supposed to occur when a step occurs, but maybe we can adjust our compare value to compensate.

Unsure if this approach will work. In theory though if we could accelerate this part of the process, we could end up with a quicker line draw.

Heaven/TQA · January 19, 2010

that would be some of my thoughts... should be still quicker than doing it by hand...

what about a texture mapper? f.e. like in Alternate Reality: The Dungeon? Or Encounter?

Rybags · January 19, 2010

There's pattern fill, but you don't get scaling with it.

Kludge-o-matic method might be to use multiple mip-mapping levels along with different X-step or zoom* values.

Heaven/TQA · January 19, 2010

well...if the core would supply fractional "adds" than it would be good...

flashjazzcat · January 19, 2010

If anyone could post a verified working code snippet showing 80 col text mode characters with their background colours changed with the attribute byte, I'd be incomprehensibly grateful.

Enjoying this discussion, BTW. New ways to abuse the blitter are always interesting.

...It's OK. I think I have it cracked. TEXTMODE.COM sets every colour between 128-255 to turquise!

Edited January 19, 2010 by flashjazzcat

flashjazzcat · January 19, 2010

I require three distinct colour schemes on the screen:

1) light turqoise on dark

2) white on black

3) black on white

I'm attempting to set up the palette so that colour 1 is light turq, while colour 129 is dark turqoise (background). In turn, colour 2 is white, and colour 130 is black... and so on. Bit 7 of the attribute byte will always be set, while bits 0 and 1 simply select one of the three possible colour schemes.

User adjustments will then be accomplished using palette adjustment. Does this seem a sensible solution?

Rybags · January 20, 2010

Thinking again about using blits to do adds.

We could do array processing of 16-bit adds (you'd need to do a certain number of operations to gain any time benefit).

VBXE doesn't do Carry from lo-hi bytes though, but there's an easy way around that. Just compare the initial value with the new value (low bytes only). If the new value of the low byte is less than the initial value, then obviously a Carry has been generated and the high byte should be incremented.

e.g. 250 + 7 = 1 (less than initial value, Carry generated)

250 + 4 = 254 (not less than initial value, no Carry)

250 + 0 = 250 (not less than initial value, no Carry)

1 + 255 = 0 (less than initial value, Carry generated)

The compare would need to be repeated to check for overflow, but in many/most cases we're probably in a controlled situation where that won't happen so we could skip it.

So, we'd have something like:

. setup blits to add Array1 elements to Array2 elements - 1 blit for lo, 1 for hi bytes.

. run the blits (results get stored in Array2)

. run a loop that performs the carry check. For quicker execution the arrays are best stored with all low bytes in one block, high bytes in another. So the code for the carry check should be as simple as e.g. for 256 element array:

 ldx #0
checkcarry  lda array2_lowbyte,x
 cmp array1_lowbyte,x
 bcs no_inc1
 inc array2_highbyte,x
noinc1  inx
 bne checkcarry

Of course, some more extra speed could be had by unrolling that loop a bit.

The method could be expanded to higher order (24/32 etc) binary addition too.

Edited January 20, 2010 by Rybags

phaeron · January 21, 2010

 ldx #0
checkcarry  lda array2_lowbyte,x
 cmp array1_lowbyte,x
 bcs no_inc1
 inc array2_highbyte,x
noinc1  inx
 bne checkcarry

12 CPU cycles/byte is pretty expensive by blitter speeds, considering that doing a read-modify-write pass with the blitter can run as fast as 0.38 cycles/byte.

I did some sketches with logic operations, and I'm beginning to think that the fastest way to do this is using the blitter with a 64K lookup table to compute the carry. It's expensive in blitter time, but it's still much faster than the CPU at ~3 cycles/byte.

Rybags · January 21, 2010

But how's a lookup table going to work with an array processing situation?

I can't quite visulise how the blit could do a pass through our data again and tell us which bytes require Carry.

phaeron · January 21, 2010

But how's a lookup table going to work with an array processing situation?

I can't quite visulise how the blit could do a pass through our data again and tell us which bytes require Carry.

It's similar to the trick I did with the rotate program to set up the shears entirely on the blitter:

Create a list of N 1x1 blits. Source pattern replication works nicely for this.
Blit one set of addends into the source low bytes of the blits (dest X step = 21).
Blit another set of addends into source mid bytes of the blits.
Patch the final NEXT bit and execute the blit list. Each blit copies one entry from a 256x256 table into a destination array with 00 (no carry) or 01 (carry).
Use the result as source for a blit into the high byte array in add mode to add in lo->hi carry.

Not the fastest way to do a table lookup and you do need to align the lookup tables in memory, but it's still faster than the 6502.

Edited January 21, 2010 by phaeron

Rybags · January 21, 2010

Ahh... I got it now.

That technique could be used to do all kinds of table-lookup generation.

Next up: see if somehow we can do line-draw acceleration.

flashjazzcat · January 24, 2010

Any guidelines or tips on exporting palettes from Photoshop or similar when designing 256 colour bitmapped images for VBXE?

Heaven/TQA · January 24, 2010

question regarding 24bit macros in mads... is .long correct working for vbxe programming?

look:

$00100:
 Source: $04000 Xinc=+0 Yinc=+320
 Dest:   $00040 Xinc=+0 Yinc=+3841
 Size:   272 x 1
 Masks:  AND=$00, XOR=$00, COLL=$00
 Zoom:   1 x 1
 Patt:   disabled
 Mode:   0 (Copy)

says the debugger of Altirra and here is my BCB code snippet while using MADS...

char_bcb: 
	;.byte $00,$40,$00 ;source adress
	.long $004000 ;source adress
	.byte <320,>320 ;source step
	.long $004000 ;destination adress
	.byte <320,>320 ;dest. step
	.byte 15,0 ;size x
	.byte 15	;size y
	.byte 255 ;and
       .byte 0       ; XOR
       .byte 0       ;  collision AND
       .byte 0       ; zoom
       .byte 0       ; pattern
       .byte 9       ; control

????

Heaven/TQA · January 24, 2010

well... should make my bcb correct... my one is 18 bytes instead of 21...

phaeron · January 24, 2010

question regarding 24bit macros in mads... is .long correct working for vbxe programming?

look:

char_bcb: 
	;.byte $00,$40,$00 ;source adress
	.long $004000 ;source adress
	.byte <320,>320 ;source step
	.long $004000 ;destination adress
	.byte <320,>320 ;dest. step
	.byte 15,0 ;size x
	.byte 15	;size y
	.byte 255 ;and
       .byte 0       ; XOR
       .byte 0       ;  collision AND
       .byte 0       ; zoom
       .byte 0       ; pattern
       .byte 9       ; control

.long does produce a 24-bit value that should work, but you are missing the source/destination X step bytes.

Heaven/TQA · January 24, 2010

now the imho correct bcb:

Altirra> db 4100
4100: 00 40 00 40 01 01 00 40-00 40 01 01 0F 00 0F FF |.@.@...@.@......|
Altirra> db 4110
4110: 00 00 01 00 09 00 00 00-00 00 00 00 00 00 00 00 |................|

btw... how can I disassemble a complete block in Altirra?

Heaven/TQA · January 24, 2010

Altirra> .vbxe_bl
$00000:
 Source: $00024 Xinc=-55 Yinc=+2162
 Dest:   $04000 Xinc=+1 Yinc=+320
 Size:   256 x 1
 Masks:  AND=$00, XOR=$00, COLL=$00
 Zoom:   1 x 1
 Patt:   disabled
 Mode:   0 (Copy)

what could be the reason?

a12:
       lda #0
       sta $D650
       lda #$01          ;$000100 = $4100 bank #0
       sta $D651       ; blitter addr
       lda #0          ;
       sta $D652

Heaven/TQA · January 24, 2010

is there in Altirra an option where I can debug directly vbxe ram or look into it?

Heaven/TQA · January 24, 2010

RTFM... now altirra shows the correct bcb in debugger...

char_bcb: 
	.long $004000 ;source adress
	.word 320 ;source step y
	.byte 1
	.long $004000+100+16*320 ;destination adress
	.word 320 ;dest. step y
	.byte 1
	.byte 15,0 ;size x
	.byte 15	;size y
	.byte 255 	;and
       .byte 0     ; XOR
       .byte 0       ;  collision AND
       .byte 1       ; zoom
       .byte 0       ; pattern
       .byte 1       ; control

phaeron · January 24, 2010

Odd, that blitter setup should work. Any chance you may have accidentally hit the VBXE reset range at $D080-D0FF?

There currently isn't a way to peek directly at VBXE RAM -- you have to use the MEMAC A and B windows, switching banks by poking the control registers with the (e)nter command as necessary. The debugger currently only works in CPU view; giving it access to extended RAM isn't something I've gotten around to yet.

To see more of memory at once, you'll have to use the memory window. The 'db' command doesn't take a length parameter yet.

Heaven/TQA · January 24, 2010

ah... ok... was too used to db start,end or db start-end or db start end

Heaven/TQA · January 24, 2010

ok... most of the time it was my fault... damned... always stupid bugs... this time... I have not enabled the blitter to start...

Edited January 24, 2010 by Heaven/TQA

Rybags · January 24, 2010

Any guidelines or tips on exporting palettes from Photoshop or similar when designing 256 colour bitmapped images for VBXE?

For the pics I did (used Photoshop), I just converted from 24-bit to Indexed Color with one of the "Local" methods to bring it down to 256 colours.

You're only losing 1 bit per channel of RGB precision which is barely noticable. Of course the smaller palette means the pic will lose a bit of realism but it depends on the image.

I save as BMP with the image flipped (ie, right way up). Then it's a case of just skipping the header - 66 bytes (?)

Then you have the RGB for the palette which can just be loaded to RAM, stored in a Palette and discarded, followed by the bitmap data.

Heaven/TQA · January 24, 2010

i am skipping 1078 bytes?

Rybags · January 24, 2010

Short program I have - skip 54 bytes, then read 256 times (R, G, B, null byte), then picture data.

VBXE - programming, examples, programming queries

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members