ColecoVision RAM Expansion - How much is enough?

[-=Lindsey=-]

I've been kicking around some hardware ideas lately to add RAM to the ColecoVision via the expansion connector. There is a nice chunk in the memory map from $2000 to $7FFF. Adding RAM in that are would be pretty easy, giving a total of 24K of RAM and leaving the cartridge port space ($8000-$FFFF) untouched. Then I started thinking about bank switching the RAM to add even more but this would add considerable complexity to the design, by comparison. In short, it's the difference between using a GAL22V10 for the logic and having to move up to a 44 pin CPLD. I could accomplish the RAM bank switching with just the 22V10 but I would also like to add ROM to the board to replace the original BIOS and there are not enough I/O pins on the 22V10 to do both (Bank switched RAM and BIOS ROM) and still have byte-level address decoding.

 

So my question to the homebrew coders is:

 

How much RAM is enough? Is it worth the extra hardware cost and complexity to bank switch the RAM or is 24K enough?

[Pixelboy]

Honestly, my immediate answer would be that 1K is enough already. The only projects where RAM expansion would be beneficial would be MSX ports, because the larger majority of the interesting cartridge games released on MSX use more than 1K of RAM. For games made from scratch (in C language in particular) most ColecoVision homebrewers will tell you that they can easely manage with only 1K of RAM.

 

