Colecovision RPG

[Bruce Tomlin]

All right, this checking into the map width thing got me back into the programming mood again. First I fixed the stupid bug, then I made a new map and graphics for a merchant and a store counter. Then I added a new scripting instruction to handle buy/sell with a merchant.

 

I also made the "start map" handler (which I use to change the music) run immediately instead of waiting until the next time around the main loop. This means that the demo script on the "8" key will now change music when the map changes.

 

And with all of these changes in there, I'm basically at a point now where I can start adding in actual plot and story. There's still a few minor things I want to tweak, but nothing to get in the way of actual building.

 

The bloat is up to 20K, but now I can shrink maps to exactly the size I need. The only reason I didn't is that I want to do some expansion in the house.

 

EDIT: oh yeah, and anyone who wants to make a demo cart to show off at Cinciclassic, go right ahead. Since I'm still keeping my title a secret, just scribble "ColecoVision RPG v020" on the label.

rpg_020.bin

Edited March 19, 2006 by Bruce Tomlin

[Bruce Tomlin]

I guess it's about time for a quick summary of the current keypad assignments:

 

1 - window scrolling test with engrish text

2 - flags scripting test showing chest open/close status

4 - name entry test

5 - inventory / use / drop (the only key that isn't a test!)

8 - scripting test, wizard goes to bed

2+3 simultaneous - tile test (fire button 4 on super action controller)

 

in the menu windows:

joystick - changes selection

left fire - accept

right fire - cancel

0 - cancel

 

in the name entry screen:

joystick - changes letter selection

left fire - moves cursor right

right fire - backs up

0 - goes to the END selection

# and * - moves cursor left and right through name

[Pixelboy]

I finally tried it with my USB cart on my CV, and I must say it's absolutely awesome! I'd love to see how far you could go with a sizeable bankswitching cart!

[Bruce Tomlin]

* added a new map for a castle exterior

* moved sprites out of their holding positions in the first map

* changed the money name

 

And I've finally decided that I need to do something about map bloat before I make a lot of maps. Right now each map tile takes up two bytes, from two different arrays. The first array is just the tile ID, and while it is likely to go over 63, it is not likely to go over 127. The second array is mostly zero, or 80H where you can't go. So right there I could combine both of those and the second table would be mostly zero.

 

Since the only other thing I need fast access to is the changeable tile status, that can go into a special table, and all the other special tiles can now go into another table. This will probably save 2.5K just with the maps it has now. And while I'm at it, I can make the changeable tiles change into any other tile, not just ID+1, so I could, say, make a gate in the castle wall that appears or disappears with a flag setting. The other benefit is that changeable tile status will be separate from special tile status, so you will be able to walk over changeable tiles.

 

I'm doing well on code size, as it's still under 8K of code. I really, really need to keep it under 16K for my planned bankswitching method (the one for real carts, not the flash cart).

rpg_021.bin

[newcoleco]

First, get a copy of the coding guide: http://www.geocities.com/newcoleco/cv-coding-guide.zip

 

I don't know how much of that was from Coleco and how much of that was from Daniel B. I have my own different names for most of the symbols because I disassembled it on my own years ago.

 

The scale chart is on page 193. The sound format is shown on pages 190-191. (Note that the first line of "NOISE" on p191 should be all zeros.) In the musicbox demo, all the tunes are broken up by channel, but there are still some noise notes mixed with regular notes. Note that the rest, end, and repeat notes may ignore the channel number. Also, I found what appears to be a bug with the "special effect" note that nobody used, and made a note of that in my musicbox disassembly.

All the symbols for the coleco bios listing in this document came from two official coleco documents (one for Adam computer, the other for ColecoVision). The part I modified in the bios listing is basically the original comments to make some block of functions fit into fewer pages. For the sound and video information in the annexe, it's the way I understand the technical documentation that was made for electronic experts, not for software programmers. Please note that it taked me months to re-write the coleco bios listing because no scanner and/or no ocr software was good enough to make an electronic copy of this precious information. So, I hope I didn't re-write it for nothing.

 

And if you find something interresting to be added in the doc, let me know. Someone already mentionned some points missing like the controllers and expension modules that may be useful for some special projects.

 

Continue your good work, Bruce!

 

To all the coleco programmers : Let me know if you want to show your coleco project during the Arcadia festival (in Montreal). It supposed to be bigger than last year. I will be there to present the homebrew scene and particulary the new ColecoVision games, and I will probably do a presentation about this passion to program new games for the good old classic systems.

Edited April 3, 2006 by newcoleco

[Bruce Tomlin]

I'll have to look up what differences there were, but once I cleaned up the typos and added a few symbols that were missing, I got the whole thing to assemble, and the binary was right the first time. I know what you mean about getting it typed in, as I had to do the same for the 7800 BIOS listing, which was a bit smaller.

 

So anyhow, the operation was a success, and the patient survived. Yesterday evening I went through the four or five steps that were needed to convert the map like I needed it to be, and I did in fact save over 2500 bytes, mostly in the data, but I did manage to simplify some code too.

 

And now it's back to the data mines for more art and maps.

Edited April 3, 2006 by Bruce Tomlin

[Bruce Tomlin]

Today I added text compression. Thank goodness I had an ICE to debug it so quickly. That saved me 200 bytes or so, and did away with the spoiler factor of looking at it in a hex editor.

 

Even after adding another map, I'm still 2000 bytes smaller than before.

 

rpg_022.bin

P.S. yes, there is a way to open the gate. The gate is a new trick I can do with my improved display engine.

 

And yes, I've seen the uploads on alt.binaries.emulators.misc. Don't worry, I'm saving the source to every version, too.

[Bruce Tomlin]

A couple of weeks ago I started on the main room of the castle, and also fixed the sound code so that going between two rooms with the same background music didn't restart the music.

 

I got some good work done tonight, adding a guard sprite and a downstairs to the castle, and I don't think I'll have much of a chance to do anything else for a few days, so I'm going to post what I've got now.

rpg_023.bin

[vdub_bobby]

Looks good!

[Pixelboy]

I tried the latest binary, and it's definately getting cooler by the minute! So will there be a fighting mode to this thing? The main character is a wizard, so I'd like to cast a couple of spells on some unsuspecting goblins or slimes...

[+thegoldenband]

I'm excited to see how this one develops -- any progress of late?

[Bruce Tomlin]

I've been taking some time to play a few games since getting a DS Lite. I've only written down a few small snatches of plot ideas so far.

 

I did manage to save a few more bytes with a really simple trick. A few bytes don't make sense in the color tables, any one with the same foreground and background color, and any one using transparent as the foreground color. So every 8x8 cell that used the same color table eight times was replaced with FF plus the color table. I was totally blown away to find that I saved about 850 bytes just with that alone. I still haven't tried to see what I could save with a 2-byte reference for common color tables. For that I would use 0xxx where the 12 bits of xxx represent some kind of offset. If I align the common color table on an 8-byte boundary, that could specify any address from 8000-FFFF with just a little shifting.

[vdub_bobby]

Any more progress with this?

[CV Gus]

This game looks terrific- sort of like those NES games, with some Ultima.

 

Any console can do decent adventure games, but one that will keep you coming back- this could be one of them.

 

So far, it looks great. If such games had come out back then, the NES could never have gotten past the CV.

 

Keep it up!

[Uzumaki]

Wow I'd love to see this finished some day. I loved 2D RPG games like Ultima series.

[Bruce Tomlin]

Well, right now it's set aside so I can work on other things.

 

Basically I got laid off 2 1/2 months ago, and only whis week got the (big) final severance check. And those first two months (when I was still an employee only with no job responsibilities) were real busy for various reasons. Since I now have way more than a year's worth of savings (and I just got a refi with no escrow sucking up money every month), I'm taking a sabbatical to do stuff like homebrewing. It's like getting my first summer vacation in over ten years.

 

But lately I've been taking time to look more into the Sega Genesis, including making a 68000 assembler, disassembler, and today I made a prototype cartridge board design and sent it out to pcbpool to get a first run. The temptation of "no bank switching" and "16-color tiles" is hard to resist. Also, Genesis and Colecovision are so similar in design that it's not too much trouble going either way. It may be easier to get the RPG going on Genesis first, then back-porting it to Colecovision.

 

Don't worry, I'm hacking as fast as I can. I'll get something finished one of these days. After all, I'm going to have to find something to do with those 100 Coleco cartridge shells I'm ordering, right?

[Uzumaki]

Genesis and Colecovision being similar is not a coincidence. Sega made the Genesis with Z-80 processor so the system could play 8 bit SMS games. It just happens that SMS and Colecovision is closely related on hardware level. It'd probably be easy to port CV games to SMS

[Bruce Tomlin]

Genesis and Colecovision being similar is not a coincidence.

Uh, I didn't say it was.

[Bruce Tomlin]

I've been spending the past couple of weeks starting to convert this thing over to Sega Genesis. I got tired of the lack of color and the lack of ROM space (20K out of 32K for just the demo is a lot), and even all the crap you have to do to make the vertical blank interrupt not screw up regular VDP access. Right now I've got it so you can move around in the first map. There's LOTS of stuff I still need to convert over, particularly the text/window routines and the script interpreter.

 

I guess the coolest part is that even with 4-bit graphics, it's still only marginally larger than the Colecovision version right now. Sure, it'll grow when I add the code it needs, and when I add back in the other maps (which will be twice as big for now) and the music, but this is a lot leaner than I was expecting it to be. I'm also not using any hardware scroll support.

 

rpg68_001.bin

Remember, that's a Sega Genesis binary, not Colecovision!

[+remowilliams]

Aww, that's sad for the CV. But I can understand.

[Bill Loguidice]

Aww, that's sad for the CV. But I can understand.

 

As long as the ColecoVision version still gets made at some point. After all, do we really need a single person-developed Sega Genesis RPG when that system is rife with quality commercial RPG's? I think a ColecoVision version would be much more impactful and significant, particularly since there are a dearth of such games on the platform, but that's just my opinion. In any case, good luck to the author.

[Bruce Tomlin]

It's just too big for the Colecovision. It's just too much work when there is no bank switching supported by emulators, so I'd have to do everything the hard way. Porting it back after completion could be possible, but it's just too big as it is.

 

This is basically a NES/SMS era game, but I had to go with Genesis because the NES hardware is a pain, and the SMS is as hard to find (in the US) as the Colecovision, and wouldn't give me any significant benefits. There was no other option.

 

Turn up your nose as you will about it not being on an 8-bit system, but a game is a game. Most people wouldn't be able to run it on a Colecovision, and if they're going to use an emulator anyhow, I might as well go for a 16-bit system. My time is at a premium, and I'm not going to waste it on working around the limitations of either the Colecovision or 7800.

 

Besides, that Blast Processing is so sweet.

 

After all, do we really need a single person-developed Sega Genesis RPG when that system is rife with quality commercial RPG's? I think a ColecoVision version would be much more impactful and significant, particularly since there are a dearth of such games on the platform, but that's just my opinion. In any case, good luck to the author.

Or you could have said "Why write a paper book when paper books are rife with quality stories? I think a stone-engraved version would be much more impactful and significant, particularly since there are a dearth of such stories on stone".

Edited December 27, 2006 by Bruce Tomlin

[haroldoop]

Well, what can I say... Welcome to the Genesis dev scene!

[Emehr]

I'm not sure if it can be appreciated just how involved it is to code an RPG, especially as a solo effort. I haven't tried the binaries (CV or Genny) but I've read the threads and all I can say is...keep up the good work! I've been coding a 2-D RPG for Classic MacOS for an embarrassingly long time now and I'm impressed to see how much progress you've made in the past year.

[Bruce Tomlin]

I've finally got everything working except sound. That will need a port of the Colecovision sound routines, which won't be too hard since the Genesis has the same sound chip inside it.

 

The last thing I did was changeable tiles, and I did that with the quickest hack possible, which is to check at every tile during display. This causes a noticeable slowdown in certain levels, depending on how many tiles there are like that. So I still need to rewrite the display routine to buffer the line and check at the end of the line like I did before.

 

rpg68_002.bin