Super Pro STIC?

[First Spear]

I thought this was discussed a bit on the AA forums, but my searching is not turning up anything.

 

How plausible would it be for a cartridge to add electronics to aid or circumvent the STIC to increase background tile counts (improve resolution) or increase flickerless MOB count (improve action)?

 

On the 8-bit Apple II line, graphics resolution can be doubled by increasing memory and bank-switching with add-on hardware (http://nerdlypleasures.blogspot.com/2013/09/the-overlooked-artifact-color.html). I was wondering if the same could be done on the Inty.

 

Of course it would break compatibility with everything else on the Intellivision, just curious....

 

[intvnut]

The answer to your question depends on the answer to this question: Do you want the video output to go out the normal RF output path (or A/V port if suitably modified), or have a video connector on the cartridge?

 

If it came out of the cartridge, I'd say "Oh hey look! It's a video game system that uses an Intellivision for a power supply!" And even if it routed the video into the Intellivision so it came out of the Intellivision's RF... I may still be inclined to think of it that way.

 

The original Intellivision only offers a very simple "pull to white" circuit that's used by the Keyboard Component to overlay white text over whatever graphics the STIC is outputting. In theory, you could inject color video via that line, but you'd have to be very carefully synced to the colorburst coming out of the STIC. But, that'd basically be more or less bypassing the STIC, making your own video that just happened to be sync'd to the STIC.

 

And, it would only work on unmodified Intellivision 1s. If you have an Intellivision 2 (or a suitably modified Intellivision 1), then you can output whatever video you like, by disabling/overriding the STIC. Those have a circuit that allows the System Changer to bypass the STIC and output Atari 2600 graphics. For that, you don't need to sync with the STIC's output. But, again, you're producing your own output, completely separately of the STIC.

 

Other than that, there's no way to really upgrade the STIC's output from the cartridge port. You bypass / overlay with something separate of what the STIC outputs.

 

If you allow opening up and modifying the Intellivision's guts, then you do have some options there. Some ideas, roughly from easiest to hardest:

• Increasing the number of GRAM slots from 64 to 256. This is trivial, and just requires connecting a large enough capacity RAM in place of the 256 x 8 RAM that's connected to the GROM.
• Doubling the vertical resolution of the display. This is a little trickier, as it requires building a small logic state machine and doubling the GRAM storage again, but I have actually prototyped such a hack.
• Changing the 20x12 BACKTAB to, say 20x24. This would require replacing the RA-3-9600 System RAM, feeding different data to the STIC in response to the SR1/SR2/SR3 pulses. This is a bit more complicated, but still possible.
• Providing a larger BACKTAB area than visible, with a way of changing what portion of it was currently visible, to help with hardware scrolling: Requires similar work to the previous bullet.
• A bitmap or pseudo-bitmap mode: If you have 256 GRAM slots, you have a 2-color bitmap mode already. To get a more colorful bitmap mode (such as the VDP's Graphics II mode), you need to replace the RA-3-9600 with something that can provide add'l color data for the BACKTAB to the STIC. (Doable in a similar manner to the last two bullets.)

Some things to note:

• You can't really upgrade the STIC video from the cartridge port. You can overlay it or replace it, depending on Intellivision 1 or 2.
• You can upgrade the STIC video by putting increasing amounts of logic around it to trick it into displaying what you want, ranging from the simple (more RAM) to the complex (elaborate state machines).
• No amount of logic around the STIC will cause the STIC to display more MOBs, though.

Ah well.

Edited March 5, 2015 by intvnut

[freewheel]

You could just buy an NES...

[intvnut]

You could just buy an NES...

 

It's interesting you should mention the NES. The way they set up its PPU, with the dedicated graphics fetch bus (CHR ROM) coming to the cartridge port, you really could upgrade that system's display capabilities from the cartridge port.

 

That's one of the functions the various 'mapper' chips were responsible for. Check out MMC5, for example. And now for some irony: The MMC5 provides extra audio channels too, but you can't use them on the NES. While the Famicom includes an external audio pin, this pin was left off the NES. *d'oh*

 

Now back to your regularly scheduled Intellivision programming.

[freewheel]

Well that's kinda why I chose it. It was ridiculously expandable for its day.

 

But mostly I'm of the opinion to enjoy something for what it is. Once you start down the franken-console path, it takes all of a couple of solder joints before you're not really using the original console anyway. The guys on AA that are hacking the hell out of the Aquarius to make it less of a piece of shit - sure, it's an impressive technical achievement, but why not just use a computer that isn't a piece of shit to begin with? What exactly does the Aquarius bring to the table that demands expanded capabilities?

 

The little mods we do for cleaner video and audio are neat. Overclocking an NES to reduce framerate slowdown, cool. But fundamentally changing the graphics architecture of a machine, to the point where 3 people on the planet are ever gonna be able to play your enhanced game? Why not just buy a different console - that's what you're creating, anyway.

 

Unfortunately the INTV isn't really "expandable" via the cart port, not in the way people are thinking. That being said - holy crap can you do a lot more with it given the near-unlimited ROM space we have today. So to me, it already has the capability to do much enhanced graphics compared to 1981. It's still gonna be tile-based, it's still gonna be low resolution, and it still has a small sprite count. So get creative with your tiles

[First Spear]

I was asking about cartridge-based expansion was for the single reason of having an upgrade basically available to "everyone" (that wanted to pay for it). Pure fantasy, but I thought I'd ask (and love Joe's answer) since I don't know the hardware well enough and looking at the Wiki didn't increase my clue count.

 

I agree that letting games now use up to 42k is like having "super graphics" in that the storage allows for more expansive games than ever.

 

Creative with tiles? Just wait....

 

 

 

But mostly I'm of the opinion to enjoy something for what it is. Once you start down the franken-console path, it takes all of a couple of solder joints before you're not really using the original console anyway. The guys on AA that are hacking the hell out of the Aquarius to make it less of a piece of shit - sure, it's an impressive technical achievement, but why not just use a computer that isn't a piece of shit to begin with? What exactly does the Aquarius bring to the table that demands expanded capabilities?

 

[snip]

Unfortunately the INTV isn't really "expandable" via the cart port, not in the way people are thinking. That being said - holy crap can you do a lot more with it given the near-unlimited ROM space we have today. So to me, it already has the capability to do much enhanced graphics compared to 1981. It's still gonna be tile-based, it's still gonna be low resolution, and it still has a small sprite count. So get creative with your tiles

[First Spear]

I was thinking of the normal RF output path. The 8-bit Apple II had "40 column graphics" and 280 pixels horizontal display, but adding additional hardware and software calls made the display 80 columns of text and 560 pixels wide by interleaving two banks of 40 column display. I thought that through the cartridge port the Intellivision could be "tricked" into doing the same thing somehow.

 

But the answer is no.

 

I just learned a ton in the process.

 

Thanks!

 

 

 

The answer to your question depends on the answer to this question: Do you want the video output to go out the normal RF output path (or A/V port if suitably modified), or have a video connector on the cartridge?

[snip]

 

Other than that, there's no way to really upgrade the STIC's output from the cartridge port. You bypass / overlay with something separate of what the STIC outputs.

 

[snip]

[intvnut]

I was thinking of the normal RF output path. The 8-bit Apple II had "40 column graphics" and 280 pixels horizontal display, but adding additional hardware and software calls made the display 80 columns of text and 560 pixels wide by interleaving two banks of 40 column display. I thought that through the cartridge port the Intellivision could be "tricked" into doing the same thing somehow.

 

Well even the Apple ][ wasn't quite as expandable as you suggest. They built the 80-column upgrade capability directly into the Apple //e. It wasn't present on the Apple ][ or Apple ][+. (Heck, those machines didn't even have lower case!) The 80 column cards used on the ][ and ][+ actually switched out the on-board video to override with their own, as I understand it.

 

 

But the answer is no.

 

And believe me, I wish the answer was yes, even for small values of "yes", such as expanding GRAM from the cartridge port.

 

I'm with freeweed above that going nuts and providing something well beyond the capability of the original isn't keeping with the spirit of the machine. But, something mild like GRAM expansion, something that's directly supported in the chips already there, really, and only precluded by what they pin out, is well within scope IMHO.

Edited March 5, 2015 by intvnut

[freewheel]

Anything that can be added as hardware into a cart, while still utilizing the base machine in every sense, I'm all for. Especially when it only adds a few bucks to the final manufacturing cost, and is easily implemented in emulation as well.

 

Of course you could probably cram a Pi into a cart shell and run an N64 emulator from it, if you really wanted to.

[carlsson]

Is there a software way to determine if a game runs on an Intellivision 1, 2 or later? I don't need any code, just an answer "yes" or "no". My thinking is that a cartridge with extra hardware then could determine whether it should try to override the STIC with an own, on-board graphics system or if the game should play with regular graphics so the same cartridge still would be operational on all variants but improved graphics on those where the video can be overriden.

[+DZ-Jay]

I agree that letting games now use up to 42k is like having "super graphics" in that the storage allows for more expansive games than ever.

 

Creative with tiles? Just wait....

 

 

This is basically the reason that Christmas Carol resulted in such a rich and satisfying game with so many complex animations and cut-scenes: once I came to terms that it probably wouldn't fit in 16K, I said, "to hell with space constraints. I got 42K, let's use'em!" At that point, I unleashed my creativity without any consideration for space.

 

My game engine had already proven that it could animated any number of cards simultaneously (mostly because the chances of all of them requiring an update at the same time was very slim), so it was just a matter of animating the heck out of every single element: Christmas Carol's hair, the Snowman's arms, the Jack-In-The-Box's coil, the little droplets that fall from the ceiling during the cut-scenes, explosions, sparks, etc. No more two- or three-frame animation sequences for me!--everything has a rich and complex sequence to support variable frame rates at very fine-grain resolutions.

 

I even decided to forgo any physics code because it came to the point that it was so much more simpler to animate, say, a coil bounce that looked realistic, or the sinuous trajectory of the floating "+5" points--frame by frame--than to figure out how to make objects follow an actual sine wave or compute gravity acceleration using maths.

 

It's all "smoke and mirrors": a combination of clever animation and variable frame-rates controlled by the number and sequences of frames, rather than complex velocity calculations.

 

I think the results are rather effective. The game may not be as complex as others, and may not push the hardware to its critical limits in the traditional sense; but it did raise the bar on expectations of quality and polish since then, or at least showed that graphics can be rich and expressive even on the Intellivision.

 

Of course, I would have liked to be able to move more than 8 objects at a time, or draw bitmaps, or have better color variety on my backgrounds. However, not having them forces you to concentrate on the things that the machine can offer--and let's face it, having 42K of ROM and virtually unlimited on-cartridge RAM is the Holy Grail of ancient 1980s consoles.

 

-dZ.

[+DZ-Jay]

For an example of the wasteful-yet-effective nature of Christmas Carol's animation--and a vote in the "MOAR ROMS! PLEZ!" column--consider the following animation of the Snowman's arms:

@@Attack:
:0       :1       :2       :3       :4       :5       :6       :7       :8       :9       :10      :11      :12      :13      :14      :15      :16      :17
........ ........ ........ .......# .......# ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
........ ........ ......#. .......# .......# ......#. ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
........ ....#... ......#. .......# .......# ......#. ....#... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
....#... .....#.. ......#. ......## ......## ......#. .....#.. ....#... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
.....#.. .....#.. .....##. .......# .......# .....##. .....#.. .....#.. ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
.....#.. ....##.. .......# .......# .......# .......# ....##.. .....#.. ...#.... ........ ........ ........ ........ ........ ........ ........ ........ ...#....
....###. ......#. .......# .......# .......# .......# ......#. ....###. ....#... ........ ........ ........ ........ ........ ........ ........ ........ ....#...
.......# .......# ........ ........ ........ ........ .......# .......# .....### ....#### ......## .......# .......# .......# .......# ......## ....#### .....###
........ ........ ........ ........ ........ ........ ........ ........ ....#... ...#.#.. ....##.. ......#. ......#. ......#. ......#. ....##.. ...#.#.. .....#..
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...#.#.. .....##. ......## ......## .....##. ...#.#.. ........ ........
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....#... ......#. ......#. ....#... ........ ........ ........
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....#... ......#. ......#. ....#... ........ ........ ........
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......#. ......#. ........ ........ ........ ........
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........
........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........

If you look closely, there's probably 8 or 9 unique 8x8 cards in there, yet the sequence repeats them which results in a total of 18 frames of two cards each--a total of 36 cards! Even when the GRAM card is sequenced at a specific rate, the duplicate frames result in a visually nuanced animation, suggesting that the arm slows down and speeds up as it goes from top to bottom motion.

 

I'm sure there are more clever ways to do this, and certainly more efficient ways. Yet, I didn't have to figure out variable rate conversions, tile compression, or expend any effort trying to address technical limitations; I just kept on adding frames and moving pixels around until it felt right and looked natural--space constraints be damned!

 

It's hard for me to overstate how incredibly liberating this was. So yes, please, MOAR ROMZ IZ GOOD!

Edited March 6, 2015 by DZ-Jay

[freewheel]

Yup. I've put some serious thought into doing a tech demo strictly about high framerate animation. The only actual limitation on the INTV, to be honest, is the 2-colors-per-card limit. THAT constrains you something fierce and is something I wish I could change. But the screen resolution, MOB count, etc? Those are all easy to work around.

[intvnut]

Is there a software way to determine if a game runs on an Intellivision 1, 2 or later? I don't need any code, just an answer "yes" or "no". My thinking is that a cartridge with extra hardware then could determine whether it should try to override the STIC with an own, on-board graphics system or if the game should play with regular graphics so the same cartridge still would be operational on all variants but improved graphics on those where the video can be overriden.

 

You can detect Intellivision II vs. Sears vs. (neither Sears nor Inty 2). You cannot detect in software whether the system has the System Changer modification.

 

If you're going to use the System Changer's video path, that's what you need to detect.

 

If you're building custom hardware, you may be able to detect the presence of the system changer modification. On unmodified Intellivision 1 systems, pin 2 is tied to ground. On systems that support System Changer, pin 2 is an input. So, if you can successfully drive pin 2 to a voltage other than 0v, you can input video via this path. So if your video output is buffered through a resistor, you can tie a sense line after the resistor right at the pin back to logic on the board to report back whether video is able to make it into the system.

 

I'm not sure offhand what the Intellivoice or ECS do with pin 2. You may need to plug directly into the console.

[First Spear]

These are now "affordable": https://www.sparkfun.com/products/14828

 

I don't know how they might be useful to augment the new cart architectures like JLP, but it looks interesting*.

 

 

Anything that can be added as hardware into a cart, while still utilizing the base machine in every sense, I'm all for. Especially when it only adds a few bucks to the final manufacturing cost, and is easily implemented in emulation as well.

 

Of course you could probably cram a Pi into a cart shell and run an N64 emulator from it, if you really wanted to.