Making Backgrounds and Shapes (IntyBASIC-ish)

[First Spear]

I was trying-out the tutorial from Tarzilla. Very good stuff. Thanks!

 

My next move is kind of a Paint.NET question, but I'm open to doing it with any tool - I am now interested in taking images I have already drawn, cutting them down to Intellivision size, and having a tool pre-dither them using the Intv palette so IntyColor will simply convert them into Color Stack or F/B backgrounds without throwing errors.

 

Can anyone recommend a process to do that?

 

Thanks.

[First Spear]

Playing around with Image Magick. No success so far...

[+Tarzilla]

I was trying-out the tutorial from Tarzilla. Very good stuff. Thanks!

 

My next move is kind of a Paint.NET question, but I'm open to doing it with any tool - I am now interested in taking images I have already drawn, cutting them down to Intellivision size, and having a tool pre-dither them using the Intv palette so IntyColor will simply convert them into Color Stack or F/B backgrounds without throwing errors.

 

Can anyone recommend a process to do that?

 

Thanks.

There is no easy way to convert an existing image, lots of trial and error. After awhile you'll start to think in 2 colors allowed per tile and how to disguise changes on 8x8 boundaries and reuse tiles to keep under the 64 card limit.

 

Take a copy of your image, resize it to 160 by 96. Play with the Re-sampling options of the Image-->Resize menu. Forget any hope of auto dithering. If you drew them yourself as a line drawing without color you'll have to most success sizing them down. An example image would allow us to give better advice.

[intvnut]

Hmmm... I'm not sure it's that straightforward. The issue is that the Intellivision has a couple severe limitations that require creativity to get beyond:

• Only two unique colors in a given 8x8 square. And it's worse than that...
  • In FGBG mode, one of the colors is limited to 8 of the 16 possible while the other can use all 16.
  • In CSTK mode, one of the colors comes from the color stack, and the color stack only holds 4 unique colors and only lets you access them in a rotating sequence.
  • In either mode, you can use MOBs to "patch" areas with high detail, but you only get 8 MOBs
• Only 64 GRAM cards. That's enough to cover about 1/4th of the visible screen. So, you need to either:
  • Adjust elements of your graphics to match existing patterns in GROM
  • Adjust your graphics so you can reuse the same GRAM tile multiple times
  • Not fill the entire display
  • Some combination of the above

 

If it's a 2-color image and smaller than 64 pixels by 64 pixels, then it's trivial because you can just map it to bits in GRAM. Going up from there requires a bit of skill and art. Heck, even 2 and 3 color images larger than that are a trick. I know I took a few artistic liberties with some of the splash screens and title screens I helped Elektronite with. Go buy a copy of Kroz if you want to see how they turned out.

Edited November 30, 2014 by intvnut

[intvnut]

If you study the LTO Logo splash screen, you'll see what I mean about reused GRAM, etc... It's a lot of work to leverage the 8x8 tile boundaries in a way that doesn't make them obvious, but still helps you.

 

[intvnut]

FWIW, in some conversions, I used GIMP to do the conversion, with one layer holding a grid, and others holding different "planes" of the graphic (such as backdrop vs. MOB patches). It was exceedingly tedious, but moderately effective.

 

Basically, I treated GIMP as a form of "tracing paper", drawing the Intellivision image over whatever it was I was trying to approximate. That's how I generated the Jean Luc image I've posted previously, FWIW. (And that thing ate pretty much all of the GRAM, and only covers about 25% of the screen, if that.)

 

Edited November 30, 2014 by intvnut

[+DZ-Jay]

I generate my background graphics in a similar way to intvnut, mostly by trial and error. I start with a general idea of what I want to accomplish, perhaps even a sketch showing the positions. I then try to use creative ways to adapt the screen and produce a similar result.

 

I've tried using GiMP and Pixelmator to "convert" whole scenes, but it's mostly a manual process, not automatic. Like intvnut, the underlying image becomes more of a base on which to "trace" the final Intellivision scene. I've worked mostly with Color Stack, because it allows me to utilize the full GROM complement.

 

About the only automated part is when I convert my hand-drawn "ASCII" scene into actual data statements for the Intellivision. The source itself is a manually composed text file that includes "." and "#" symbols to draw the scene, and some metadata on the use of colours per tile. I've built a set of scripts that automatically convert these files into data that my programs then can load and process.

 

