IntyBASIC BACKTAB Card Hardware Flip?

[First Spear]

Can anyone share an idea or code routine in IntyBASIC (or Assembly callable from IntyBASIC) that could do a "hardware flip" of a particular on-screen card in BACKTAB?

 

My sample use case is having 3 arrows, all sourced from the same bitmap, different colors, pointing left. I know that the first arrow needs to point right and it is at tile 4,6. If there is a way to programatically change the "facing" of the arrow, then I would rather do that instead of creating a whole new bitmap.

 

My actual use case is doing the sample case for about 40+ different bitmaps; if it was just for a single arrow I would just redraw it or use the new functionality in IntyColor to flip stuff, but with a lot of images that gets out of hand quickly.

 

 

All ideas appreciated. Thanks!

[GroovyBee]

My sample use case is having 3 arrows, all sourced from the same bitmap, different colors, pointing left. I know that the first arrow needs to point right and it is at tile 4,6. If there is a way to programatically change the "facing" of the arrow, then I would rather do that instead of creating a whole new bitmap.

If they are all defined as the same card in GRAM and you flip the data for that single card, then all the cards on screen will point in the new direction. The only way to do it is to have as many unique arrows as required. How many arrows will you need to change per game frame?

[First Spear]

I am "mixing my metaphors", I think. I am not interested in the GRAM shape location necessarily, since I don't want to change the source, but I want to reverse the bitmap image at a specific location on the screen. That way if I know I placed 3 arrows on the screen at location 3,6 and 4,6 and 5,6 but want to change what is seen at 4,6 I can have that single card change.

 

I do not think that this is possible because there is no "buffer" between what is seen on-screen and the GRAM source, but if anyone knows of a cute way to do it, it would be the gurus on this forum.

 

Thanks.

 

 

 

If they are all defined as the same card in GRAM and you flip the data for that single card, then all the cards on screen will point in the new direction. The only way to do it is to have as many unique arrows as required. How many arrows will you need to change per game frame?

[GroovyBee]

I am "mixing my metaphors", I think. I am not interested in the GRAM shape location necessarily, since I don't want to change the source, but I want to reverse the bitmap image at a specific location on the screen. That way if I know I placed 3 arrows on the screen at location 3,6 and 4,6 and 5,6 but want to change what is seen at 4,6 I can have that single card change.

OK, just have a GRAM card for left and a GRAM card for right. Place either on screen in the direction required. Are you out of GRAM cards?

[Arnauld]

As already pointed out, you definitely need distinct GRAM cards for 'left' and 'right' shapes. You may however consider storing only one half of these shapes and building the other half programmatically.

 

I don't know if/how this can be adapted to IntyBASIC but here's an example in assembly. I'm using GROM card #46 (uppercase 'N') as the source and GRAM card #0 as the destination. But the source could be another GRAM card just as well.

.

            ORG         $4800

            MVII        #isr,       R0          ; set ISR routine
            MVO         R0,         $100
            SWAP        R0
            MVO         R0,         $101

            EIS                                 ; enable interrupts

            MVII        #$807,      R0          ; draw GRAM card #0
            MVO         R0,         $200+21     ; at (1,1)

            DECR        R7                      ; stay here

isr         PROC

            MVO         R0,         $20         ; enable display

            MVII        #$3000+46*8,R4          ; R4 = pointer to GROM card #46 ('N')
            MVII        #$3800,     R5          ; R5 = pointer to GRAM card #0
            MVII        #4,         R2          ; R2 = number of iterations (4 x 2 rows)

@@loop      SDBD                                ; load next 2 rows of source card
            MVI@        R4,         R0          ; into R0

            MOVR        R0,         R1          ; swap odd/even bits
            SLR         R1
            ANDI        #$5555,     R1          ; using bitmask %0101010101010101
            ANDI        #$5555,     R0
            SLL         R0
            XORR        R1,         R0

            MOVR        R0,         R1          ; swap bit pairs
            SLR         R1,         2
            ANDI        #$3333,     R1          ; using bitmask %0011001100110011
            ANDI        #$3333,     R0
            SLL         R0,         2
            XORR        R1,         R0

            MOVR        R0,         R1          ; swap nibbles
            SLR         R1,         2
            SLR         R1,         2
            ANDI        #$0F0F,     R1          ; using bitmask %0000111100001111
            ANDI        #$0F0F,     R0
            SLL         R0,         2
            SLL         R0,         2
            XORR        R1,         R0

            MVO@        R0,         R5          ; write result into destination card
            SWAP        R0
            MVO@        R0,         R5

            DECR        R2                      ; next iteration
            BNEQ        @@loop

            B           $1014                   ; return to EXEC

            ENDP

.

This code is missing a lot of initialization stuff but it does produce the expected result, at least in jzIntv.

 

We could also use a lookup table for all 256 possible rows. It would allow to process more cards per ISR.

 

[+DZ-Jay]

Can anyone share an idea or code routine in IntyBASIC (or Assembly callable from IntyBASIC) that could do a "hardware flip" of a particular on-screen card in BACKTAB?

 

My sample use case is having 3 arrows, all sourced from the same bitmap, different colors, pointing left. I know that the first arrow needs to point right and it is at tile 4,6. If there is a way to programatically change the "facing" of the arrow, then I would rather do that instead of creating a whole new bitmap.

 

My actual use case is doing the sample case for about 40+ different bitmaps; if it was just for a single arrow I would just redraw it or use the new functionality in IntyColor to flip stuff, but with a lot of images that gets out of hand quickly.

 

 

All ideas appreciated. Thanks!

 

I think everybody has missed your original question, though the answers are still relevant. To answer your specific question, unfortunately there is no way to "flip" background cards; that's a MOB feature only.

 

Therefore, if you want to display arrows pointing at different directions at the same time, you will need a different bitmap for each, like others have said. That also means one GRAM slot for each arrow direction.

 

You could programmatically alter the GRAM card, but it's almost always easier, faster, and more efficient just to define a different bitmap for each, and just change their index when drawing them in the background.

 

-dZ.