Jump to content
Tarzilla

What can an Intellivision do?

Recommended Posts

A new version of the IntyBASIC compiler was released today:

http://atariage.com/forums/topic/240512-intybasic-compiler-v11-the-directors-cut-;/

 

even newer version at:

http://atariage.com/forums/topic/241446-intybasic-compiler-v12-the-good-things-are-now-better/

 

 

along with a comprehensive SDK which makes it much easier to setup a programming environment and dive into programming for the Intellivision:

http://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk/

 

 

To get an idea of some of the capabilites of the Intellivision, instead of just reading about GRAM and GROM and SPRITES and other terms, you can also see it in action.

 

https://youtu.be/GUjGm8ITlp8

 

Huge thanks to DZ-Jay for redoing the capture video with the proper tools and making some professional title and credits screens!

 

 

The full source is included in the SDK and it demonstrates many of the constants that were added as part of the SDK to make it easier not to have to memorize "Magic Hex Numbers."

 

Make some changes and compile with the new INTYBuild and IntyRun command line scripts.

 

Old video is here:

Original, crappy cel phone video here:

Edited:July 15, 2015 to upgrade the video

I'm not sure what was up with the sound popping, I'll update with a better video when I get a chance.

 

Edited: November 16, 2015 to reference newer IntyBASIC

 

Edited February 10, 2016 to attach the ROM version

intro.rom

Edited by Tarzilla
  • Like 19

Share this post


Link to post
Share on other sites

Complete with a snow level! Now, that's IntyBASIC POWAH!!! :grin:

  • Like 2

Share this post


Link to post
Share on other sites

That is actually a remarkably good introduction to graphics on the Intellivision. I don't always hand out praise easily, but colour me impressed.

 

It does raise one question in my mind that's always bugged me though - is the actual resolution of the INTV better described as 192 high? Not that you could ever take advantage of it. My brain just thinks of the default MOB as using "half-height pixels" but of course that's not actually possible. I think the official term is "scanline doubling" - and now I'm wondering how interlacing comes into play - but I'm already way out of my depth here. I just know how to draw them purty pictures.

  • Like 2

Share this post


Link to post
Share on other sites

It does raise one question in my mind that's always bugged me though - is the actual resolution of the INTV better described as 192 high? Not that you could ever take advantage of it. My brain just thinks of the default MOB as using "half-height pixels" but of course that's not actually possible. I think the official term is "scanline doubling" - and now I'm wondering how interlacing comes into play - but I'm already way out of my depth here. I just know how to draw them purty pictures.

 

It's tricky really. Either you describe the resolution as 159x96, with MOBs having the option for half-height pixels, or you describe the resolution as 159x192, where the BACKTAB cards have vertically-doubled pixels. In most of my descriptions I've stuck with a 159x96 resolution, with MOBs having the option to display with half-height pixels, as the Y coordinate registers for MOBs only let you move MOBs through "whole pixels" (0-95) rather than the finer-grain "half-pixel" space (0-191). That said, my STIC emulation computes a 159x192 image, due to half-height pixels in MOBs.

 

Regarding "scanline doubling" and such things: I guess it depends on what you mean by that specific nomenclature. This isn't quite the same as the interlace tricks that some systems were able to perform, such as the SEGA Genesis, where the vertical resolution was doubled to match the actual NTSC (or PAL) vertical scan through various field-shifting tricks. (That's how they squished the screen in some of the head-to-head games, such as in Sonic 2.) The STIC always sends the "even" field (or is it the "odd" field?), so you can't get a 384-line resolution screen by reprogramming your graphics 60 times a second. And yes, I did experiment with that. If nothing else, it could have lead to some interesting color-blending approaches...

 

