How does this work regarding PRINT "\256"

[8bitwidgets.com]

PRINT AT 0 COLOR 7     'color of background objects
FOR c = 1 TO 20
PRINT "\256"
NEXT c

 

I understand this makes a line across the screen..  if i change the AT 0 to say..  AT 60.. the line moves down (though part of it still draws up top..  

I feel like the main mystery is what the heck is "\256"?  When I change that all kinds of weird stuff starts to happen to the line..  

 

I believe I understand the FOR c stuff.. and NEXT c.. basically looping this 20 times.. but the the 256 stuff is not clear.  

 

I've done some tinkering and it seems like maybe this is some kind of list of symbols that can be called on?  is there a map of what all of these (apparently hundreds?) are by number?  

 

 

/256

 

 

/257

Edited September 5, 2021 by Caleb Garner

[+nanochess]

The backslash character means a numerical code for the character (or card).

 

If you replace \256 for \33 you'll see twenty A letters drawn horizontally on the screen.

 

The Intellivision has a GROM containing 256 predefined characters.

 

However it happens that by simple arithmetic of multiplying by 8, the 257th character (\256) is located into the GRAM, which is the place were are placed 64 definable characters.

 

This way the \256 to \319 codes refer to the GRAM cards 0-63 that can be defined using the DEFINE statement of IntyBASIC.

 

There is another advantage of using PRINT with this code. You can control the COLOR without resorting to using bitmasks.

 

[8bitwidgets.com]

Awesome @nanochess this is very cool and wow what a great thing to have in rom.. prefab graphics ready to go.  Kinda reminds me of the Odyssey 2, but obviously much better!  

 

 

[8bitwidgets.com]

7 minutes ago, nanochess said:

the GRAM cards 0-63 that can be defined using the DEFINE statement of IntyBASIC.

could you explain that more?  \256 through 319 can be defined..  as in effectively overwritting the graphic that is the default in that slot?  so for example.. i could replace \256 by defining the graphics from the smiley face example earlier in your book?    

 

if your game of ball example you call on 256 through 259 but those are beyond the GROM?  256 is a solid block, so that makes sense.. but what default images are in 257?  i don't recall in the program you defining what would be the shape at 257.  

 

 

[+nanochess]

14 minutes ago, Caleb Garner said:

could you explain that more?  \256 through 319 can be defined..  as in effectively overwritting the graphic that is the default in that slot?  so for example.. i could replace \256 by defining the graphics from the smiley face example earlier in your book?    

 

if your game of ball example you call on 256 through 259 but those are beyond the GROM?  256 is a solid block, so that makes sense.. but what default images are in 257?  i don't recall in the program you defining what would be the shape at 257.  

 

 

No. The GROM only contains the shapes for 0 to 255 (GROM means Graphic-Read-Only-Memory)

 

IntyBASIC uses (abuses?) the fact that arithmetically the number 256 triggers a bit selecting the GRAM access. So using the values 256-319 access the GRAM. (GRAM means Graphic-Random-Access-Memory)

 

The GRAM is a type of Graphic RAM. This RAM in startup contains garbage, I don't know if it is initialized by the Intellivision EXEC. So before using it, you should load it with graphics using the IntyBASIC DEFINE statement.

 

 

[8bitwidgets.com]

3 minutes ago, nanochess said:

So before using it, you should load it with graphics using the IntyBASIC DEFINE statement.

Ooooooo ok I think I get it now.  at the start of a game of ball, you define a series of shapes. 0-7 and THESE are the shapes 256 and up?  

 

If this is right..  i could change the shape of the first BITMAP you have at the start.. and this should change the look of the top and bottom border lines..   ok NOW we're cooking with good grease.. 

 

and the DEFINE parameters are..   0,7 (is the range of GRAM slots to reserve), game_bitmaps_0 (is the same of the "sprite sheet" of images

 

BITMAP "11111111"
BITMAP "11111111"
BITMAP "00000000"
BITMAP "11111111"
BITMAP "00000000"
BITMAP "11111111"
BITMAP "00000000"
BITMAP "11111111"

 

is what i used to create what you see below.  i guess the break in the pattern is because shortly after that another gram graphic overwrites that bad chunk.. which makes sense.   

 

[+DZ-Jay]

5 hours ago, nanochess said:

IntyBASIC uses (abuses?) the fact that arithmetically the number 256 triggers a bit selecting the GRAM access. So using the values 256-319 access the GRAM. (GRAM means Graphic-Random-Access-Memory)

 

Actually, I believe that is by design.  You see, GRAM and GROM are contiguous in the memory map.  The STIC uses the picture card field in the A Register (or BACKTAB) to compose an address to the graphics memory.  This computation is actually more direct than you may imagine.

 

That "GRAM" bit in the register is merely part of the field.  GROM and GRAM happen to be aligned to a 2K boundary.  It works like this:

• GROM starts at $3000 and goes to $37FF
• GRAM starts right after, at $3800 and goes to $3AFF
• The lower byte of the address is represented by the card index multiplied by 8 (because there are 8 bytes for each card, and we want to address cards, not individual bytes)
• And bit #11 ($0800) marks the boundary between GROM and GRAM address space.

This is part of the reason the bit field for the picture card is shifted three bits to the left:  it is very convenient.  Instead of an offset to a memory location, we can treat it as a card index; but in reality, it is an offset aligned to an 8 word boundary.

So you see, IntyBASIC is just leveraging what the Mattel engineers so cleverly designed.

 

   dZ.

[+DZ-Jay]

6 hours ago, Caleb Garner said:

Awesome @nanochess this is very cool and wow what a great thing to have in rom.. prefab graphics ready to go.  Kinda reminds me of the Odyssey 2, but obviously much better!  

 

 

Be mindful that those extra GROM pictures following the ASCII set, are only available in Color Stack mode (Mode #0).

 

In FG/BG mode, only the first 64 pictures are available -- and of course, the entirety of GRAM, which is always available.

 

    dZ.

[+DZ-Jay]

6 hours ago, Caleb Garner said:

Ooooooo ok I think I get it now.  at the start of a game of ball, you define a series of shapes. 0-7 and THESE are the shapes 256 and up?  
 

Yes.  Typically, we treat those shapes as "starting at zero in GRAM"; even though, numerically, as you see, they start at 256.  That's just an idiosyncrasy of IntyBASIC's PRINT statement that allows direct access to graphics cards with a single number.

 

Quote

If this is right..  i could change the shape of the first BITMAP you have at the start.. and this should change the look of the top and bottom border lines..   ok NOW we're cooking with good grease.. 

 

Yes! ??
 

Quote

and the DEFINE parameters are..   0,7 (is the range of GRAM slots to reserve), game_bitmaps_0 (is the same of the "sprite sheet" of images

The DEFINE statement takes three arguments:

DEFINE <starting card number>, <total cards>, <source data>

That example then sets the arguments like this:

• Starting card number: zero
• Total cards: 7
• Source data: game_bitmaps_0

So, it will load seven 8x8 cards from a data table labeled "game_bitmaps_0," and store them in GRAM starting at card index #0.

 

Quote

 

BITMAP "11111111"
BITMAP "11111111"
BITMAP "00000000"
BITMAP "11111111"
BITMAP "00000000"
BITMAP "11111111"
BITMAP "00000000"
BITMAP "11111111"

That is the definition of one card (8 x 8-bit bytes).

 

Quote

is what i used to create what you see below.

 

The loop prints card \256 across the top of the screen, horizontally.  As mentioned below, this is a magic value that represents card #0 in GRAM.  You can decode it like this:

card / 256 - 1 = index

where "card" in this case is 256, "index" results in zero.

Because you changed the bitmap pattern of the first card in the data table from a solid horizontal bar, to a pattern of alternating solid horizontal bars, this is reflected in the screen, as you can see.

Quote

i guess the break in the pattern is because shortly after that another gram graphic overwrites that bad chunk.. which makes sense.   

 

It is not a bad chunk at all.  That "break" is actually the first instance of the vertical "net" pattern.  It just happens that the pattern is defined as a vertical dashed line, in the 4th card (\259) of the data table:

BITMAP "00000001"
BITMAP "00000000"
BITMAP "00000000"
BITMAP "00000001"
BITMAP "00000001"
BITMAP "00000000"
BITMAP "00000000"
BITMAP "00000001"

That card is printed in the final loop, ten times vertically.

 

Notice that the picture defines a dotted-line pattern aligned to the right of the card.  This means that all the pixels to the left are blank.  That blank part is what you see in the gap above.  The first dotted-line pattern can be seen to the right edge of that card, touching the next horizontal alternating lines pattern.

 

If you change that last loop to start at 2 instead of 1, it'll probably look more like what you expected -- it would not overwrite the horizontal bars pattern and start below it.

 

    dZ.

 

Edited September 5, 2021 by DZ-Jay

[8bitwidgets.com]

1 hour ago, DZ-Jay said:

 That "break" is actually the first instance of the vertical "net" pattern.

I did a bunch of variations after reading this and confirmed what i suspected..  which you further confirmed.. feeling good about all this though i'm still not so confident about how i could use them to make scenes of my own, but getting there.. 

 

 

I made that "net" wider on purpose just to make it more obvious where one ended and the other began.. and just used different colors to better identify. 

 

 

2 hours ago, DZ-Jay said:

IntyBASIC is just leveraging what the Mattel engineers so cleverly designed.

 

it does feel intentional just based on how it's laid out for sure and i dig it.  

 

7 hours ago, nanochess said:

\256 through 319 can be defined.. 

and I'm thinking that these can be redefined dynamically in the game meaning you can have up to 64 unique cards on screen, but you could at any given time redefine any one of those to meet new game requirements down the road like if you wanted to make more levels that had a lot of visual variation.  

 

2 hours ago, DZ-Jay said:

are only available in Color Stack mode (Mode #0).

there are two color modes right?  and mode #0 is the basic one that limits you to 8 colors right?  

 

2 hours ago, DZ-Jay said:

In FG/BG mode, only the first 64 pictures are available

I think i'm going to avoid the other color modes for awhile and work within the basic for awhile.. 

 

1 hour ago, DZ-Jay said:

DEFINE <starting card number>, <total cards>, <source data>

ah ok yes that makes much more sense.. if i was thinking (it was late) 0-7 would be 8 bitmaps and the pong game only has 7

 

1 hour ago, DZ-Jay said:

GRAM starting at card index #0

why would you need to define this?  wouldn't you just put all your (up too) 64 symbols in that one space?  or does this go back to my assumption that you can redefine all (or some) cards throughout the game?  

Edited September 5, 2021 by Caleb Garner

[+DZ-Jay]

42 minutes ago, Caleb Garner said:

and I'm thinking that these can be redefined dynamically in the game meaning you can have up to 64 unique cards on screen, but you could at any given time redefine any one of those to meet new game requirements down the road like if you wanted to make more levels that had a lot of visual variation.  

Yes, for sure:  The 64 GRAM picture cards are for the program to define and redefine as necessary.  Those 64 cards represent the set of custom tiles you can have at any given point in your program, available for both sprites and background scenery.

 

What you then describe is a common technique:  you reserve a chunk of GRAM for cards that describe your play-field.  Then, it's just a matter of loading the specific set of cards needed for each level or game phase.  That's how I do it in my games as well.

 

Moreover, one common way to implement sprite animations is to have the MOB point to a specific GRAM card (via its A Register, remember?), and then periodically switching the actual underlying picture that it points to in GRAM, on subsequent frames.  That's actually how all I do most of the animations in my game.

 

Just know that those 64 cards are all you've got at any one time, and they must be shared among sprites and background graphics -- but they are completely under your program's control.

 

Quote

there are two color modes right?  and mode #0 is the basic one that limits you to 8 colors right?  

Er ... it's a bit more complex than that.  See my previous descriptions on the modes in another thread, or take a look at their descriptions in the "stic.txt" document.  Both modes have pros and cons.  It boils down to this:

• Color Stack (Mode #0):  More graphics, less color control.
• Foreground/Background (Mode #1):  More color control, less graphics.

They are both very useful and powerful in their own ways.  Most IntyBASIC programmers focus on FG/BG mode because it is easier to work with, and very similar to how other platforms manage color.

 

However, Color Stack mode offers full access to the GROM set, which includes numerous geometric shapes and lines that can be used to fill in more complex scenes.  This flexibility comes at the cost of more difficulty in managing colors.  Note that I haven't said it offers less colors -- that's an important distinction.  You can have very colorful scenes using all 16 colors with the Color Stack; it's just a bit more complex to do so.

 

For example,

 

I count 10 colors in that scene, some of which are in the "pastel" (high) color set:

1. Olive
2. Dark Green
3. Light Green
4. Red
5. Lilac
6. Light Blue
7. Blue
8. Orange
9. Yellow
10. White

That scene is done purely in Color Stack mode, employing various tricks, like reverse-video characters.  It uses also the full GRAM card set and a bunch of GROM cards in order to add more detail.  It even uses a couple of MOBs to add those "serif" decorations on the "R"s and other letters.

 

All that to say, do not be afraid of any of the screen modes, and do not assume that either is superior or inferior than the other -- they are different, and they both have their strengths and weaknesses. (Although mode #1 is arguably easier to learn than mode #0.)

 

Quote

I think i'm going to avoid the other color modes for awhile and work within the basic for awhile.. 

Actually, the "basic" mode (i.e., the simpler to use), is mode #1.

 

Quote

ah ok yes that makes much more sense.. if i was thinking (it was late) 0-7 would be 8 bitmaps and the pong game only has 7

Right:  it's a total of 7, starting on slot #0, so from 0 to 6.

 

Quote

why would you need to define this?  wouldn't you just put all your (up too) 64 symbols in that one space?  or does this go back to my assumption that you can redefine all (or some) cards throughout the game?  

You need to tell the DEFINE statement where in GRAM you want the cards loaded.  There are 64 slots and you do not need to use them all, nor in any specific order.  It is common to reserve certain slots for different things; say, for text messages, or for sprites, etc.  The DEFINE statement allows you to load a sub-set of GRAM at a time.

 

In this case, the program loads the 7 cards used by the game play-field, paddles, and ball; so it loads them all at the start of GRAM, from card #0 on.  However, it could have just as well loaded them into a higher part of GRAM, or scatter them around it.  It just worked out more convenient this way.

 

For other games, you could separate your sprites and your play-field into distinct card sets and load them separately.  That way, changing the scene for a new level is just as simple as loading a new set of play-field cards to replace the previous ones, without touching the other cards.

 

 

Quote

 

 

Neat-o!  ?

 

   -dZ.

Edited September 5, 2021 by DZ-Jay

[8bitwidgets.com]

22 minutes ago, DZ-Jay said:

64 cards are all you've got at any one time

plus the 256 standard ones to use right? not an either or situation.

 

23 minutes ago, DZ-Jay said:

Both modes have pros and cons. 

do you happen to have any classic game examples that use one or the other?  discs of tron, burgertime, b-17 bomber, night stalker, etc?  Would love to just reference games that use one vs. the other.  I could imagine that would give a great perspective as to which mode I NEED to really understand first. 

 

25 minutes ago, DZ-Jay said:

They are both very useful and powerful in their own ways.

can you change color modes in the same game?  or is this something that is defined up front and forever?  

 

31 minutes ago, DZ-Jay said:

(i.e., the simpler to use), is mode #1

gotcha!  yes i see what you mean now.  

 

32 minutes ago, DZ-Jay said:

It is common to reserve certain slots

is this more for sanity and establishing boundaries?  Like "level wall / obstacles" could be a certain range of the 64 while "enemies / animations" might be in another set of blocks to help keep things organized?  

 

35 minutes ago, DZ-Jay said:

without touching the other cards.

right because i know it would help me just remember and give me further constraints to work within when building out content.  

[+DZ-Jay]

49 minutes ago, Caleb Garner said:

plus the 256 standard ones to use right? not an either or situation.

Right, but it depends on the screen mode.  FG/BG mode (the easier one) only supports 64 of the GROM set, and that's only the text and punctuation characters.  These are of limited use for purely graphic scenery.

 

But, yes, both the built-in GROM and customizable GRAM are available at once.  It's just that most people count on GRAM only because they use FG/BG mode, and therefore expect to use GROM only for text.

 

Quote

do you happen to have any classic game examples that use one or the other?  discs of tron, burgertime, b-17 bomber, night stalker, etc?  Would love to just reference games that use one vs. the other.  I could imagine that would give a great perspective as to which mode I NEED to really understand first. 

Unfortunately, I do not have examples at hand.

 

That said, my recommendation is to start with FG/BG mode, just because it is easier.  You have so many other things going on, and so many other complex parts to deal with, that you can defer the complexity of Color Stack to a later time.

 

Also, as stated before, FG/BG is more popular among IntyBASIC programmers; so more people may be able to help you use it.

 

Quote

can you change color modes in the same game?  or is this something that is defined up front and forever?  

You can change color modes at any time in your game.  In IntyBASIC, you do this with the "MODE" statement, which will then switch modes on the next frame.

 

Quote

is this more for sanity and establishing boundaries?  Like "level wall / obstacles" could be a certain range of the 64 while "enemies / animations" might be in another set of blocks to help keep things organized?  

 

Personally, I am obsessive with the organization and categorization of my code and data structures, and I try to keep them tidy and organized, but that's just me.  That said, the more common reason for separating blocks of GRAM is to be able to load independent sets at various times, as your program needs.  But that's just a matter of preference.

 

Nothing stops you from loading the full GRAM at once with all its assets at any one time (well, actually, there are technical limitations that force you to spread this across multiple frames, but this is not germane to the issue at hand).  However, you may instead want to just load, say, new sprites for enemies without having to reload all cards used for the background, if they did not change.

 

 

Quote

right because i know it would help me just remember and give me further constraints to work within when building out content.  

Well, what I meant to say is what I posed in my previous sentence above.  Let me illustrate it with an example.

 

Suppose your game has a level that, depending on the advancement of the player, may spawn different enemies at any given time.  In this case, the background scenery remains the same, but the enemy sprites are different.

 

You could create an entire GRAM set of cards for all your assets, including within it -- in no particular order -- pictures for drawing trees and buildings and clouds, and other background stuff.  Scattered in there, you may also include the pictures for your enemy tanks. 

 

You then use the DEFINE statement across a few frames during the initialization of a game level, to load the entire 64 card set into GRAM, and proceed to use them as normal.

 

As the player shoots down the enemy tanks, the game switches to a more challenging mode and spawns enemy fighter planes after our player.  So you need to load the graphics for the fighter planes into GRAM.  There's no more space, but because you do not need the tank pictures anymore, you can replace them.  So, what do you do?

 

You could define an entire new set of 64 cards for the same level with the new enemy pictures.  However, this would be wasteful because most (or all) of the background cards remain the same, so now they are duplicated, wasting precious space in the cartridge ROM.

 

Alternatively, you could target the specific slots where your enemy tank pictures are stored in GRAM and replace each one with an enemy fighter plane picture.  If the slots are all scattered willy-nilly in GRAM, this may be difficult to do without knowing precisely where they are.  You could keep a separate table that tells you the index of each enemy card, but then you'll have to decode each one, compose pointers, and load each one individually.  It just gets ugly and more complicated from there on.

 

However, if you were to store all your enemy tank pictures contiguously in GRAM, and keep track somewhere precisely where your store that set of cards, then that task becomes easier.

 

It becomes easier still if you actually define all your enemy pictures as their own data tables in your program ROM; because then you can just load an entire set of enemy pictures at any time to the same place in GRAM -- and as long as the sets are all the same size, you won't even have to think about it too much. ?

 

You could have a table with pictures of tanks, another with fighter planes, and yet another with aliens, or slugs, or whatever -- and switching them is a matter of loading each set using a DEFINE statement targeted at a given block in GRAM.

 

That's just one example, but it should illustrate why you may want to treat GRAM in a similar way that you treat any other RAM.  After all, you define variables for specific purposes, and arrays with contiguous blocks of RAM for other.  You don't treat the entirety of RAM as one huge array, haphazardly populated with values, and then deal with the complexity of finding a specific value among a sea of other unrelated ones.  You could, but that would just be a nightmare to manage.

 

   -dZ.

Edited September 5, 2021 by DZ-Jay

[8bitwidgets.com]

5 hours ago, DZ-Jay said:

GRAM only because they use FG/BG mode

ah ok so for mode 0 gram is relied on more.  glad it's that way and not the other way around..  living without most of the GROMs is fine.  ]

 

5 hours ago, DZ-Jay said:

my recommendation is to start with FG/BG mode

yep sounds like that's the way to go till i'm more comfortable doing other more fundamental stuff.. like how the heck that pong ball moves in the books example!  i'm happy i understand the basic layout stuff, but oh boy.. a lot to unpack there.. 

 

5 hours ago, DZ-Jay said:

instead want to just load, say, new sprites

 yea i definitely agree that i'm going to work on my game "i, killbot" which shouldn't need more than the 8 mobs..  i won't need anything for background except basic room walls / doorways (think berzerk)..  

 

5 hours ago, DZ-Jay said:

difficult to do without knowing precisely where they are.

ok yea that makes sense.  completely get that strategy.