Expanded GRAM

[+cmadruga]

Question to hardware gurus out there... what would it take to be able to expand GRAM on a standard console?

Thinking about INTV88's 256 tile capacity.

 

Thanks

[+Gemintronic]

Not an answer, but, I suspect whatever chips the Inty board has is not easily soldered off and on again.

 

Probably have better luck with hardware assist on the cartridge either in a new standard library, additional CPU or more RAM.. or, all three!

[carlsson]

Would the STIC be able to address cartridge RAM though? In that case I would suppose that JLP style memory already had an option for more GRAM.

 

Many computer enthusiasts like to piggy-back RAM chips on top of the others. Often there is an address select line that is different, and then you have other pins in common for voltage, ground etc. I don't know if the memory decoding circuitry even supports piggy-backing chips for more GRAM, or if you would need a bigger internal surgery to achieve it on a regular console. Somehow I would assume this topic has been up before, but I haven't looked back for previous answers.

[Zendocon]

47 minutes ago, carlsson said:

Many computer enthusiasts like to piggy-back RAM chips on top of the others. Often there is an address select line that is different, and then you have other pins in common for voltage, ground etc. I don't know if the memory decoding circuitry even supports piggy-backing chips for more GRAM, or if you would need a bigger internal surgery to achieve it on a regular console. Somehow I would assume this topic has been up before, but I haven't looked back for previous answers.

I'm pretty sure there's no way to modify the actual hardware, based on @artrag's answer to that question.  It would be nice though.

[carlsson]

Also, I just read in stic.txt (see the /doc/programming folder in jzintv) that bits 9-10 are ignored when bit 11 (GRAM) is set or if one uses BG/FG mode. I understand that GRAM is made up of two GTE 3539, just like the one GTE 3539 for 8-bit Scratchpad RAM.

 

Joe's page summarizes some of the tech: http://spatula-city.org/~im14u2c/intv/tech/overview.html

 

The comment that $3A00 - $3FFF contain read-only aliases of the GRAM at $3800 - $39FF sounds to me like the chip is only partly decoded. We recognize that from many other systems, i.e. on a C64 the SID chip is normally addressed at $D400 but it shows up mirrored at $D500. The finer granularity you need for decoding chips (i.e. one at $4000, one at $4080, one at $4100 etc), the more complex and expensive it gets.

 

Even if it was possible to piggy-back another 3539, I wonder if it would show up in the memory map and nevertheless, if the higher bits are ignored when trying to access GRAM (whether that is due to the STIC or routing of signals on the circuit board), it probably wouldn't work anyway.

[+DZ-Jay]

I believe Joe Z. did this once as a proof of concept.  I don't recall the details, but I seem to remember there were plenty of caveats.  It did require a hardware modification.

 

UPDATE:  Here are the details I found:

https://groups.io/g/intvprog/topic/56960066#5862

 

 

Edited April 15, 2021 by DZ-Jay

[+cmadruga]

@DZ-JayWow, thanks for that! Amazing!

I guess that answers my original question...

 

Thanks folks for all the other responses as well!

[skywaffle]

Does anyone know if having the extra GRAM would cause compatibility issues with prior games?  This modification is simple enough to do, and the thought of having double the GRAMs available on stock hardware sounds like a lot of fun to play with.

[+cmadruga]

15 minutes ago, skywaffle said:

Does anyone know if having the extra GRAM would cause compatibility issues with prior games?  This modification is simple enough to do, and the thought of having double the GRAMs available on stock hardware sounds like a lot of fun to play with.

I believe so... per Nanochess at another topic:

 

"In fact some games occupy the non-used bits of GRAM access to preserve data and would show trash on a Tutorvision."
 

One idea would be to incorporate some type of mechanical switch or button to the mod.

[carlsson]

I read that comment from Nanochess and I wonder what he means. Take any GRAM card that is 8x8 or 8x16 pixels (some MOBs). As far as I can tell, every bit is used to its maximum in the GRAM memory. I think he meant the BACKTAB where the two upper bits are unused and can be used to store additional data. Those two bits are not involved in selection of which GROM/GRAM to display.

 