In a single NTSC field, there's 262.5 scan lines. The STIC actually only sends 262 scan lines (which is what causes it to always send the "even" field, as opposed to alternating even vs. odd), and it allows MOBs to have different graphics on every scan line, while the pixels on the BACKTAB cards are 2 scan lines tall. If the BACKTAB's limited vertical resolution is what you mean by "scanline doubling," the Intellivision's STIC absolutely does that.

 

159x96 or 159x192 are both roughly accurate descriptions of the Intellivision's resolution. 159x192 is more accurate, but for most graphic design, you need to treat it as 159x96.

 

(And no, it's not 160x96 or 160x192. The Intellivision blanks out the rightmost column of the display with the border color. If you try to put graphics there, you will be disappointed.)

  • Like 1

Share this post


Link to post
Share on other sites

That is actually a remarkably good introduction to graphics on the Intellivision. I don't always hand out praise easily, but colour me impressed.

 

It does raise one question in my mind that's always bugged me though - is the actual resolution of the INTV better described as 192 high? Not that you could ever take advantage of it. My brain just thinks of the default MOB as using "half-height pixels" but of course that's not actually possible. I think the official term is "scanline doubling" - and now I'm wondering how interlacing comes into play - but I'm already way out of my depth here. I just know how to draw them purty pictures.

 

We opted to describe it in terms of actual pixels and show that the Background is "doubled" vertically. We thought that "half-pixels" would be a confusing concept to newcomers and that it would be easier to understand the background being more blocky and the sprites being higher resolution than complicating things with scan-lines and other technical jargon.

 

-dZ.

Share this post


Link to post
Share on other sites

 

159x96 or 159x192 are both roughly accurate descriptions of the Intellivision's resolution. 159x192 is more accurate, but for most graphic design, you need to treat it as 159x96.

 

(And no, it's not 160x96 or 160x192. The Intellivision blanks out the rightmost column of the display with the border color. If you try to put graphics there, you will be disappointed.)

Given the target audience, we decided to ignore some things, like explaining why 8 x 20 is only 159. I have another one in progress explaining more stuff like the controller quirks, demonstrating scrolling, Intellivoice (phonemes only,) and some other things like the ECS extra sound and controllers.

 

I could swear, though, that I read somewhere that the STIC chip itself could do single scan line cards but they cut the system memory required to execute it due to cost.

Share this post


Link to post
Share on other sites

 

In most of my descriptions I've stuck with a 159x96 resolution, with MOBs having the option to display with half-height pixels, as the Y coordinate registers for MOBs only let you move MOBs through "whole pixels" (0-95) rather than the finer-grain "half-pixel" space (0-191).

If a game can spare the gram space, it can "fake" moving mobs at half vertical resolution. This is done by having two gram images for the object, one of which is shifted down one scan line from the other.

 

Nomally, the unshifted gram image is displayed. But when the object needs to move down half a pixel, the code displays the shifted down image instead.

 

 

Share this post


Link to post
Share on other sites

If a game can spare the gram space, it can "fake" moving mobs at half vertical resolution. This is done by having two gram images for the object, one of which is shifted down one scan line from the other.

 

Nomally, the unshifted gram image is displayed. But when the object needs to move down half a pixel, the code displays the shifted down image instead.

 

 

How do you shift the GRAM card one scan-line?

Share this post


Link to post
Share on other sites

How do you shift the GRAM card one scan-line?

I do this in the Mars Mini's game Cavern. With 96 pixels of height available I couldn't get the gravity to feel right. So I doubled the range to 192 and then I choose the frame to display for the ship depending if the y coordinate is odd or even. Then I divide Y by 2 and configure the MOB accordingly. The yres mode (DOUBLEY in IntyBASIC) is ideal for this but you have to limit the sprite height to 15 pixels.

Share this post


Link to post
Share on other sites

DZ-Jay redid the capture of the video and I updated the first post, thanks, dude!

 

For reference, what tools did you use?

Share this post


Link to post
Share on other sites

How do you shift the GRAM card one scan-line?

From Intellipongola - here's the gram character for the ball:

; number # 2
; name: ball
_gfx_eo SET 0
_gfx_w  SET 0
    gfx_row   "##......"
    gfx_row   "##......"
    gfx_row   "##......"
    gfx_row   "##......"
    gfx_row   "........"
    gfx_row   "........"
    gfx_row   "........"
    gfx_row   "........"

And here is the gram character for the ball shifted down one scan line:

; obj 29 ball half position
_gfx_eo SET 0
_gfx_w  SET 0
	    gfx_row     "........"
	    gfx_row     "##......"
	    gfx_row     "##......"
	    gfx_row     "##......"

	    gfx_row     "##......"
	    gfx_row     "........"
	    gfx_row     "........"
	    gfx_row     "........"

; object 30 light

Notice the extra blank line at the top of the image. If the fractional part of the object's y position is one half or greater, I use the second image, so the ball appears to move down one scan line. Since the object's vertical resolution is twice that of backtab, it appears to move down half a scan line (in backtab terms).

 

Does this help?

Edited by catsfolly
  • Like 3

Share this post


Link to post
Share on other sites

I do this in the Mars Mini's game Cavern. With 96 pixels of height available I couldn't get the gravity to feel right. So I doubled the range to 192 and then I choose the frame to display for the ship depending if the y coordinate is odd or even. Then I divide Y by 2 and configure the MOB accordingly. The yres mode (DOUBLEY in IntyBASIC) is ideal for this but you have to limit the sprite height to 15 pixels.

So one 8x16 MOB alternating between two slightly shifted pairs of cards like this:

 

post-38229-0-00309200-1436974657_thumb.png

  • Like 2

Share this post


Link to post
Share on other sites

From Intellipongola - here's the gram character for the ball:

; number # 2
; name: ball
_gfx_eo SET 0
_gfx_w  SET 0
    gfx_row   "##......"
    gfx_row   "##......"
    gfx_row   "##......"
    gfx_row   "##......"
    gfx_row   "........"
    gfx_row   "........"
    gfx_row   "........"
    gfx_row   "........"

And here is the gram character for the ball shifted down one scan line:
; obj 29 ball half position
_gfx_eo SET 0
_gfx_w  SET 0
	    gfx_row     "........"
	    gfx_row     "##......"
	    gfx_row     "##......"
	    gfx_row     "##......"

	    gfx_row     "##......"
	    gfx_row     "........"
	    gfx_row     "........"
	    gfx_row     "........"

; object 30 light
Notice the extra blank line at the top of the image. If the fractional part of the object's y position is one half or greater, I use the second image, so the ball appears to move down one scan line. Since the object's vertical resolution is twice that of backtab, it appears to move down half a scan line (in backtab terms).

 

Does this help?

Oh, I knew that trick. I thought you meant a more obscure technique like shifting the playing field for a single frame, which sounded odd.

Share this post


Link to post
Share on other sites

DZ-Jay redid the capture of the video and I updated the first post, thanks, dude!

 

For reference, what tools did you use?

I use a program called "Screenflow" for the Mac. It's very powerful and allows you to record the entire screen and then crop it to a particular region, edit the video and sound tracks, and add transitions and title cards.

 

I'm glad you liked it. :)

Share this post


Link to post
Share on other sites

Given the target audience, we decided to ignore some things, like explaining why 8 x 20 is only 159. I have another one in progress explaining more stuff like the controller quirks, demonstrating scrolling, Intellivoice (phonemes only,) and some other things like the ECS extra sound and controllers.

 

I could swear, though, that I read somewhere that the STIC chip itself could do single scan line cards but they cut the system memory required to execute it due to cost.

 

The STIC itself doubles the rows for cards coming from BACKTAB, and there's no option for it to do otherwise. I did however, make a proof of concept hack that shows with additional hardware, you could double the vertical resolution of the STIC. All of the coordinate addressing in the X/Y registers is still on a 159x96 grid, though. GroovyBee's nifty hack allows for effective sub-pixel positioning, but that's software on top of the STIC.

 

The STIC 1B, intended for the Intellivision III, was supposed to double the resolution of the STIC among other things. But, as we know, that didn't survive and make it into a product.

 

FWIW, many of the STIC 1B upgrades—larger BACKTAB, higher vertical resolution, more GRAM tiles, programmable color palette—could be grafted onto the STIC itself with external hardware. (ie. replace the RA-3-9600 with a fancier external controller, and add a state machine to generate an extra address line to the GRAM/GROM for scan-doubling.) Heck, you could even implement a pseudo-bitmap mode such as the TMS9918A VDP's Graphics II mode with a suitably upgraded System RAM + GRAM. I wonder if GI's STIC 1B prototype for Mattel took that approach?

Share this post


Link to post
Share on other sites

The STIC itself doubles the rows for cards coming from BACKTAB, and there's no option for it to do otherwise. I did however, make a proof of concept hack that shows with additional hardware, you could double the vertical resolution of the STIC. All of the coordinate addressing in the X/Y registers is still on a 159x96 grid, though. GroovyBee's nifty hack allows for effective sub-pixel positioning, but that's software on top of the STIC.

 

The STIC 1B, intended for the Intellivision III, was supposed to double the resolution of the STIC among other things. But, as we know, that didn't survive and make it into a product.

 

FWIW, many of the STIC 1B upgrades—larger BACKTAB, higher vertical resolution, more GRAM tiles, programmable color palette—could be grafted onto the STIC itself with external hardware. (ie. replace the RA-3-9600 with a fancier external controller, and add a state machine to generate an extra address line to the GRAM/GROM for scan-doubling.) Heck, you could even implement a pseudo-bitmap mode such as the TMS9918A VDP's Graphics II mode with a suitably upgraded System RAM + GRAM. I wonder if GI's STIC 1B prototype for Mattel took that approach?

Maybe this discussion warrants its own thread...?

 

The topic is "Things the Intellivision can do" in the context of programming it with IntyBASIC, and more specifically, about the introduction demo that Tarzilla created. :)

 

dZ.

Share this post


Link to post
Share on other sites

Maybe this discussion warrants its own thread...?

 

The topic is "Things the Intellivision can do" in the context of programming it with IntyBASIC, and more specifically, about the introduction demo that Tarzilla created. :)

 