If I were to make suggestions on what art-related tools could be useful for Intellivision games, it's this:

• A graphics drawing package that has knowledge of the colour modes and limitations of the Intellivision and that works within those constraints.
• It should support layering your Intellivision-style scene over a higher-res one for "tracing" while you draw.
• It rips the final scene into unique tiles and generates an output file containing data statements for programs to use.
• If using Color Stack, the graphics program should automatically detect GROM tiles and use those instead when generating the final output.
• It should also have a mode where it detects and recommends tiles that are "similar" to GROM tiles or to one another, so that the artist could choose whether to modify them into common tiles, and reduce the number of used GRAM cards.
• It should also generate output in ASCII format, so that other tools can incorporate it or process it in custom, program-specific ways.

My personal recommendation to would-be Intellivision graphic artists is: Always start with artwork and try to turn it into tiles, and never vice-versa. If you adapt tiles to fit your scene, it is bound to look more natural and organic, than if you try to compose a full scene made out of cool-looking tiles and patterns.

 

I'll post this video again, partly because it is a apropos to this discussion and shows how I work, partly because it is the season for it, but mostly because it is just plain cool.

 

http://vimeo.com/54165189

 

 

 

EDIT: Fixed embedded video.

Edited November 30, 2014 by DZ-Jay

[+nanochess]

I was trying-out the tutorial from Tarzilla. Very good stuff. Thanks!

 

My next move is kind of a Paint.NET question, but I'm open to doing it with any tool - I am now interested in taking images I have already drawn, cutting them down to Intellivision size, and having a tool pre-dither them using the Intv palette so IntyColor will simply convert them into Color Stack or F/B backgrounds without throwing errors.

 

Can anyone recommend a process to do that?

 

Thanks.

 

I sometimes use Paint.Net to convert to simple bicolor images using this technique.

 

1. Convert to grayscale (monocromatic)

2. Use the brightness/contrast tool, move contrast all to right, and adjust brightness, you'll get a bitmap of only black and white, easy to colorize and/or convert.

[First Spear]

 

I sometimes use Paint.Net to convert to simple bicolor images using this technique.

 

1. Convert to grayscale (monocromatic)

2. Use the brightness/contrast tool, move contrast all to right, and adjust brightness, you'll get a bitmap of only black and white, easy to colorize and/or convert.

 

Thanks to everyone for adding their thoughts on this topic!

 

I think I did not understand enough about Intellivision graphics when I started. I still don't, but now I know what I don't know.

 

I have Paint Shop Pro X6, Paint.NET, and Image Magick. I was thinking that I could take a simple image (cut to 160x96), use the palette included with Tarzilla's tutorial to create a new, limited palette, and then use PSP or PN or IM to let them dither-down the image to the 16 colors allowed, and then wash the .bmp through IntyColor. I still think my process is workable, I just don't know enough of my tool capabilities yet.

 

Intvnut mentioned that there are only 2 colors allowed in an 8x8 square... Not sure I understand that.

 

If I wanted to make a "slideshow" of Intellivision graphics, say a still life photo, a sunrise, a pair of sunglasses, etc, what mode would I use to make a 160x96 image with 16 colors (no MOBs)?

 

Thanks.

[+Tarzilla]

Take a look at this screen that I created using paint.net.

 

 

Notice how no block has more than two colors?

 

That is the Intellivision's limit. Technically it is even more limited due to color combos of primary and secondary as was mentioned above. As well, running it thru Intycolor will tell you if you have 64 or less unique cards, forcing you to go back and cut back some detail and conprimise by reusing some cards more than once. This image doesn't have that problem, but I did an new title Alps mountain scene for the Goatnom game that uses 60 cards and still had to use MOBs to fill some transitions requiring more than two colors.per block.

 

Realistically trying to do a slide show wouldn't really be worth the time because unlike some Atari 8-bit and Colecovision things I've seen where the image was converted using a tool, you are going to be doing a lot of hand tuning.

[First Spear]

[snip]

That is the Intellivision's limit. Technically it is even more limited due to color combos of primary and secondary as was mentioned above. As well, running it thru Intycolor will tell you if you have 64 or less unique cards, forcing you to go back and cut back some detail and conprimise by reusing some cards more than once.[snip]

 