Edit: Unless of course the reference was to bits 9-10 which form address bits 7-8 in selecting GROM in CS mode, but per the stic.txt mentioned above are ignored for GRAM and BG/FG mode. It might very well be so that the BACKTAB holds all 16 bits and that the CPU can read all of it, but since STIC won't bother about bits 9-10 as long as bit 11 is set, you have a total of 4 bits (9, 10, 14, 15) to store additional information as long as you use GRAM. On an expanded console with 1K or 2K GRAM, the bits 9 and 10 would apparently be used by the STIC which means BACKTAB would contain garbage if you at the same time tried to use those two bits for own information.

 

Rather I would think the mirroring effect in the memory map is more important to take into consideration, if any game writes to $3800 and then reads from $3A00. On a stock Intellivision the content supposedly would be the same, but on a modified machine you would have your extra 64 cards starting from $3A00. You might say that is a strange way to program but you can never rule out all sorts of interesting practices. Perhaps there are side effects wrt bus usage if the STIC accesses GRAM at $3800 but the CPU would access it from a different address, just speculating.

 

I agree with Skywaffle that on an Intellivision II it doesn't seem like a very big modification to make. It reminds me of how to add 32K Sideways RAM to a BBC Micro, by using one of the spare ROM slots to put a static RAM chip into, cutting some lines on the underside of the circuit board and solder in a wire or two to route a signal.

 

What about the Intellivision System ///, does it also use 2114 type SRAM or did INTV revert back to the older 256 bytes RAM chips? If it would turn out this is a hack that only applies to Intellivision II units, it would create a subclass of games only compatible with that one, just like I've got the impression there are some peripherals and games not compatible with that particular model.

Edited April 15, 2021 by carlsson

[+DZ-Jay]

Christmas Carol uses two of those bits in the BACKTAB word because it relies on the fact that it uses Color Stack mode and only GRAM tiles within the maze boundaries.  In such situations, bits 9 and 10 are ignored by the STIC, so we use them, along with bits 14 and 15, to hold the position of items on the card.

 

Spoiler

; ===================================================================
; We are using "Color Stack" mode for drawing the background, this
; frees up four bits from each 16-bit BACKTAB word, which we can use
; for game state information.
;
; The unused bits of each 16-bit word are co-opted to store the state
; of each bonus item in RAM.
;
; Each "natural" tile may contain up to three items, one of which
; can be a Magical Snowflake, the others are pieces of candy.
; The available item positions within a natural tile are as follows:
;
;   8x8 Natural Tile:
;     ...2....
;     ........
;     ........
;     ........
;     ...1...0  <- #1 can be either Candy or a Magical Snowflake.
;     ........
;     ........
;     ........
;
; The BACKTAB data for the Christmas Carol maze is pre-computed below
; for faster loading.  Each word defines a 16-bit vector in the
; following format:
;             ,-----------------------> Stack Advance Flag
;             |
;             v
;     F   E   D   C   B   A   9   8   7   6   5   4   3   2   1   0
;   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
;   | @ | * | - | C | M | * | * |    GRAM/GROM Card #   |  FG Color |
;   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
;     ^   ^       ^   ^   ^   ^
;     |   |       |   |   |   |
;     |   |       |   |   |   `-------> Candy #1
;     |   |       |   |   `-----------> Candy #2
;     |   |       |   `---------------> GRAM=1, GROM=0
;     |   |       `-------------------> FG Color High Bit
;     |   |
;     |   `---------------------------> Candy #3
;     `-------------------------------> Magical Snowflake
;
;
; Copyright (c) 2010-2018, James Pujals (DZ-Jay)
; ===================================================================

 

 

So reading those extra bits to get to more than 64 GRAM cards will make Christmas Carol look strange.

 

In that thread, Joe adds,

Quote

