GROM Table Mask

[Alkadian]

Hi,

I am back here seeking for more help again 

 

With reference to page 245 from Oscar's second book (Advanced Game Programming For Intellivision) I read that with setup MODE 0,0,7,0,7 you can use the mask $2000 to change the background between black/white.

 

I understood from the comments provided to me in one of my previous threads that I need first to empty the 'bit-fields' before writing new values to them. Can somebody please explain to me how to achieve it with a simple example? Thanks!

Edited September 17 by Alkadian

[+DZ-Jay]

The short answer is to AND with a bitmask that is the complement of the bits you want to erase.  So, for the case of the bitfield $2000, you can use "NOT $2000."

 

Here is a trivial example:

' Get the data word from BACKTAB
#data = Backtab(pos)

' Erase the contents for the bitfield of interest
#data = #data AND (NOT $2000)

' Set the value of the bitfield
Backtab(Pos) = #data + $2000

Of course, you could do that in a single operation:

Backtab(pos) = (Backtab(pos) AND (NOT $2000)) + $2000

Now, keep in mind that you only need to do this if you do not know the current state of the bitfield -- that is, if you do not know whether it is currently empty or not.  If you know for sure its contents, you can take some shortcuts by manipulating it directly.

 

For instance, using an XOR operation will flip the bits from 0 to 1, and viceversa.

' Toggle the "Color Stack Advance" flag
Backtab(pos) = Backtab(pos) XOR $2000

That's the short version, assuming you know how this all works.  If you are not familiar with Boolean logic, bitwise operations, or bit-masking in general; you can take a look at this simple guide I offered someone else in the past.

 

 

 

And just because you are experimenting with Color Stack, which some people find weird and difficult to use, here is a description I wrote in the past for someone else to help them understand the mode.

 

 

dZ.

 

 

[Alkadian]

@DZ-Jay many thanks for your help to let me understand the subject. I am happy to report that I have made a little progress. I have managed to change the background colour of the first four rows of sort of space invaders bitamaps and then change back to all black for the other remaining rows. I have also experimented with the MUSIC statements. I have made a very simple tune based on Stranger Things series theme that plays in the background. Very, very basic but I am very happy with my progress. It is so rewarding, thanks again 

[+DZ-Jay]

Whenever you get some progress that you would like to share, just post the compiler ROM binary file.  Others can see what you've done, comment on it, and offer suggestions.

 

    dZ.

[Alkadian]

Sure, I will do. For now nothing really going on. But for me big progress

background.rom

Edited September 17 by Alkadian

[+nanochess]

Cool Stranger Things style background 😎

 

[Alkadian]

Hi,

Again nothing special here. But I am now getting more familiar with the loops instructions and the MUSIC statement! I am really having a lot of fun. I have also experimented GIMP with INTYTColor and it works great! 

I hope the tune will sound familiar! Just to share my little achievements

 

alternate.rom

Edited September 21 by Alkadian

[Alkadian]

Hi,

 

I have been experimenting with masking either the ROM card number or the RAM card number from the backtab.

 

The bitmask for the GRAM in mode 1 is: 0000000111111000=$01F8

 

The bitmask for the GROM in mode 0 is: 0000011111111000=$07F8

 

The code seems to work fine when masking the GRAM. In fact the second bitmap gets displayed in the correct place y+4=1+4=5

 

CLS

MODE 1

WAIT

DEFINE 1,1,bitmap1

 

c=10

loop:

#backtab(c)=$0800 + 1 * 8 + 7

wait

x=#backtab(c)

y=(x AND $01F8) /8

#backtab(y+4)=$0800 + 1 * 8 + 7

GOTO loop

 

bitmap1:

BITMAP "...##..."

BITMAP "#.#..#.#"

BITMAP ".######."

BITMAP "..#..#.."

BITMAP ".#....#."

BITMAP "#......#"

BITMAP ".######."

BITMAP "........"

 

 

However the code below it doesn't seem to work when masking the GROM. In fact the GROM character # gets displayed in a different position and not at position y+1=3+1=4

 

CLS

MODE 0,2,0,0,0

WAIT

c=0

 

loop:

#BACKTAB(c)=$0007 + 3 * 8

WAIT

#BACKTAB(c)=x

y=(x and $07F8) / 8

#BACKTAB(y+1)=$0007 + 3 * 8

 

GOTO loop

 

Could you please explain to me what I am doing wrong? Also I have noticed that if I don't put WAIT after #BACKTAB(c)=$0007 + 3 * 8, then the first GROM character doesn't get displayed at all.

 

Thanks!

Edited September 23 by Alkadian
Typos

[artrag]

Note that x,y are 8 bit variables 