OK.... So then maybe a kind of slideshow of 160x96 images is possible if I dither it to black+white (or high-contrasting as nanochess mentioned), then run the .bmp through intycolor to determine if more then 64 8x8 sections are unique, then when that rule is satisfied I can then go back and use grey from the palette in place of black if possible.

 

?

[intvnut]

Intvnut mentioned that there are only 2 colors allowed in an 8x8 square... Not sure I understand that.

 

I should have posted my images earlier with a grid overlaid. Here they are again w/ a grid. You may need to click on them to see the grid clearly.

 

 

The Intellivision display is a tile-oriented display. Each tile pulls a single 8x8 bitmap out of GRAM or GROM. GROM has 256 preprogrammed pictures (including the beloved Intellivision font), and GRAM holds up to 64 pictures.

 

Each of these 8x8 bitmaps is 1 bit per pixel. That gives you the ability to select between a "foreground" color (bits set to 1) and a "background" color (bits set to 0) with that bitmap.

 

That's where the "two colors per 8x8 square" restriction comes in.

 

In FGBG mode (aka F/B mode) you can select the foreground from colors 0-7 and the background from colors 0-15. In CSTK mode, you can select the foreground from all 16 colors, but the background color comes from a 4 entry color stack. (Note: You're limited to foreground colors 0-7 if the tile comes from GROM.)

 

If you look closely at the gridded images I posted, you'll see places where I've "nudged" the artwork to fit better within the grid structure. There are also places where I have three colors within an 8x8. In those places, I've used a MOB overlay.

 

What I did when making the Jean Luc image, I started with a photograph, and then I used GIMP's "Posterize" filter to reduce the colors and get a good starting point. I worked from there, nudging and editing until I ended up with something recognizable that still fit within the Intellivision's capabilities and GRAM.

 

For your slideshow, you'll probably have to do something similar.

 

EDIT: Speaking of grey levels and dithering... you might take a look a what I did for the dithered sky in the LTO Sign GIF.

 

EDIT 2: Blank 8x8 tiles are especially useful for making larger images. There's a surprising amount of blank space in Jean Luc's face, for example. The GROM has an all-bits-0 tile and an all-bits-1 tile which helps.

Edited November 30, 2014 by intvnut

[First Spear]

Intvnut said

 

 

 

The Intellivision display is a tile-oriented display. Each tile pulls a single 8x8 bitmap out of GRAM or GROM. GROM has 256 preprogrammed pictures (including the beloved Intellivision font), and GRAM holds up to 64 pictures.

 

So I have 64 tiles to contain the various "puzzle pieces" that might make up my background, correct? This is why in Tarzilla's tutorial he mentioned tweaking images to re-use cards, correct? If I have something like a lot of curves (eg a bowl with fruit in it), and I can't get the shapes collected in 64 cards and I can't use preprogrammed images from ROM, I'm out of luck, correct?

 

 

and

 

 

http://www.intellivisionbrasil.com/.%5Ctutor-soft%5CTutorial_WhitePaper-IntellivisionProgramming2.pdf states that

 

 

The second scheme is called "Color Stack Mode" (CS). In this scheme, we define a circular stack of 4 colors. Those colors may be any primary or pastel ones, but now the catch is different: one of the colors of each card HAS TO BE either one color pulled from the stack, or the next one in sequence. That way it is possible to have 2 pastels on the same card, which is not possible through the F/B scheme.

 

I don't understand the "next one in sequence" statement. Isn't that the same as just saying that an image tile can only have 4 colors?

 

 

Thanks again to all for working hard to get me some clues.

[catsfolly]

 

I don't understand the "next one in sequence" statement. Isn't that the same as just saying that an image tile can only have 4 colors?

 

 

Thanks again to all for working hard to get me some clues.

There are four registers in the STIC chip that make up the "color stack". The program can set each of these four registers to any color.

For example, I could set:

 

The first color = red

the second color = green

the third color = blue

the fourth color = white

 

Then, on my color stack mode display, the background color will initially be red, the first color in the "stack".

 

If I set a bit in one of the backtab memory (card) locations that is designated "advance color stack", then the background color will switch to the next color in the "stack". (In this example, since we were displaying the first color red, the background color will change to the second color, green, for this card and all following cards.)

 

If one of the following cards has the "advance color stack" bit set, the background color will advance to the third color (in this example, blue).

 

Then, If one of the following cards has the "advance color stack" bit set, the background color will advance to the fourth color (in this example, white).

 

If one of the following cards has the "advance color stack" bit set, the background color will switch back to the to the first color (in this example, red).

 

Catsfolly

[intvnut]

There are four registers in the STIC chip that make up the "color stack". The program can set each of these four registers to any color.

For example, I could set:

 

The first color = red

the second color = green

the third color = blue

the fourth color = white

 

Then, on my color stack mode display, the background color will initially be red, the first color in the "stack".

 

If I set a bit in one of the backtab memory (card) locations that is designated "advance color stack", then the background color will switch to the next color in the "stack". (In this example, since we were displaying the first color red, the background color will change to the second color, green, for this card and all following cards.)

 

If one of the following cards has the "advance color stack" bit set, the background color will advance to the third color (in this example, blue).

 

Then, If one of the following cards has the "advance color stack" bit set, the background color will advance to the fourth color (in this example, white).

 

If one of the following cards has the "advance color stack" bit set, the background color will switch back to the to the first color (in this example, red).

 

 

 

Catsfolly pretty much nails it. The only thing I'd add is that everything happens in normal "reading order" on the grid of 20 x 12 cards: left-to-right, top-to-bottom

 

 

Suppose I had a color stack similar to what Catsfolly described, with Red, Green, Blue, and Black. (I changed White to Black, so it'd work in a text-only post.)

 

The following diagram shows what would happen if I set the Advance bit every 5th card. I've indicated that with the letter 'A'. The other cards indicated with 'x' just take the current color-stack color. Each letter is colored with whatever background color the color-stack would have assigned that position.

 

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

xxxxAxxxxAxxxxAxxxxAxxxxA

 

Notice also that the color stack advance affects the card that askes for the advance. That is, the cards with an 'A' have a different background color than the card to their left.

 

This particular pattern is pretty boring. Typically, to make good use of CSTK mode, you divide your image into bands that are dominated by a particular color. For example, if you have a landscape image, you might have "sky", "water", "beach", "grass", and set your color stack to "light blue", "blue", "tan", "green", and put color stack advance bits on the first column of the first row where that background color is needed. Or, for an image such as Jean Luc above, I had "Yellow", "Red", "Black", "Black", and found appropriate places to advance the stack within each row.

 

Color stack does require some creativity to get the most out of it.

 

 

EDIT: One last detail: The terms 'card' and 'tile' are pretty much interchangeable. If you read documentation for other systems, they might also call that construct a "character." All three words refer to an 8x8 bitmap that lives on a grid of such bitmaps.

EDIT2: Noticed I had botched the color stack example above. Fixed it.

 

EDIT3: And to this question:

 

 

I don't understand the "next one in sequence" statement. Isn't that the same as just saying that an image tile can only have 4 colors?

 

In case it isn't abundantly clear, yes, in color stack mode, you are limited to four distinct background colors. The tradeoff is that those four background colors can come from the full set of 16 colors. Foreground colors can also come from all 16 colors (as long as the tile's picture comes from GRAM).

 

In FGBG mode, each tile can pick a different background color from all 16 colors, but only pick a foreground color from 0-7 (the so-called "primary colors"). In FGBG mode, you're also limited to the first 64 tiles in GROM, which prevents you from accessing the graphic pattern tiles and even the lowercase letter tiles.

Edited December 1, 2014 by intvnut

[intvnut]

Intvnut said

 

 

So I have 64 tiles to contain the various "puzzle pieces" that might make up my background, correct? This is why in Tarzilla's tutorial he mentioned tweaking images to re-use cards, correct? If I have something like a lot of curves (eg a bowl with fruit in it), and I can't get the shapes collected in 64 cards and I can't use preprogrammed images from ROM, I'm out of luck, correct?

 

 

Well, this is where the "art" comes in to trump the "science". When I first tried to convert Patrick Stewart's image for the Jean Luc menu, I was way over. Something like 74 or 80 tiles. (Note: I was doing this by hand with the help of GIMP.)

 

The art comes in with nudging bits and pieces of the image to better line up with the grid. For example, go take a look at the Jean Luc picture above. Notice how there's 2 blank yellow squares under his left eye. I made those happen by adjusting the shading elsewhere so that the flat squares looked natural.

 

There's another spot along his jawline, one row below the '3', where there's a bit of a divot inward so that I can have a completely black square.

 

And then there's the odd detail here and there that I tweaked or flattened out. For example, his forehead wasn't that flat when I started. etc.

 

I made similar tweaks for the title screen graphic in Kroz, shifting / modifying elements of the letters around until things snapped in the grid well and I could reuse pieces of letters. The Apogee logo, as boring as it looks, has many such adjustments. (Without them, the Apogee logo would be much smaller on the screen.) Also, the Apogee logo (and parts of Jean Luc's forehead) make use of graphics tiles build into the GROM.

 

So, for your hypothetical bowl of fruit, depending on what was in it you might be able to forgo some shading in places to slot in a solid-colored square, or to adjust some angled transitions to match tiles in GROM. You might be able to make some pieces of fruit slightly larger or smaller or shift them by a pixel this way or that to make things line up better. It really is art trying to make it all work.

[First Spear]

Thanks to all for sharing concepts and examples and being patient with me as I get my head around this.

 

 

 

 

I am going to play with that image as a self-tutorial. It seems to have repeating shapes and total colors are low. I'll come back later with my findings (or more questions). To get the most colors I will start with color stack mode (unless someone wants me to go to FGBG mode).

 

Thanks.

[First Spear]

...and by the way, how is Safecracker done? Those buildings are gorgeous and scrolling on/off the screen. That is background wizardry!

 

 

Edited December 3, 2014 by First Spear

[+DZ-Jay]

...and by the way, how is Safecracker done? Those buildings are gorgeous and scrolling on/off the screen. That is background wizardry!

 

 

 

That is actually quite simple. Most, if not all, the angles are at tile-boundaries, and most of the tiles come from the built-in GROM set. If you compare it to some of the other, more complex screens, you'll notice that it is rather low on detail, i.e., it is mostly composed of solid blocks and two-colour triangles.

 

The scrolling is done by the hardware, while your program draws the next row or column when a card-boundary is crossed.

[First Spear]

 

That is actually quite simple. Most, if not all, the angles are at tile-boundaries, and most of the tiles come from the built-in GROM set. If you compare it to some of the other, more complex screens, you'll notice that it is rather low on detail, i.e., it is mostly composed of solid blocks and two-colour triangles.

 

The scrolling is done by the hardware, while your program draws the next row or column when a card-boundary is crossed.

 

OK, sir, now you have stepped in it.

 

Can you post to the thread a single .bmp that IntyColor will like, along with some IntyBASIC code that shows how to make it scroll and wrap-around? If you're going to shatter my beliefs, please put out some hard evidence.

 

Thanks.

[+DZ-Jay]

OK, sir, now you have stepped in it.

 

Can you post to the thread a single .bmp that IntyColor will like, along with some IntyBASIC code that shows how to make it scroll and wrap-around? If you're going to shatter my beliefs, please put out some hard evidence.

 

Thanks.

Haha! Well played.

 

Unfortunately, I am not an IntyBASIC developer, so I'll leave that to others. I can, however, provide the tile graphics and scene data for it, but it'll have to wait until the week-end.

[+Tarzilla]

OK, sir, now you have stepped in it.

 

Can you post to the thread a single .bmp that IntyColor will like, along with some IntyBASIC code that shows how to make it scroll and wrap-around? If you're going to shatter my beliefs, please put out some hard evidence.

 

Thanks.

Intybasic comes with a scroll.bas sample file that shows you. There is no magic in Intybasic that saves you from understanding how the scrolling hardware works. Draw a screen. Tell the system to hardware scroll in what direction and by how many pixels. Loop. After 8 pixels have moved you have to replace the column or row that is now empty with tiles. The sample uses print commands to replace these tiles Iirc.

[+Tarzilla]

Haha! Well played.

Unfortunately, I am not an IntyBASIC developer, so I'll leave that to others. I can, however, provide the tile graphics and scene data for it, but it'll have to wait until the week-end.

Don't you have some new game that you should be working on :-) and a contest to manage? I have a scrolling sample in IntyBasic I'll post later tonight or tommorow that is more specific to his question.

[+DZ-Jay]

Don't you have some new game that you should be working on :-) and a contest to manage? I have a scrolling sample in IntyBasic I'll post later tonight or tommorow that is more specific to his question.

 

HAHA! Yes, I'm working on both. I merely wanted to show that drawing that city on the Intellivision was really not a big deal, and describe how it is made. But I'll leave it up to your better qualified hands.

 

-dZ.

[intvnut]

 

OK, sir, now you have stepped in it.

 

Can you post to the thread a single .bmp that IntyColor will like, along with some IntyBASIC code that shows how to make it scroll and wrap-around? If you're going to shatter my beliefs, please put out some hard evidence.

 

Thanks.

 

 

Intybasic comes with a scroll.bas sample file that shows you. There is no magic in Intybasic that saves you from understanding how the scrolling hardware works. Draw a screen. Tell the system to hardware scroll in what direction and by how many pixels. Loop. After 8 pixels have moved you have to replace the column or row that is now empty with tiles. The sample uses print commands to replace these tiles Iirc.

 

 

Ok, for what it's worth, jzIntv does come with a (perhaps mediocre) description of how the hardware scrolling works. Here's what comes with SDK-1600.

------------------------------------------------------------------------------
  THE OBJECT FIELD VS. THE DISPLAYED AREA.
------------------------------------------------------------------------------

The STIC provides 8 movable objects.  These objects may be placed
anywhere on a 167 x 105 pixel field (NTSC) or 168 x 104 pixel field (PAL).
This field is larger than the actual display.  (Recall, the display is
159 x 96.)  By default, the object field relates to the displayed area 
like so:

  
              +--------------------------------------------+
              |  OBJECT FIELD outer area                   |
              |   +---------------------------------------+|
              |   |  DISPLAYED AREA of object field       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   |                                       ||
              |   +---------------------------------------+|
              +--------------------------------------------+

Notice that the Object Field starts above and to the left of the
displayed area.  By default, the object field starts 8 pixels to the
left of the display and 8 pixels above the display.  The right edges of
the object field and the displayed area touch each other.

The upper left corner of a MOB can be placed anywhere in the object field.
Because most MOBs are 8x8 pictures, this arrangement allows MOBs to
slide smoothly off the edges of the screen.  

In contrast, the 20x12 matrix of background cards is restricted to the 159
x 96 area in the lower-right corner of the object field.  (Or rather, more
exactly, the 20x12 matrix starts 8 rows below and 8 columns to the right
of the object field.)  This corresponds to the default displayed area.
The remaining portion of the object field is blank -- that is, it is
filled in with the background color, as defined by the given display mode.

Notice that I keep saying "default" in the above discussion when referring
to the displayed areas.  It is possible to move the object field relative
to the displayed area.  This is done using the "horizontal delay" and
"vertical delay" registers.  The effect of these registers is to move the
object field to the right or downwards relative to the displayed area.
At the maximum "delay", the object field has the following orientation
relative to the displayed area:

                 +--------------------------------------------+
                 |+---------------------------------------+   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||                                       |   |
                 ||        DISPLAYED AREA of object field |   |
                 |+---------------------------------------+   |
                 |                    OBJECT FIELD outer area |
                 +--------------------------------------------+

Note that all background cards and MOBs move with the object field.  Thus,
the delay registers will cause the blank areas to the top and left of the
screen to become visible.  Depending on the application, this may or may
not be desirable.  

The STIC offers two additional control bits, the Border Extension bits
in location $0032, which address this need.  These work by reducing
the displayed area along the top edge or left edge.  When one is set,
an 8-pixel wide area along the corresponding edge is blocked out --
that is, the area is filled with the border color.  As a result, the
blank areas of the object field are never visible; rather, only the
background-card filled areas are visible.  The displayed area affected
by these bits is indicated with "//", "\\" and "XX" below:

                 +--------------------------------------------+
                 |+---------------------------------------+   |
                 ||XX\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|   |
                 ||XX\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//                                     |   |
                 ||//      DISPLAYED AREA of object field |   |
                 |+---------------------------------------+   |
                 |                    OBJECT FIELD outer area |
                 +--------------------------------------------+

The net effect of the delay registers and border extension registers is
to provide a complete mechanism for smoothly scrolling the screen around.
Careful programming can use these mechanisms to provide the illusion of 
an infinitely large object field.

MOB coordinates are specified relative to the object field, not the
displayed area.  Also, a MOB with an X coordinate of 0 behaves as if it
is disabled.  (Y coordinate of 0 is not special, however.)  Thus,
with the default display area, the smallest coordinate position where
a single pixel of an 8x8 MOB is visible is (1, 1).  An 8x8 MOB in that
position will have a single pixel of the lower right corner of the MOB
is visible in the upper left corner of the screen.