Just be sure to allow tying the RAM's A9 lines back to GND, otherwise you may break existing games.  Existing games probably store garbage in that extra bit in BACKTAB that selects between GRAM cards 0-63 and 64-127.

So I guess that with a careful design, backwards compatibility could be maintained.

Edited April 15, 2021 by DZ-Jay

[+DZ-Jay]

By the way, here's the second part of that hack:

https://groups.io/g/intvprog/topic/56960186#5908

 

Here's a critical quote from Joe:

Quote

Quote

... so you're saying you could integrate a permanent add-on circuit onto any Intellivision mainboard and improve the quality of the output graphics - of any game?

 

No, it doesn't do that.  It does make it possible for new games to offer graphics with double the vertical resolution, though.  Not quite as impressive, to be sure.  When I say it's "backward compatible with existing games," I mean that they continue to work exactly as they did before.  

My 128-GRAM-card hack from a week ago didn't have that property.  If you plugged in an existing game, there was a non-zero chance that it wouldn't function correctly.  (Space Patrol pretty much looked like crap.)  This weekend's hack adds logic to turn the new features on/off, defaulting to off after reset.

 

    -dZ.

[+DZ-Jay]

As the above suggests, these are topics which have been discussed before.  Those two threads on the INTVProg mailing list are regarding the hardware, but you can find a few threads here on AA regarding the software side and how much interest there is.

 

The bottom line is that, although technically possible, it would require a not-so-trivial hardware modification to the console itself, and would only work on new games.

 

This has two significant implications:  First, the use of the feature relies on developers taking advantage of it for new games.  Second, the number of modified consoles will need to reach a critical mass in order for it to become an attractive proposition to developers, enough to warrant investing time and effort in learning and exploiting it.  Both depend on each other, and neither is guaranteed.

Notwithstanding the practical implications, there is also the more mundane aspect of focus and interest.  As you all know, there is the not-so-minority view that changing too much the hardware characteristics of the device lessens its nostalgic appeal.  And at that point, all those discussions degenerate into "wouldn't it be cool if someone made a new retro/modern/ish Intellivision console?," and it's all just a trip down speculation-dream-ville from there until people lose interest on the thread.

 

In such a relatively small community of home-brew enthusiasts, all those barriers become more pronounced.

 

Still, it's a neat hack.

 

     -dZ.

 

Edited April 15, 2021 by DZ-Jay

[mr_me]

The hack on an original intellivision is straightforward, just a matter of soldering all the pins.  An intellivision ii already has 1kB of gram present, one of the address pins not connected on each chip.  All he did was connect the address line to double the gram (and cut the connection to ground).  With an original intellivision you just disconnect the existing ram and solder in new sram, up to 2kB.  A lot more soldering but that's it.  Joe only tested one of the unknown address lines for 1kB gram but presumably the second address line will give the full 2kB gram that the stic/grom supports.

 

As far as backward compatibility, I remember that Worm Whomper graphics would be broken.  There might be a second cartridge from the originals affected but don't remember.  Sounds like homebrewers used those two bits to store data more often.  As has been said, you can get backward compatibility with a mechanical switch that disconnects the extra address lines.

 

Joe's second hack is a little different.  It's about doubling the background resolution to match the sprite resolution.  He talks about a counting circuit that would give each background tile 8x16 resolution.  He doesn't go into the details, says it's simple, but probably not.

 

If anyone wants play around with expanded gram in emulation, jzintv supports it with a command switch.

Edited April 15, 2021 by mr_me

[Zendocon]

33 minutes ago, mr_me said:

If anyone wants play around with expanded gram in emulation, jzintv supports it with a command switch.

Yes.  The switch is "-G1" for 1K GRAM, or "-G2" for 2K GRAM.

 