#backtab() is a 16 bit variable, its value has to be passed to a 16 bit variable unless you want to lose the upper 8 bits

[Alkadian]

3 hours ago, artrag said:

Note that x,y are 8 bit variables 

#backtab() is a 16 bit variable, its value has to be passed to a 16 bit variable unless you want to lose the upper 8 bits

@artrag, thanks so much for pointing that out. Shame on me as I should have noted that 16-bit variables always need a # in front of them! I did read it on @nanochess's book (page 9)and completely forgot about that! Thanks again! 

 

That did the trick and I am very happy to report that the code below is now working as intended!

 

CLS

MODE 0,2,0,0,0

WAIT

c=0

 

loop:

#BACKTAB(c)=$0007 + 3 * 8

#y=(#BACKTAB(c) and $07F8) / 8

#BACKTAB(#y+1)=$0007 + 3 * 8

GOTO loop

 

Edited September 24 by Alkadian
Added more context and image

[+DZ-Jay]

@artrag's response was spot on.  I just wanted to add that you should take a look at the "Constants.bas" file and look to use its constants to avoid magic numbers.  It makes your code a lot easier to read and maintenable.

 

This code,

loop:
#BACKTAB(c)=$0007 + 3 * 8
#y=(#BACKTAB(c) and $07F8) / 8
#BACKTAB(#y+1)=$0007 + 3 * 8
GOTO loop

 

Can be turned into,

loop:
  #BACKTAB(c) = FormatGromCard(3) + CS_WHITE
  #y = (#BACKTAB(c) and CS_CARD_DATA_MASK) / 8
  #BACKTAB(#y + 1) = FormatGromCard(3) + CS_WHITE
GOTO loop

Also, one more thing related to something in your older comment:  the need for WAIT.

 

As I described in another message, the STIC (video co-processor) interrupts the CPU 60 times a second, upon the raster's "vertical blanking" (VBLANK) period, as it gets ready to draw a new video frame.  During this period, the CPU has access to all graphics sub-systems briefly, GRAM, Sprites, etc.

 

When the VBLANK period concludes, the STIC takes over control of the graphics system again and composes the video frame.  It does this by reading the BACKTAB one row at a time, from top to bottom.  Obviously, any card in the BACKTAB that needs it, must be updated before the STIC gets to it and reads it.

 

Because IntyBASIC handles the VBLANK and graphics access complexity for you, you can never know exactly in which phase the STIC is in, nor whether it is about to draw -- or has already completed drawing -- the frame.

 

It seems that in your original code, you just happen to write to the BACKTAB after the STIC read it's data and composed the frame.  Consequently, you then have to wait until the next frame (i.e., the next VBLANK interrupt) for your changes to take effect.  The WAIT statement does precisely that.

 

The way we typically handle this bit of oddity is to try to align our game loop (especially our drawing updates) to the STIC's video signal by calling WAIT at the top of the loop.

 

Something like:

MainLoop:

  ' Start a new frame
  WAIT

  ' Do Gamey Stuff ...
  ' -------------------
    ' Check for user input
    ' Update GRAM & sprite attributes
    ' Update background
    ' Update game state

Goto Loop

 

Another way to think about it is that you should bunch up all your graphics handling code, including updates to the BACKTAB, and precede them all by a WAIT.  That should give you some time to get your changes in before the STIC composes the frame.

 

If anything is not clear, or sounds too technical, just let me know.

 

    dZ.

 

[Alkadian]

@DZ-Jay, thanks a lot for your further very clear explanations! They are always very helpful! Your notes regarding the WAIT made a lot of sense to me thanks for clarifying that!

 

You are absolutely right about the use of Constants.bas. At the moment I am using the magic numbers as I am still learning the actual meaning of them. Once I will digest it I will definitely switch to the Constants.bas. As you rightly say it makes the code a lot easier to read and maintenable. Thanks a lot for for rewriting it for me. Much appreciated!

 

I have a question, if I may. Would it be possible to use the PRINT function to print the contents of a variable? Something like:

 

PRINT AT 7 COLOR 6, "Contents of variable y" 

 

Thanks so much! You guys are a treasure here!

Edited September 24 by Alkadian
Added more text

[+DZ-Jay]

26 minutes ago, Alkadian said:

@DZ-Jay, thanks a lot for your further very clear explanations! They are always very helpful! Your notes regarding the WAIT made a lot of sense to me thanks for clarifying that!

 

You are absolutely right about the use of Constants.bas. At the moment I am using the magic numbers as I am still learning the actual meaning of them. Once I will digest it I will definitely switch to the Constants.bas. As you rightly say it makes the code a lot easier to read and maintenable. Thanks a lot for for rewriting it for me. Much appreciated!

 

