IntyBASIC Erase GRAM Fast with GROM?

[First Spear]

Attempting to use the below code to erase the GRAM contents of locations 20 to 50. Is that the best way to do that?

 

Thanks.

For cc= 20 to 50
    Define cc , 1 , GramTile_Bitmaps_0
    If cc % 8 Then Wait
   Next
GramTile_bitmaps_0:
  DATA $0000,$0000,$0000,$0000

[skywaffle]

I did not think you could more or less queue multiple GRAM definitions in between waits. Are you needing to always clear the same number of grams?

[intvnut]

If you don't mind a bit of assembly, I think you can do this in a single frame.

.

Clear20to50: Procedure

ASM  MVII #c20to50, R0
ASM  MVO  R0, $100
ASM  SWAP R0
ASM  MVO  R0, $101
ASM  DECR PC
ASM c20to50:
ASM  SUBI #8, R6
ASM  MVII #_int_vector, R0
ASM  MVO  R0, $100
ASM  SWAP R0
ASM  MVO  R0, $101
ASM  MVII #(50 - 20) + 1, R0
ASM  CLRR R1
ASM  MVII #$3800 + 20*8, R4
ASM c20to50l:
ASM  MVO@ R1, R4
ASM  MVO@ R1, R4
ASM  MVO@ R1, R4
ASM  MVO@ R1, R4
ASM  DECR R0
ASM  MVO@ R1, R4
ASM  MVO@ R1, R4
ASM  MVO@ R1, R4
ASM  MVO@ R1, R4
ASM  BNEQ c20to50l

End

.

Clearing GRAM tiles goes much quicker than copying images into GRAM tiles.

 

I did not think you could more or less queue multiple GRAM definitions in between waits. Are you needing to always clear the same number of grams?

 

There is a WAIT buried in the IF-statement in First Spear's code:

 

If cc % 8 Then Wait

 

EDIT: Never mind, that's not what you meant. You meant multiple calls to Define between calls to Wait.

Edited February 15, 2019 by intvnut

[+DZ-Jay]

I'm curious ... why do you need to clear GRAM? I can't imagine a scenario where loading up GRAM with a blank card would be needed.

• If you need to make a MOB invisible, you can clear its "Visibility" flag.
• If you need a BACKTAB card to be clear, just set it to GROM card #0 (which is blank).

 

The only time I would worry about clearing GRAM would be during program initialization, but then that's handled by the EXEC during the bootstrap process. Even if you'd like to do it, it wouldn't be a time-critical process, so you could just loop with active display disabled and do the whole thing in one go.

 

What specifically are you trying to accomplish?

 

-dZ.

[intvnut]

I can imagine if you're computing tile bitmaps programmatically, say for rendering a proportional font bit-by-bit over multiple frames (think "RPG dialog" where text appears at speaking speed), or maybe an "automap" type of feature, starting from a blank bitmap is a good idea.

 

You can put your canvas tiles in BACKTAB, and then focus on DEFINE-ing cards as you update bits.

 

That said, 31 is (literally) an odd number of GRAM tiles to clear. It's also prime.

[carlsson]

If you have the ROM available, I would probably waste 15 * 4 = 60 words of $0000 and DEFINE 15 cards at a time. Intvnut's assembly code probably is even better, but if you desire to stay entirely in IntyBASIC that would be a decent approach I believe.

[+DZ-Jay]

I can imagine if you're computing tile bitmaps programmatically, say for rendering a proportional font bit-by-bit over multiple frames (think "RPG dialog" where text appears at speaking speed), or maybe an "automap" type of feature, starting from a blank bitmap is a good idea.

 

 

Gotcha. That's why I asked what was the actual use case to see what would be most optimal for it. Those you mentioned would be good candidates to clear the canvas.

 

-dZ.