ColecoVision T&T (RPG) very early techdemo

[PkK]

A few month ago I've started working on Tunnels & Trolls for the ColecoVision. Due to lots of university work I wasn't able to make anything really interesting yet though.

 

However I just took my old code and made it into a little techdemo. It's a map viewer. The map is rather big for a ColecoVision game. Most of it is just a huge swamp. However you start in the map's upper left corner and it takes about 6 minutes of continuous scrolling to reach the swamp.

 

Here's a map description so you don't get lost:

You start in a small rural village with some houses, a pond and some fields where crop is planted. Some trees surround the village. Two roads lead out of the village. One leads to the south, where it approaches some farms (you find them south and west of the road at the roads' second big turn to the east) before it turns east and north. The other road leads east, then turns south (southwest of the turn is a forest, east of the turn is some rocky area and further east a forest and a river). Where the two roads meet another road goes to the east, leading to a river. On the other end of the bridge a gate guards the entry to a town. North of the town is a forest. If you follow the road for some time, then go southeast where it splits or follow the river leading south you'll reach a lake. There's a town at the lake's north shore. Farms are scattered throughout the area.

 

I've attached screenshots of the pond in the starting village and the bridge with town gate.

 

As you can see this simple techdemo needs about 29KB, so I'll have to sacrifice some of what you see in this demo to be able to make a game out of it.

 

Merry christmas to all of you!

Philipp

TT.rom.gz

Edited December 23, 2007 by PkK

[Mark2008]

6 minutes of continuous scrolling to reach the edge! WOW...thats an expansive world that you have started.

 

I set blueMSX to run at 1000% emulation speed, and it was still quite sometime before it scrolled through it.

 

I think an RPG is a great genre for the colecovision, I cannot wait to see more of this game.

[Blackjack]

Highly anticipating your work! Very Cool.

[Bruce Tomlin]

As you can see this simple techdemo needs about 29KB, so I'll have to sacrifice some of what you see in this demo to be able to make a game out of it.

I'm glad to see someone else try an overhead view RPG. It's clear that the CV video chip is capable of it at least. (and be sure to play the MSX-1 version of Dragon Quest II and look for subtle things about how its graphics work).

 

Of course that "29K for just a demo" thing, and lack of any emulator support for bank switching kind of killed it for me. The Sega Genesis was like a deep cushy sofa after the CV. You could probably figure out how to optimize your map data, but at some point you run out of room. If it weren't for that pitiful 1K of RAM, you could just decompress sub-areas as necessary.

[Mark2008]

As you can see this simple techdemo needs about 29KB, so I'll have to sacrifice some of what you see in this demo to be able to make a game out of it.

I'm glad to see someone else try an overhead view RPG. It's clear that the CV video chip is capable of it at least. (and be sure to play the MSX-1 version of Dragon Quest II and look for subtle things about how its graphics work).

 

Of course that "29K for just a demo" thing, and lack of any emulator support for bank switching kind of killed it for me. The Sega Genesis was like a deep cushy sofa after the CV. You could probably figure out how to optimize your map data, but at some point you run out of room. If it weren't for that pitiful 1K of RAM, you could just decompress sub-areas as necessary.

 

I don't want to be pesky, but 32k is the standard amount Colecovision will address...it isn't the largest game you can make on a Colecovision. Even the 1984 game 'Destructor' was 54K in size, according to Coleconation. (*Edit: I just noticed a thread where this was discussed as being controversial...so without comment on that, OpCodes soon to be released bank switching carts should break the 32k barrier).

 

BlueMSX supports the megacart in emulation already.

 

So.... no doubt it is easier from the perspective of not having to either manufacture your own bank switching cart, or contract for a Megacart run... to stick to the 32k limit.

 

But if a game is under development for later 2008...I would certainly research breaking the 32k barrier....

 

If I'm completely wrong in my understanding, please correct me.... I'm thinking along the same lines, in terms of whether to break the 32k barrier myself...(also looking at some compression ideas too).

 

And on that thought, OpCode may release a memory cart as well...in my opinion, there is already a memory cart of sorts....its the ADAM computer expansion....maybe thats thinking outside the box a bit, but ...it has more than 1k of ram, and is technically a Colecovision expansion module....does a whole lot more than add memory, but it does that as well.

Edited December 28, 2007 by Mark2008

[Bruce Tomlin]

I don't want to be pesky, but 32k is the standard amount Colecovision will address...it isn't the largest game you can make on a Colecovision. Even the 1984 game 'Destructor' was 54K in size, according to Coleconation. (*Edit: I just noticed a thread where this was discussed as being controversial...so without comment on that, OpCodes soon to be released bank switching carts should break the 32k barrier).

It's not "controversial". Just look at the ROM file: "Destructor (1984) (Coleco).col" is 32768 bytes. Aside from possible multicarts, until very recently there was no ColecoVision cartridge larger than 32K. And even if Opcode released something larger than 32K, I'm pretty sure it was a multi-game cart, not a single game larger than 32K.

 

And having tried to design one, I can say that making a bank-switching CV cart is not trivial. And by "not trivial", I do not mean "impossible", just "not easy with just a single GAL chip".

 

The main problem is that (like the 2600), it the slot doesn't have a R/W line, so you can't just use a write to trigger the bank switch, like on the 7800. This means that you have to do it with reads. The CV flash cart has an FPGA or CPU which can detect a sequence of 14 reads to specific pseudo-random addresses, two of which transmit 8 bits of bank number. However, to make a multi-bank game requires trampoline routines in the 1K RAM (the bank select code alone takes 51 bytes).

 

I was thinking about reserving 256 bytes or so to flip the second half of ROM (since my game would have been a big-data game), but it still would have been a bit much with a 28-pin GAL chip. BF00-BFFF seemed like the best area for this, since those bytes could be read by swapping bank 0 into the bank area. I suppose that if writes were used with a specific address, and an extra latch chip was added, that would free up GAL pins to do better decoding with a 2-chip bank select.

 

But there's still the problem that every time you come up with a new bankswitch method, it takes time for it to get added to emulators (if it ever happens). Meanwhile, how are you going to debug your game? I have an EP-180 ICE with full overlay RAM, so I could have added another 23K, but I would have had to upload up to 47K bytes in hex at 9600 baud.

 

If only Coleco hadn't skimped on the cartridge slot, and had included a R/W line and A15.

 

So.... no doubt it is easier from the perspective of not having to either manufacture your own bank switching cart, or contract for a Megacart run... to stick to the 32k limit.

 

But if a game is under development for later 2008...I would certainly research breaking the 32k barrier....

Or you could do what I did, and consider moving up. The SMS is uncommon enough to not be worth manufacturing carts for, and it still needs bank switching. The Genesis has lots of RAM, lots of ROM, the video chip is very similar, and bank switching is very rare. My RPG didn't even grow by much to change from the 2-color world of Coleco to the 16-color world of Sega.

[PkK]

6 minutes of continuous scrolling to reach the edge! WOW...thats an expansive world that you have started.

 

I set blueMSX to run at 1000% emulation speed, and it was still quite sometime before it scrolled through it.

 

I think an RPG is a great genre for the colecovision, I cannot wait to see more of this game.

 

This world was made just for the techdemo. The game world will look different. Since I've got a lot of university stuff to do it will take time 'till this game is done. However I intent to release another techdemo in the first half of 2008. The second techdemo will show the combat system.

 

Philipp

[PkK]

Of course that "29K for just a demo" thing, and lack of any emulator support for bank switching kind of killed it for me. The Sega Genesis was like a deep cushy sofa after the CV. You could probably figure out how to optimize your map data, but at some point you run out of room. If it weren't for that pitiful 1K of RAM, you could just decompress sub-areas as necessary.

 

I'm already "decompressing" (mostly generating procedurally) sub-areas as needed. The map would need 1GB when completly uncompressed. Emulator support for bank switching shouldn't be that much of a problem since the (to me) most important emulators, xmess and Meka come with source. I've also written my own emulator, too (never released since quality is not very good, but runs my programs and some original ones such as LadyBug).

 

Philipp

[PkK]

But if a game is under development for later 2008...I would certainly research breaking the 32k barrier....

 

If I'm completely wrong in my understanding, please correct me.... I'm thinking along the same lines, in terms of whether to break the 32k barrier myself...(also looking at some compression ideas too).

 

And on that thought, OpCode may release a memory cart as well...in my opinion, there is already a memory cart of sorts....its the ADAM computer expansion....maybe thats thinking outside the box a bit, but ...it has more than 1k of ram, and is technically a Colecovision expansion module....does a whole lot more than add memory, but it does that as well.

 

When going beyond 32K there should be a really good reason for it. I have not done it for my previous four games, and will not do so for my next game but I'll probably do so for T&T.

 

I found a combination of RLE and huffman coding to be very efficient at data compression, while still feasible with the limited amount of RAM on the CV. See my colecovision library at http://www.colecovision.eu/ColecoVision/de...ent/libcv.shtml for an implementation.

 

Philipp

[A Sprite]

Your water is the most inviting I've seen in any 8 bit world. You give texture and variety to even a common grass tile. If your trees seem to disappear for lack of shadows or sunshine, it's a faint complaint, and understandable given the limited color available.

 

Congratulations.

 

You should be giving lessons in art design. I look forward to seeing more of your work.