ColecoVision Megacart

[PkK]

I just did a few first successfull test of my ColecoVision "Megacart". I'll use the pcb name, L5 in the rest of the post.

 

While there are many different configurations posible I'll just talk about the one I tested in this post.

 

As can be seen on the picture, there are 3 chips on L5. To the upper left we see a 4 MBit Flash ROM. In the current configuration the lower 24 K are mapped as usual with another 4K bank above. Any 4 K of the Flash ROM can be mapped into these 4 K of cartridge address space. Mapping is done by writing the number of the desired page to memory address 0xfffd. This written number will then be used for the Flash ROM's upper address lines when reading from the 4K bank. To the upper right we see a 64 KBit EEPROM. It provides 8 KB of memory for savegames. The CPLD in the middle manages access to Flash and EEPROM.

 

I have tried to optimize the design for low cost. From the cost of the board and components, this should be at most 1.25€ more expensive than my standard board with a 32 K EPROM.

However due to the small, fine surface mount components I can't assemble them all by hand. It took some effort to solder the prototypes.

 

L5 has been developed mainly as a platform for a future Tunnels & Trolls game. I think for an RPG I need lots of ROM to store the large world with it's map, monsters, NPCs, etc and players would want to be able to save their games.

 

Philipp

[Pixelboy]

That's super cool, Philipp!

 

I know a certain retroillucid who will be interested in this for a future project...

 

I do have a related question, however. With a C compiler, is it possible to control where the compiled binary data is written in the ROM? As I understand it, you have to keep a very precise control over where the data is placed in order to perform bankswitching... I've never looked into this problem before now, so that's why I'm asking. I'm sure placing binary data exactly where you want it in assembly is relatively easy, but C language?

 

Anyhow, great job!

[PkK]

I do have a related question, however. With a C compiler, is it possible to control where the compiled binary data is written in the ROM? As I understand it, you have to keep a very precise control over where the data is placed in order to perform bankswitching... I've never looked into this problem before now, so that's why I'm asking. I'm sure placing binary data exactly where you want it in assembly is relatively easy, but C language?

 

Well, it depends If you just want to have data at a specific place many C compilers have a #pragma directive for that. With a little bit more work (for the compiler writers) the compiler does some more of the work for you (the application developer), so you just call functions across banks normally and the compiler do the bankswitching for you (sdcc's PIC port does that; the Z80 doesn't yet).

 

Philipp

[retroillucid]

I know a certain retroillucid who will be interested in this for a future project...

 

I've already ordered a batch of 50 from Bryan

 

PKK: You did a REALLY NICE job!

[newcoleco]

With Hi-Tech C compiler, you can add codes in assembler in your C project. Even if I did experiment using assembler a couple of times to switch banks, it was only for multicart projects, not bigger rom projects. By using assembler, you can specify addresses for the data rather than using references (or pointers). So, if the game engine is in the first 16k and the rest is data, you can use an hex editor to merge all the parts together to fit the pcb specificiations. I did something like this in the past and it works fine, but it was not related to a game project.

[joyrex]

Great job! I have a few questions though;

 

Mapping is done by writing the number of the desired page to memory address 0xfffd. This written number will then be used for the Flash ROM's upper address lines when reading from the 4K bank.

I thought the data bus on the Coleco cartridge port was read-only? Since you mention writing the actual bank, that doesn't seem to be the case? If not, a coleco cartridge could be far more advanced than I thought before (eg. adding static ram).

 

To the upper right we see a 64 KBit EEPROM. It provides 8 KB of memory for savegames. The CPLD in the middle manages access to Flash and EEPROM.

Why not use the flash for savegames? We have done that in one of our msx games.

Edited October 5, 2008 by joyrex

[PkK]

I thought the data bus on the Coleco cartridge port was read-only? Since you mention writing the actual bank, that doesn't seem to be the case? If not, a coleco cartridge could be far more advanced than I thought before (eg. adding static ram).

It is not read-only. However there is no R/W signal available at the cartridge port, so you can't easily distinguish between read and write accesses. So each address has to be used for either reading or writing.

 

Why not use the flash for savegames? We have done that in one of our msx games.

Acessing flash is a little bit complicated. You need to do that 55/AA sequence for erasing of sectors, etc. Doing that with the ColecoVision would require to place the CPLD in between the cartridge port and the flash to insulate the flash from all the thing that can happen on the cartridge port. This would require a bigger CPLD.

Philipp

[joyrex]

I thought the data bus on the Coleco cartridge port was read-only? Since you mention writing the actual bank, that doesn't seem to be the case? If not, a coleco cartridge could be far more advanced than I thought before (eg. adding static ram).

It is not read-only. However there is no R/W signal available at the cartridge port, so you can't easily distinguish between read and write accesses. So each address has to be used for either reading or writing.

Ah, now I understand. But, then it would also allow some logic to swap a whole block into write only mode. Eg, when reading on some control address, the upper 4k could be swapped to allow writing to ram, but reading would fail. When reading that control address again, the upper 4k would be in read only mode again. It will probably slow down your programm when using this construction though.

[PkK]

Ah, now I understand. But, then it would also allow some logic to swap a whole block into write only mode. Eg, when reading on some control address, the upper 4k could be swapped to allow writing to ram, but reading would fail. When reading that control address again, the upper 4k would be in read only mode again. It will probably slow down your programm when using this construction though.

 

Yes (you couldn't easily use this mechanism from interrupt handlers though).

 

Philipp