dZ.

Sure, but what technical discussion in this forum DOESN'T go off on tangents ;)

Share this post


Link to post
Share on other sites

We opted to describe it in terms of actual pixels and show that the Background is "doubled" vertically. We thought that "half-pixels" would be a confusing concept to newcomers and that it would be easier to understand the background being more blocky and the sprites being higher resolution than complicating things with scan-lines and other technical jargon.

 

Imparting a flawed mental model for the sake of avoiding some momentary confusion is almost always the worst thing to do. It is a LOT more difficult to get someone to discard a flawed mental model than it is to get them to learn a new concept.

 

And yes, "half-pixels" is confusing, because it's nonsense. A pixel by definition cannot be halved. The important concept to impart to Intellivision newbies is that pixels can be different sizes.

Share this post


Link to post
Share on other sites

Sure, but what technical discussion in this forum DOESN'T go off on tangents ;)

Tangents are fine. It's just that I see many IntyBASIC-related topics go into some rather arcane technical tangents, which I would imaging may turn away a lot of people who are just starting with the platform.

 

I think we should try to keep the IntyBASIC threads at a higher level and on topic so that newcomers can join and not feel intimidated by all the low-level stuff. Also they can serve as reference to other programmers.

 

After all, the purpose of the contest and the SDK is to lower the barriers and attract more people to the platform. :)

 

dZ.

  • Like 1

Share this post


Link to post
Share on other sites

Very informative video. :-)

Did you watch until the very end? There's a surprise for you! :)

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...