Intellivision: ROM bankswitching, cartridge RAM questions

[+5-11under]

A few questions regarding the Intellivision and memory...

 

Are there any games/demos/ROMs available that use cartridge RAM? Is the RAM typically 16 bit?

 

Are there any games/demos/ROMs available that use bankswitching? I know some of the "LTO" games do... are they still using a simple scheme, or is it a more complicated scheme? Are there any non-LTO games that use bankswitching? What is the method used?

 

... I'm just laying out the next version of my Intellivision game PCB, and adding an option for RAM (and thinking of utilizing the unused half of the ROM chip). Thanks in advance!

 

[GroovyBee]

There is a description of ECS style bankswitching here :-

 

http://atariage.com/forums/topic/196015-need-all-information-on-the-ecs-computer-module/?p=2494003

 

The Intellicart/CC3 bankswitching description is located in the sdk1600\doc\programming\intellicart.txt document.

 

Bee3 RAM is 16 bit wide and mapped to begin at 0x8040 - Its an odd address because it avoids STIC aliases.

[+5-11under]

Oi! Thanks! Time for some bedtime reading!

[intvnut]

I'd strongly recommend going with ECS-style page-flipping, as it's fairly easy to implement. I've finally implemented support for it in the development version of AS1600, as well. (I think I posted a link to it previously here in the forums.)

 

ECS-style flipping is very simple and effective. GroovyBee linked my previous post describing how it works for the ECS ROMs.

 

More generally, if you're developing a game, you need to decide for each 4K block of addresses whether that block will be fixed or page-flipped. (By 4K block, I mean the 4K words starting on a 4K address, boundary, such as $6000 - $6FFF.) If it's page-flipped, that 4K block can hold up to 16 4K segments, numbered $0 .. $F. Summarizing the tl;dr in the other post: Writing the value $xA5y to location $xFFF page flips the address range $x000 - $xFFF to page 'y'. If the cartridge has ROM for page 'y' in $x000 - $xFFF, then it will respond to reads in that range with the ROM data for page 'y'; otherwise, it will not respond to reads at all. If no ROM in the system responds to the read, then ultimately the CPU sees the value $FFFF. On reset (ie. ~MSYNC goes low), all page-flipped segments reset to page 0.

 

In the context of your board design, you'll need:

• 4 register bits somewhere for each page-flipped segment to indicate which page is flipped in. When one page is flipped in, all other pages are flipped out.
• Decoder logic for each page-flipped segment to determine (a) if the game cartridge has any ROM mapped to that page, and (b) what the MSBs of the real address are in your flash ROM.
• A connection to the ~MSYNC pin to reset to page 0 for all page-flipped segments on reset.
• Logic to ensure your cartridge does not respond to requests within a ROM segment if the currently selected page isn't valid for your cartridge. (This allows paged ROMs in different devices to coexist.)

I'd suggest picking one or two 4K ranges to support page-flipping on, and then guide folks using your design toward using those windows. Annoyingly, the range at $Fxxx has a potential GRAM corruption issue, as the last word of GRAM (at $39FF) aliases location $FFFF, the location you'd write to to page-flip $F000 - $FFFF. Of course, if you're willing to keep your logic programming flexible (ie. tune the logic to match the game), then you could offer paged ROMs wherever, including overlapping the ECS ROMs at $2xxx, $7xxx and $Exxx.

 

JLP and LTO Flash! have fully programmable memory maps, and so can support page-flipped ROMs in any 4K window in any combination.

 

As far as what games use it? A few JLP-based games out there do use page flipping, mainly out of convenience, even if it wasn't strictly required. I've made numerous demo carts for my own private use that push JLP's page flipping much further. That includes one cart that I managed to squeeze something like 8 games and diagnostics (including Space Patrol, WSMLB and a fully-populated Go For The Gold—which counts as 4 games) onto with an imposing Jean Luc Picard on the menu. Also, I've tested the Colossal Cave port I started work on, which has a huge 128K-byte location database.

 

[+5-11under]

intvnut, thanks for the details!... especially regarding using msync to reset the bank(s).