No worries, I understand.

 

26 minutes ago, Alkadian said:

I have a question, if I may. Would it be possible to use the PRINT function to print the contents of a variable? Something like:

 

PRINT AT 7 COLOR 6, "Contents of variable y" 

 

Thanks so much! You guys are a treasure here!

 

Of course!  Just follow it with a comma and the variable:

PRINT AT ScreenPos(7, 0) COLOR CS_YELLOW, "Contents of variable y:", y

 

Just bear in mind that it will treat all variables as if they were characters and try to convert them to a GROM or GRAM card.

 

If you want IntyBASIC to interpret the variable as a number -- essentially converting it to a decimal numeric string -- you need to use the "<>" directive, as described in the IntyBASIC manual:

  PRINT <>expr          ' Simple number
  PRINT <const>expr     ' Right-aligned with zeroes to 'const' size.
  PRINT <.const>expr    ' Right-aligned with spaces to 'const' size.

 

So, for your example above, if "y" is numeric, you can use:

PRINT AT ScreenPos(7, 0) COLOR CS_YELLOW, "Contents of variable y:", <>y

 

For scores and such which typically have a specific field size, prefixed with zeroes or spaces, you use one of the other two variations:

' Print score in a four-digit string, with leading zeros
PRINT AT ScreenPos(12, 0) COLOR CS_RED, "P1:", <4>score

 

What happens if you forget the "<>" modifier?  The contents of the variable will be interpreted as a card number, multiplied by 8, and indexed into either GRAM or GROM, wherever it may appear to point.  In other words, the arguments to PRINT AT after the position are used to compose a BACKTAB card data word, for instance:

' The following:
'   PRINT AT ScreenPos(7) COLOR CS_YELLOW, "Contents of variable y:", y
' is the same as:
#Backtab(7) = CS_YELLOW + (y * 8)

 

So ... be careful with that.

 

     -dZ.

[Alkadian]

17 minutes ago, DZ-Jay said:

 

No worries, I understand.

 

 

Of course!  Just follow it with a comma and the variable:

PRINT AT ScreenPos(7, 0) COLOR CS_YELLOW, "Contents of variable y:", y

 

Just bear in mind that it will treat all variables as if they were characters and try to convert them to a GROM or GRAM card.

 

If you want IntyBASIC to interpret the variable as a number -- essentially converting it to a decimal numeric string -- you need to use the "<>" directive, as described in the IntyBASIC manual:

  PRINT <>expr          ' Simple number
  PRINT <const>expr     ' Right-aligned with zeroes to 'const' size.
  PRINT <.const>expr    ' Right-aligned with spaces to 'const' size.

 

So, for your example above, if "y" is numeric, you can use:

PRINT AT ScreenPos(7, 0) COLOR CS_YELLOW, "Contents of variable y:", <>y

 

For scores and such which typically have a specific field size, prefixed with zeroes or spaces, you use one of the other two variations:

' Print score in a four-digit string, with leading zeros
PRINT AT ScreenPos(12, 0) COLOR CS_RED, "P1:", <4>score

 

What happens if you forget the "<>" modifier?  The contents of the variable will be interpreted as a card number, multiplied by 8, and indexed into either GRAM or GROM, wherever it may appear to point.  In other words, the arguments to PRINT AT after the position are used to compose a BACKTAB card data word, for instance:

' The following:
'   PRINT AT ScreenPos(7) COLOR CS_YELLOW, "Contents of variable y:", y
' is the same as:
#Backtab(7) = CS_YELLOW + (y * 8)

 

So ... be careful with that.

 

     -dZ.

Awesome! Many thanks for providing me with all the required information. I will experiment and i will post back if I struggle with something, if you don't mind

 

Edited September 24 by Alkadian
Typos

[+DZ-Jay]

1 minute ago, Alkadian said:

Awesome! Many thanks for providing me with all the required information. I will experiment and i will post back if I struggle with something, if you don't mind

 

 

Of course I do not mind.  Post all the questions you want.  I will suggest, however, that you post separate questions in separate threads -- that is, unless they are truly related.  That makes it easier for others to find, and builds up a knowledge base. :)

 

In any case, to be honest, there are no rules around here -- just post as many questions as you'd like.

 

     -dZ.

[Alkadian]

3 minutes ago, DZ-Jay said:

 

Of course I do not mind.  Post all the questions you want.  I will suggest, however, that you post separate questions in separate threads -- that is, unless they are truly related.  That makes it easier for others to find, and builds up a knowledge base.

 

In any case, to be honest, there are no rules around here -- just post as many questions as you'd like.

 

     -dZ.

Thanks I will! Agreed about the separate thread, it makes sense.