In my PIDEjL front-end, I have a set of "Peripheral Options" radio buttons which allow for ECS, INTV88, or neither (I didn't include an option to have both, since apparently the Tutorvision is incompatible with the ECS).  I can try playing around with all the games with INTV88 enabled to see what games break and how so.

 

I'm also currently working on a game that optionally supports ECS for extra players and sound as FUBAR did, and another game to put the 1K GRAM to optional use (but not the ECS).  If having 1K GRAM on the Intellivision II still allows for ECS, then maybe I'll consider allowing for both in future game releases.

1 hour ago, DZ-Jay said:

This has two significant implications:  First, the use of the feature relies on developers taking advantage of it for new games.  Second, the number of modified consoles will need to reach a critical mass in order for it to become an attractive proposition to developers, enough to warrant investing time and effort in learning and exploiting it.  Both depend on each other, and neither is guaranteed.

Notwithstanding the practical implications, there is also the more mundane aspect of focus and interest.  As you all know, there is the not-so-minority view that changing too much the hardware characteristics of the device lessens its nostalgic appeal.  And at that point, all those discussions degenerate into "wouldn't it be cool if someone made a new retro/modern/ish Intellivision console?," and it's all just a trip down speculation-dream-ville from there until people lose interest on the thread.

Count me in among the interested developers!

 

As for hardware mods, I'd like to send my Intellivision II to somebody better than myself with a soldering gun to enable the 1K GRAM, as well as provide video output to something I can connect to a video capture board for live-streaming on real hardware - it doesn't have to be HDMI necessarily.  I wouldn't go any further than that though.

 

I did fantasize about a new Intellivision model a long time ago, which I never shared on any thread.  As you suggest, I'll keep it off this thread.

[mr_me]

Expanded gram shouldn't be a problem with an ecs.  The reason tutorvisions are incompatible with ecs is because of the expanded tutorvision exec rom at $2000 which conflicts with ecs rom.

[+cmadruga]

Great summary, @mr_me!

 

Going back to @DZ-Jay's critical mass comments, here's perhaps another perspective:

 

It seems these days there is increased pull for digital distribution.

More folks seem to be wanting to experience what has been coming out while not wanting to shell out for a CIB.

That makes me wonder whether having a critical mass of modified hardware is as relevant a factor nowadays.

 

I know this is a stretch, but I wonder if it's not the other way around: maybe the impact of expanded GRAM - if dramatic enough - could actually create demand for modified hardware?

Perhaps nostalgic folks and HW purists will balk at it... but at the end of the day isn't this mod just a type of work around to "Tutorvision" scarcity?

Actually, this mod would be technically a superior alternative given the absence of ECS issues as mr_me pointed out. Plus a design that can turn expanded GRAM on/off at will would preserve compatibility with existing software, as also mentioned.

Edited April 15, 2021 by cmadruga

[Zendocon]

1 hour ago, cmadruga said:

I know this is a stretch, but I wonder if it's not the other way around: maybe the impact of expanded GRAM - if dramatic enough - could actually create demand for modified hardware?

Kind of what I was thinking when I mentioned a video output mod.  I've been seeing quite a few people mod their classic systems for HDMI output these days, or at least Composite Video.  That's all the more popular with handheld systems, especially ones that weren't backlit like the Neo Geo Pocket Color, or ones whose displays start to have artifacts over time, like the "ghosting" issue on the Atari Lynx.  Since people are performing hardware mods anyhow, might as well enable double GRAM in the Intellivision II at least, and include a switch to disable it for games that don't use it.

 

In that earlier thread, @decle provides code to autodetect the extra GRAM.  Maybe @nanochess will put that into a future version of IntyBASIC, as with ECS.AVAILABLE (which didn't exist in v1.2.9 at the time of the first book's release).

[+cmadruga]

@Zendocon Exactly... I'd be interested in modding my Intellivision for that as well.

I like the idea of auto-detecting expanded GRAM and putting it to optional use. I was thinking exactly the same.

 

This is a relevant topic for me because we had to downgrade... and downgrade... graphics for Pandora to make it fit the standard constraints.

On the other hand, you give a talented guy like @Black_Tiger some extra tiles to play with, and he can do very fine stuff...

 

Edited April 15, 2021 by cmadruga

[Zendocon]

6 minutes ago, cmadruga said:

This is a relevant topic for me because we had to downgrade... and downgrade... graphics for Pandora to make it fit the standard constraints.

On the other hand, you give a talented guy like @Black_Tiger some extra tiles to play with, and he can do very fine stuff...

Perhaps you can have a commercial release of The Pandora Incident which enables the extra GRAM if present, and provide the graphics you wanted in the first place.  I think people would be willing to pay a premium for it, in spite of the small number of people who have a Tutorvision or even a modded Intellivision II console.

[Intelligentleman]

Fascinating discoveries. I don't have much interest in modding my systems personally. But, I'd consider paying someone who knows what they're doing to do it. But the other thing is, as someone already stated, extensive mods can be a turn off to some people, myself included. I'm still not sure how I feel about AV mods, for example. Seems like anything "better" than composite could really change the look of the games.

Edited April 15, 2021 by Intelligentleman

[+DZ-Jay]

4 hours ago, cmadruga said:

Great summary, @mr_me!

 

Going back to @DZ-Jay's critical mass comments, here's perhaps another perspective:

 

It seems these days there is increased pull for digital distribution.

More folks seem to be wanting to experience what has been coming out while not wanting to shell out for a CIB.

That makes me wonder whether having a critical mass of modified hardware is as relevant a factor nowadays.

 

I know this is a stretch, but I wonder if it's not the other way around: maybe the impact of expanded GRAM - if dramatic enough - could actually create demand for modified hardware?

Perhaps nostalgic folks and HW purists will balk at it... but at the end of the day isn't this mod just a type of work around to "Tutorvision" scarcity?

Actually, this mod would be technically a superior alternative given the absence of ECS issues as mr_me pointed out. Plus a design that can turn expanded GRAM on/off at will would preserve compatibility with existing software, as also mentioned.

 

That’s all fine and all, but until you and others make a game utilizing those enhancements, this is just yet one more of those threads I mentioned.

 

Consider that your challenge.

[+nanochess]

Just made IntyColor to support the expanded GRAM by using the -t option. Notice the only mode that can access the 256 GRAM cards is the Color Stack mode.

 

As always the source code is at https://github.com/nanochess/IntyColor

 

Let me show also a tiny example using the cutegirl.bmp file (from my previous demo to test for Tutorvision/Super Pro systems):

./intycolor -b -s0707 -t cutegirl.bmp cutegirl.bas
./intybasic cutegirl.bas cutegirl.asm
./as1600 -o cutegirl cutegirl.asm
./jzintv -z3 -G2 cutegirl

 

For jzintv is very important the uppercase G, otherwise with the lowercase g it tries to load a strange GROM file.

 

 

IntyColor_v1.2.0.zip cutegirl.bmp

Edited April 15, 2021 by nanochess

[+nanochess]

12 hours ago, carlsson said:

I read that comment from Nanochess and I wonder what he means. Take any GRAM card that is 8x8 or 8x16 pixels (some MOBs). As far as I can tell, every bit is used to its maximum in the GRAM memory. I think he meant the BACKTAB where the two upper bits are unused and can be used to store additional data. Those two bits are not involved in selection of which GROM/GRAM to display.

 

Edit: Unless of course the reference was to bits 9-10 which form address bits 7-8 in selecting GROM in CS mode, but per the stic.txt mentioned above are ignored for GRAM and BG/FG mode. It might very well be so that the BACKTAB holds all 16 bits and that the CPU can read all of it, but since STIC won't bother about bits 9-10 as long as bit 11 is set, you have a total of 4 bits (9, 10, 14, 15) to store additional information as long as you use GRAM. On an expanded console with 1K or 2K GRAM, the bits 9 and 10 would apparently be used by the STIC which means BACKTAB would contain garbage if you at the same time tried to use those two bits for own information.

I was thinking on Utopia, I remember reading invnut's Utopia Revealed!

 

 

 

[+cmadruga]

@nanochess

Wow, that was fast! Now that's what I call responsiveness

 

Thank you for the IntyColor update!