I have 64K available to devote to this (without trying to recover unused space from the main 64K space), so if I limit the set-up to one 4K block (times 16 banks), that should be somewhat easy to implement (most of the logic is done by a CPLD, so it's pretty easy to change which 4K block is used).

[intvnut]

intvnut, thanks for the details!... especially regarding using msync to reset the bank(s).

I have 64K available to devote to this (without trying to recover unused space from the main 64K space), so if I limit the set-up to one 4K block (times 16 banks), that should be somewhat easy to implement (most of the logic is done by a CPLD, so it's pretty easy to change which 4K block is used).

 

My own personal strategy for new code that uses paging is to keep most of the game ROM "flat", and only page-flip data sections. (For example, with Colossal Cave, I page flip based on where in the database the room description lives, and then read out/unpack the description for display.) That simplifies coding.

 

(The other pattern I've used is to shove multiple games that are unaware of page-flipping, and the menu does the page flip.)

 

If you don't have on-board RAM, then you can fit approximately 50K into the Intellivision memory map with a little effort:

• $2000 - $2FFF (4K)
• $4800 - $4FFF (2K)
• $5000 - $FFFF (44K)

(Note: Programmers will need to avoid using $8000 - $803F and $C000 - $C03F, but there's absolutely no harm letting your ROM respond to those ranges.)

 

There are some caveats. The ECS ROMs live at the following ranges:

• $2xxx PAGE 1
• $7xxx PAGE 0
• $Exxx PAGE 1

To ensure full ECS compatibility, you probably don't want to map ROM there yourself.

 

Also, the EXEC and ECS boot sequences probe for ROM at $7000 and $4800; if they detect ROM at either location (upper bits of the data at the location are all 0s), they'll short-circuit the boot sequence. So, programmers will need to be aware of this, either expecting to intercept the boot sequence, or plugging values like $FFFF at these locations to fool the ROM detection.

 

Let's say you ignore $4800 - $4FFF for a moment, and have 48K mapped. That gives you 16K left over that you can then use for paging. You can pick how you want spend that with some combination of paged segments vs. number of pages in each paged segment. For example, you could pick 4 address ranges that flip between 2 pages, or 1 range that flips between 5 pages, or something in-between. If you leave your CPLD design flexible enough, you could adapt to whatever the game needs.

 

I apologize for not elaborating further; I'm about to head out for the evening. Feel free to ask questions, though. :-)

[+cmart604]

Also, I've tested the Colossal Cave port I started work on, which has a huge 128K-byte location database.

 

Wait. What? I'm sure you said some other words but my brain only processed these words

[+5-11under]

(Note: Programmers will need to avoid using $8000 - $803F and $C000 - $C03F, but there's absolutely no harm letting your ROM respond to those ranges.)

 

There are some caveats. The ECS ROMs live at the following ranges:

• $2xxx PAGE 1
• $7xxx PAGE 0
• $Exxx PAGE 1

To ensure full ECS compatibility, you probably don't want to map ROM there yourself.

 

Thanks again!! I appreciate your time and effort here!

 

Just to be sure, if I am going to use the $C040-$CFFF range as part of a program, are you saying it's okay to enable the ROM for all off $C000 -$CFFF? Same for $8xxx?

 

Plugging a cart that uses/enables cartridge ROM at $2xxx, $7xxx, or $Exxx into a stock Intellivision is perfectly fine?

Plugging a cart that uses/enables cartridge ROM at $2xxx, $7xxx, or $Exxx into an ECS unit would or could cause bus contention issues?

By the way, I'm currently using a 128K (x 16 bit) memory chip, so I have 64K easily available for bankswitching, and more if I want to get fancier. I also plan to use a 64K (x 16 bit) RAM chip (that can be addressed pretty much anywhere, including the $8040-$9EFF range). I'm guessing jzintv would work just fine with this.

[intvnut]

 

 

Thanks again!! I appreciate your time and effort here!

 

Just to be sure, if I am going to use the $C040-$CFFF range as part of a program, are you saying it's okay to enable the ROM for all off $C000 -$CFFF? Same for $8xxx?

 

Plugging a cart that uses/enables cartridge ROM at $2xxx, $7xxx, or $Exxx into a stock Intellivision is perfectly fine?

Plugging a cart that uses/enables cartridge ROM at $2xxx, $7xxx, or $Exxx into an ECS unit would or could cause bus contention issues?

By the way, I'm currently using a 128K (x 16 bit) memory chip, so I have 64K easily available for bankswitching, and more if I want to get fancier. I also plan to use a 64K (x 16 bit) RAM chip (that can be addressed pretty much anywhere, including the $8040-$9EFF range). I'm guessing jzintv would work just fine with this.

 

 

For $4000 - $403F, $8000 - $803F and $C000 - $C03F, the System RAM isolates the CPU side of the bus from the STIC registers, but it does not isolate the STIC from the CPU side of the bus. Furthermore, the STIC side of the bus is only 14 bits, which is how we end up with aliasing. So reads to these locations do not return STIC contents, but the STIC still sees the read as a read in the range $0000 - $003F. (That affects location $21—aliased at $4021/$8021/$C021—as it switches between Color Stack and Foreground/Background mode based on whether $21 was read or written.)

 

Also, the STIC sees all writes to $4000-$403F, $8000-$803F and $C000-$C03F as writes to $0000-$003F. That only matters if you want to map RAM in those locations, and programs try to write to that RAM. For example, the ECS maps RAM at $4000 - $47FF, but programs only use $4040 - $47FF.

 

For ROM at $2xxx, $7xxx and $Exxx, it's perfectly safe to map ROM in those locations on an unexpanded Intellivision. If the EXEC detects ROM at $7xxx (upper 6 bits of location $7000 are 0), it will jump to $7000 directly, very early in the EXEC boot sequence. But, there are no bus conflicts or anything else.

 

If you attach an ECS, you could have bus conflicts with the ECS ROMs when the ECS ROMs are paged in. ECS ROMs map to $2xxx page 1, $7xxx page 0, and $Exxx page 1. So, immediately after reset, $7xxx is visible, but $2xxx and $Exxx are not. However, the ECS boot sequence switches in the ROM at $2xxx. So, if you have unpaged ROM at $2xxx, $7xxx you will end up with bus conflicts.

 

The ECS has a third segment at $Exxx page 1. This ROM segment isn't consulted by the ECS during bootup. You can safely have an unpaged segment at $Exxx if your game switches $Exxx to page 0 (which, for an unpaged ROM does nothing, but for a paged ROM ensures that only page 0 is selected). Incidentally, this is what WSMLB does, as it has fixed ROM at $Exxx. It just writes $EA50 to $EFFF early in its setup and carries on from there.

 

So, with 128Kx16-bit of flash/EPROM, you're at about the same ROM capacity as JLP. You should be able to go nuts with page flipping.

 

And yes, jzIntv should be fine with all of this.

Edited September 28, 2014 by intvnut