The real question is, what would a homebrewer do with 24K of RAM? There is of course great potential (like perhaps a cartridge version of the Dragon's Lair ADAM game, for example, which would likely sell like hot cakes) but given the fact that game projects done with 1K of RAM can still require months of work, most of it taken out of the homebrewer's free time, you've offering a hardware solution that most homebrewers don't really need. It's just a plain fact: The number of different games you can make with just 1K of RAM is already infinite. They will all be small games, but that's what makes the ColecoVision such a great platform for homebrewers: Projects remain relatively small in scope, but after months of development and debugging, the programmer is just fed up with his project, and he's glad it's over when it's over.

 

Opcode has been working on a module that combines a 16K RAM expansion with an extra MSX PSG sound chip (and also some other secondary bells and whistles) and what makes his project enticing is the number of games that he can offer with it, namely Donkey Kong Arcade, Goonies, Knightmare, King's Valley, Yie Ar Kung-Fu 2 and many more. Without games to go with it, a RAM expansion module is doomed to remain a paperweight, because CV homebrewers don't want (or even need) to restrict the number of buyers of their games to the number of RAM module owners.

[-=Lindsey=-]

Honestly, my immediate answer would be that 1K is enough already.

 

It really depends on what you want to do and what kind of game you want to write, but in many cases you're right. Obviously 1K has been enough to develop 99% of all the great games that currently exist for the system.

 

The only projects where RAM expansion would be beneficial would be MSX ports, because the larger majority of the interesting cartridge games released on MSX use more than 1K of RAM.

 

That's debatable. Additional RAM could definitely be beneficial for new homebrew titles. But again, depending on what kind of game you want to write and if you can make use of more RAM in that code. If all the cool MSX games use more than 1K it stands to reason that the ColecoVision could benefit from more than 1K. The question of whether 24K is enough has obviously been answered

 

For games made from scratch (in C language in particular) most ColecoVision homebrewers will tell you that they can easely manage with only 1K of RAM.

 

Do people writing in assembly tend to have more RAM limitation problems than people writing in C? That seems counter intuitive. Maybe people writing in C tend to write less complicated games? Why is that? Is it a RAM or ROM limitation?

 

The real question is, what would a homebrewer do with 24K of RAM?

 

Recursive functions, tons of global variables, etc... It's really up to the programmer but my original question is starting to seem a little ridiculous because 24K is obviously WAY more than enough.

 

There is of course great potential (like perhaps a cartridge version of the Dragon's Lair ADAM game, for example, which would likely sell like hot cakes) but given the fact that game projects done with 1K of RAM can still require months of work, most of it taken out of the homebrewer's free time, you've offering a hardware solution that most homebrewers don't really need.

 

Adding RAM to the console shouldn't make development much more difficult. If anything it will make it easier in some ways. You're right though, more complicated games will definitely take more time to develop.

 

It's just a plain fact: The number of different games you can make with just 1K of RAM is already infinite.

 

You could make an infinite number of games with virtually no RAM at all too. Well... I guess you would need the VRAM

 

They will all be small games, but that's what makes the ColecoVision such a great platform for homebrewers: Projects remain relatively small in scope, but after months of development and debugging, the programmer is just fed up with his project, and he's glad it's over when it's over.

 

Agreed. I still think it would be cool to expand the horizons of the system and keep the cost reasonable enough that it can make the whole thing more fun for the developer and player.

 

With 32K SRAMs under $2 it just makes sense to add RAM to the ColecoVision. What you've made me realize is that a dedicated piece of hardware connected to the expansion port to add that RAM is probably not the best approach. RAM bank switched and added to the cartridge address space is more painful to access in software but ultimately the best overall approach.

 

Opcode has been working on a module that combines a 16K RAM expansion with an extra MSX PSG sound chip (and also some other secondary bells and whistles) and what makes his project enticing is the number of games that he can offer with it, namely Donkey Kong Arcade, Goonies, Knightmare, King's Valley, Yie Ar Kung-Fu 2 and many more. Without games to go with it, a RAM expansion module is doomed to remain a paperweight, because CV homebrewers don't want (or even need) to restrict the number of buyers of their games to the number of RAM module owners.

 

You're right in that any expansion is going to need games written for it to be useful and an adapter connecting to the expansion port limits the market to only people with that expansion. The solution is definitely in the cartridge connector. I just got distracted by that damn expansion connector because it's so clean and easy to access the logic

 

I guess I should have asked BEFORE designing the board. hehe

[GroovyBee]

Thats one of the main problems with making new "expansion style" hardware for old machines. You have to give people reasons to want it. That means either you code games for it yourself or you persuade other programmers to write/port for it.

[Pixelboy]

Thats one of the main problems with making new "expansion style" hardware for old machines. You have to give people reasons to want it. That means either you code games for it yourself or you persuade other programmers to write/port for it.

 

Correct. The way I see it, aside from Opcode's Super Game Module, the only other kind of expansion module that would be somewhat worthwhile would be a mini-ADAM module, which would essentially be a subset of a real ADAM computer: Put the raw binary contents of a Super Game DDP onto a 256K bankswitched CV cartridge, and have the mini-ADAM module run the software from the cartridge the same way a real ADAM would read a DDP. This implies having the ADAM's BIOS included inside the mini-ADAM, together with 24K of RAM and a physical port for connecting the ADAM keyboard. I think this would be cool to have, but admittedly, it would be hard to implement.

 

Another interesting idea for an expansion module would be a barcode reader. Then you could have something similar to the Barcode Battler, which could be used by a number of specially-designed games, like RPGs or boardgames.

[Pixelboy]

Sorry, messed-up my edit. Please ignore.

Edited January 9, 2012 by Pixelboy

[Pixelboy]

Do people writing in assembly tend to have more RAM limitation problems than people writing in C? That seems counter intuitive. Maybe people writing in C tend to write less complicated games? Why is that? Is it a RAM or ROM limitation?

 

Most homebrewers just prefer writting in C, and letting the compiler/linker create the ROM for them. It's not really a question of RAM limitation. Although when programming in C, you have to keep your fingers crossed that the stack won't grow to the point where it will overwrite data elsewhere in RAM. To avoid this problem, and other RAM-related problems as well, programmers try to minimize their RAM usage, so that often leads to "less complicated games".

 

It's just a plain fact: The number of different games you can make with just 1K of RAM is already infinite.

 

You could make an infinite number of games with virtually no RAM at all too. Well... I guess you would need the VRAM

True, and that raises another issue, which is that savvy programmers can use unused parts of the VRAM as auxiliary RAM for their games.

 

You're right in that any expansion is going to need games written for it to be useful and an adapter connecting to the expansion port limits the market to only people with that expansion. The solution is definitely in the cartridge connector. I just got distracted by that damn expansion connector because it's so clean and easy to access the logic

 

I guess I should have asked BEFORE designing the board. hehe

 

Yep, RAM in the cartridge is pretty much the way to go if you're going to add more RAM, but getting the hardware passed the prototype phase is only half of the project. The other half is writing programs and general documentation that clearly shows how to use the extra RAM in standard C programs. And it has to be super-easy to program for (and also to compile) otherwise most CV homebrewers won't bother with it.

[65Gamerguy]

Anything to help out the homebrew scene I am for. I say go for it Lindsey. You have some great ideas and maybe your ideas might lead to something better than we all know yet.

Edited January 10, 2012 by 65Gamerguy

[+5-11under]

There's always the LotD method: 24K ROM plus 2K write and 2K read at the high addresses (mirrored as WRWR in the upper 8K space). My LotD PCB should also be able to handle 4K write and 4K read, although that hasn't been tested. It's not too efficient, though, as far as total memory available, compared to Lindsey's idea of latching the R/W line.

[youki]

Having more ram is always more confortable in general.

 

But as homebrewer on colecovision, i don't really care.

 

What i like is juggle with limitations of the hardware and try to create the best game as possible.

 

So 32k of rom and 1 k of ram , it is only what i need. Even if sometimes it is really frustrating and i would love to have more ROMs , the fact to have only 32k at least force me at one point in time to stop to add thing and complete the game!.

 

Adding Ram , or creating Super Game Module for an old console for me , make no sense. If you find the colecovision not enough powerfull... use a Sega Master System. (that is more a less that would have been a colecovision 2!).

 

Of course if you come with a solution where all is in the cartridge (no expension module) and really easy to use from C , and with Emulator that support that solution , and that these cartrigde are easy to produce and not to expansive. I could find a interrest in using that additionnal RAM. Otherwise no.

 

And for me , the more frustrating limitation of the colecovision is the 4 sprites by row. not RAM or ROM.

[-=Lindsey=-]

Having more ram is always more confortable in general.

 

But as homebrewer on colecovision, i don't really care.

 

What i like is juggle with limitations of the hardware and try to create the best game as possible.

 

So 32k of rom and 1 k of ram , it is only what i need. Even if sometimes it is really frustrating and i would love to have more ROMs , the fact to have only 32k at least force me at one point in time to stop to add thing and complete the game!.

 

Adding Ram , or creating Super Game Module for an old console for me , make no sense. If you find the colecovision not enough powerfull... use a Sega Master System. (that is more a less that would have been a colecovision 2!).

 

Of course if you come with a solution where all is in the cartridge (no expension module) and really easy to use from C , and with Emulator that support that solution , and that these cartrigde are easy to produce and not to expansive. I could find a interrest in using that additionnal RAM. Otherwise no.

 

And for me , the more frustrating limitation of the colecovision is the 4 sprites by row. not RAM or ROM.

 

Agreed on all counts. Seems like the most important things are emulator support and ease of programming. I think the first step is going to be creating a prototype cart and writing the C code to make it work. That should take a couple months

[-=Lindsey=-]

The cost is a bit of a concern. Obviously the cost will be more than a basic cart with an EPROM and a 16V8 but how much more is yet to be seen. The raw cost shouldn't be more than a few bucks more but they will take a lot longer to assemble.

 

So... what would be an acceptable cost for a finished cart PCB? Obviously lower is better but how high is too high?

Edited January 10, 2012 by -=Lindsey=-

[+Yurkie]

I think with or without the added RAM $10 if they can be programmed via USB is fine. Then if you go to all the trouble of adding ram and writing programming software, is anyone going to program a game that needs the RAM? If so I am guessing your probably looking at a max of $20 for a PCB.

[+nanochess]

There's always the LotD method: 24K ROM plus 2K write and 2K read at the high addresses (mirrored as WRWR in the upper 8K space). My LotD PCB should also be able to handle 4K write and 4K read, although that hasn't been tested. It's not too efficient, though, as far as total memory available, compared to Lindsey's idea of latching the R/W line.

The LotD method is supported by BlueMSX. I remember seeing a post by Retroillucid telling how to do it.

Personally as programmer, 1K of RAM is barely enough for games, as the video screen is 768 bytes some tricks only can be done with 2K .

When I've crunched Zombie Near for Colecovision (written purely in assembler, C language would made it impossible), I needed space for the title screen so I compressed music and uncompressed it on VRAM, it is crazy!

With 8K of RAM would be enough for someone to port MSX goodies like Nemesis .

But at the end, the limitations make you more smart