Colecovision RPG

[DracIsBack]

Another problem is that it seems I'm always finding problems with emulators, like when I used 320B mode on a 7800.  With my new use of Mode 2 character cell graphics (as opposed to Mode 2 full bitmap mode), MESS won't display any colors, or at least it's reusing the black & white color table entries from the ASCII character code range.  For now, I'll have to use the Mugrat emulator for portable development.  The only problem I've found with Mugrat is that it doesn't do the right fire button.  But I plan to use the keypad and not the right fire button.  (This will be good news to people with Champ keypads, since they don't handle the right fire button either.)

990440[/snapback]

 

Uh oh -- you mentioned 7800 in the thread. That means you've committed yourself to do a 7800 RPG too!

 

Seriously though -- this game is neat looking. Keep up the good work!

Edited December 29, 2005 by DracIsBack

[Bruce Tomlin]

It took me about an hour this morning to get the bounds checking in place. So now the only thing missing from the previous release is a transition effect between levels. And the engrish too, now that there's no empty space for it to fill up.

 

If anyone wants to complain to the MESS folks about the color table being implemented incorrectly in this mode, feel free to send 'em this binary.

rpg_010.bin

[Bruce Tomlin]

* Tiles are now loaded per map (for a graphics test, press 2+3 simultaneously)

* Widened the two big maps now that I don't need padding around the edges. (I still need to expand the house map.)

* Chests can be opened and closed (tests flag-based sprites, flag routines, and fire button action on an object)

* Popup text windows have been implemented ('1' key brings up the engrish; doors from the two white houses give a "door is locked" message), but I don't have automatic word wrap.

 

I'm finding that the Colecovision is extremely easy for me to program. Having a Z-80 ICE helps some, but I've always liked Z-80 coding better than 6502. (and 6809/68000 better than either of those) By the time I stopped using my old TRS-80 (I went Mac in 1985), I could write Z-80 code almost like it was BASIC.

rpg_011.bin

[Bruce Tomlin]

I found the bug with MESS. When setting up the video mode, I was writing VDP register 3 after register 0. However, one of the TMS9928a.c driver variables that depended upon the value of register 3 was not being updated.

 

I've posted in the appropriate MESS and MAME forums (it's a MAME driver), and I've changed my code to set up register 3 first.

[Bruce Tomlin]

Hooray! I got half-tile scrolling to work! I did have to tweak the graphics on the mountains and water tiles to make them look better with half-tile scrolling, but I like my new mountains.

 

This version is again compatible with MESS, and the other main thing I added was a scripting test on the 0 key. This starts the wizard guy off in the square, and he goes into the house and gets "on" the bed.

rpg_013.bin

[+-^CrossBow^-]

Bruce:

 

Just wanted to say how really cool all of this looks!!

 

I am testing your Bin's using Virtual Colecovision (NT version) it is an old Emu, but it works just fine for your current WIP bins. The only trick to get them to work, is to simply rename the ext from .bin to .rom. Apparently Virtual Colecovision only sees files with the .rom extension.

 

And yes the new half tile scrolling looks awesome! I also like bumbing around in the dark in the cave when I go off trail...hehe...anything else that can be done besides walk around, try to open some locked doors, and see the cave and open chests with nothing inside?...hehe...This is looking really cool. And even a single player adventure game with this would be excellent. Hmm...wasteland.....

 

[Bruce Tomlin]

Basically, I'm still in the graphics engine development phase. But I agree that wandering around the empty cave area is kind of fun. And don't forget to try the keypad. I've got the 0, 1, and 2 keys hooked up. The "2" key is a flag/scripting test that shows which chests are open or closed.

 

And those doors aren't locked, there just isn't anything behind them:

Map0_3  _WIN    01A6H,3,21
        _TOGF   0
        _PSHF   0
        _IFZ    .10
        _MSG    "The door is locked."
        _JMP    .20

.10     _MSG    "Locked the door is."
.20     _WAND
        _MAP
        _EXIT

Also, I tried putting this on a cartridge and realized that I need to turn off the sound chip before doing anything else. Oops. On real hardware (or on mine, at least), the sound chip is making noise when the system is powered on.

Edited January 13, 2006 by Bruce Tomlin

[Bruce Tomlin]

After a lot of work, I finally got sprites working. They don't move on their own at this time, and I'm not sure I want to go to the extreme effort of getting them to do half-tile movement, but they do display. About the only negative is that the sprite overlay on them can leave ghost faces in message windows, but careful placement of the message box reduces this problem. The main thing is that at this point, my display engine has the minimum necessary stuff for an RPG.

 

Also, in version 014 I added a name entry routine. Just hit the 4 key to see this. LFire accepts a letter, * moves the cursor right, # and RFire backspaces, and 0 selects END.

 

As far as bloat goes, 013 to 014 added less than 1K, and 014 to 015 adds more than 2K, but 1.5K of that is the data for four NPC sprites.

 

And it just wouldn't be pushing the technology if I didn't find another emulator problem. MAME properly handles the display updates during map scrolling such that sprites and the tiles behind them move at the same time (which the real hardware does), but Mugrat (an OS X-only emulator) moves them at different times, so the faces don't move at the same time as the bodies. I even went to the extra effort of not moving the sprite until I was about to send the tile row it was on, and the faces were still disembodied on Mugrat.

 

EDIT: It seems the sprites vs menu windows problem is more important that I thought. So I fired up MSX Dragon Quest 2 again and noticed a couple of things. 1) when a menu pops up, sprites under it are taken off the map before drawing the window, and 2) when you sit around doing nothing for a few seconds and the status window pops up, sprites outside the window will not walk under it, and sprites that were caught under it do not move! So I guess I'll have to add something like that in next.

rpg_015.bin

Edited January 22, 2006 by Bruce Tomlin

[moycon]

Awesome reading how this great looking title is progressing.

It amazes me what some of you guys can create using old coding and inventing new techniques to realize your vision.

Awesome.

Edited January 24, 2006 by moycon

[Serguei2]

Hi Bruce

 

 

Great stuff. I tried your RPG ColecoVision demo and I like it.

 

 

Are you planning to add password or a battery back up in your game?

[Inky]

Sounds excellent so far...

 

If I knew how to do it, I'd help make a special ADAM version which supports save game files to data pack or floppy.

[Bruce Tomlin]

Are you planning to add password or a battery back up in your game?

I won't have any idea until I have anything that can be saved. Right now I'm still working on the graphics engine. I don't even have support for items yet.

 

If I can figure out how, I might even try to make the game sufficiently random that it can be played in two hours or so, which would not only remove the need to save anything, but would also give it higher replay value. But right now I really have no idea how to do that. Aside from Rogue-like games, I'm not aware of any totally random RPG games, so I don't have anything to use as a reference for gameplay. So this idea is kind of a long shot.

[Pixelboy]

If I can figure out how, I might even try to make the game sufficiently random that it can be played in two hours or so, which would not only remove the need to save anything, but would also give it higher replay value.  But right now I really have no idea how to do that.  Aside from Rogue-like games, I'm not aware of any totally random RPG games, so I don't have anything to use as a reference for gameplay.  So this idea is kind of a long shot.

1007930[/snapback]

Bah, you could just use a password system similar to Metroid on NES. You could store a lot of data with a long password, which could be entered easely with the keypad buttons on the standard CV controller.

[Bruce Tomlin]

I finally figured out why I was having trouble using my register dump routine to debug graphics kernel stuff was simply due to an "infinite mirrors" problem, and adding a flag fixed that. So while at an anime convention and away from my ICE (which is back at home on the other side of town), last night I was able to debug my new sprite code that hides sprites as windows pop up over them, using nothing more than strategically placed register dumps. Sprite hiding should also work when I pop up more than one window, but I haven't specifically tested for that.

 

I also started adding just a little bit more scripting for sprites to let them turn and move. While I haven't used the movement thing yet, I did get the turning working. So now when you "talk" to a sprite, it can turn to face you.

 

So now, at last, I can finally start thinking about content. Now I've got to come up with support for items and inventory.

rpg_016.bin

[Bruce Tomlin]

I've got items and money basically working now. The 5 key calls up the inventory screen. The right fire button or the '0' key cancels. I also moved the scripting demo from the '0' key to the '8' key because I was getting tired of running it by accident, now that I'm getting used to '0' as a general cancel key. (the right fire button doesn't work in the emulator I normally use)

 

I was surprised to find that I didn't have support for "clicking" on an object. The chests were just hard-coded to toggle the flag and update the display. Now they've got scripting, and are scripted to only open once. Repeated opening and closing works, but I don't want to have to use another flag to keep track of whether they are empty or not.

 

The next thing to add will be merchants so you can buy stuff.

rpg_017.bin

[vdub_bobby]

I've been following this thread, but I haven't actually played any of the ROMs yet.

 

But I just did, and it looks fantastic! Great job, Bruce. Can't wait to see where this goes.

 

EDIT: Er, who is Robert anyway? Sorry, fixed it. Don't know what I was thinking.

Edited February 6, 2006 by vdub_bobby

[Bruce Tomlin]

Who is Robert?

 

One thing I forgot to mention... I have now broken the 16K barrier. It would be really cool if I could get this thing to fit in 32K (crossing fingers), because bank switching will make it a pain to develop until I get emulator support for whatever bank switching I use. But the part that needs to be in the primary bank (8000H) should definitely fit in 16K.

[Bruce Tomlin]

I hacked in some sort of buying and selling code. The selling code will have to be separated out later, but right now it's hooked up to the inventory (key 5). The buying code is hooked up to key 6.

 

Now I need to come up with an actual merchant, which means a lot of data work, then I can hook up buying and selling to its scripting.

rpg_018.bin

[Bruce Tomlin]

I haven't had any good chance to work on this for over a month now. But I got my 127-in-1 last week, and I managed to load it with everything that I didn't already have on cartridge, and tried out some interesting stuff.

 

I came across the "Adam's Musicbox Demo", which was 24K of ColecoVision format songs and some simple code to play them. A few of the songs had a nice sound to them. I was inspired to fully disassemble this thing and understand how it worked. Thanks to the "ColecoVision coding guide" document, I had a lot of info to help me understand the sound routines and the sound data format. (by the way, there is an error: plain noise notes start with $00, not $02)

 

So I've been taking some time over the past few days to disassemble it, and to get the sound using macros instead of a bunch of faceless DB statements. The good news was that three of the four songs I was interested in weren't very big. Actually grafting the code into my RPG was the easiest part (with a slight setback when MESS decided it didn't want to play sound until I quit and re-ran it). I decided to add a script procedure to be executed when entering a zone, and have that run an instruction to start background music.

 

(So where did that "musicbox demo" come from, anyhow? The only clue is that it has the number "1987" in it. Since Coleco was basically already dead by then, I doubt they would have been making something like that in 1987.)

rpg_019.bin

[+thegoldenband]

Very nice! Even though I never owned a Colecovision as a kid (strictly Atari 2600/5200 for consoles at my house), I've really been enjoying following your progress with this project.

 

Out of curiosity: I know the CV uses the Texas Instruments SN76489A -- same chip as the SMS, Game Gear, et al. -- and that it has 3 square wave channels + 1 noise channel. Can it reproduce pretty much the full gamut of tempered pitches (i.e. all the notes on the piano, in tune)?

 

I ask because I know that on the Atari 2600 (for example), its sound hardware is so idiosyncratic that it would be very difficult for a composer and programmer to collaborate on game music. But listening to the tunes you took from the "musicbox demo", and looking at the CV's tech specs, I found myself thinking, "Hey, I could write music for this system!" -- and that my MIDI files (or whatever I might send) could be comfortably rendered, so long as I kept strictly to no more than 3 voices + "percussion" (i.e. noise channel clicks and rumbles) at any one time...

 

Or are there technical hurdles I'm overlooking?

Edited March 16, 2006 by thegoldenband

[Bruce Tomlin]

Not only does it have a five octave range that corresponds roughly to scale, the ROM has routines which support decay and pitch changes. It goes from A110 to A3520, but after five octaves it doesn't have enough precision to stay on scale.

 

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 I did was copy existing music just to get things working. Writing a new tune from scratch will depend on understanding the wierdnesses of the sound routines, plus having a good ROM disassembly handy. In my disassembly of musicbox demo, notice how some sounds just add in three or four lists and are done with it, but others muck around with the first byte of the channel tables, maybe to chain two lists together.

 

In the musicbox demo, you may notice how the NMI checks some flags; this is to avoid VDP problems. You have to read the VDP status to acknowledge the NMI so that you can get another NMI, but if you read it while a VDP address is being loaded, things will go on the screen at the wrong place. (I've seen this happen with the Bejeweled demo.) It also defers the sound update, but never calls the AddSound routine with the NMI protection. I put the sound update directly into my NMI, but now I have to wonder how good an idea that was.

 

Also, you can download a copy of my Z-80 assembler from this page: http://xi6.com/hacks/ Here are the commands which will assemble a file:

 

asmz80 -l -o -w -e $file
makerom <$file.hex >$file.bin

FWIW, I started work a long time ago on an optimized BIOS ROM, and was able to save over 1K (out of 8K!), and still remain compatible with most stuff. While looking into the sound routines the other day, I actually found six or seven more bytes to save, and possibly another couple more. It's absurd how loose that code was.

adammbox_2006_03_14.zip

Edited March 16, 2006 by Bruce Tomlin

[vdub_bobby]

Out of curiosity, how big of a map can you have at once?

[Bruce Tomlin]

The only limitation I have is that the width has to be a power of two so that I can do a looped shift instead of a multiply. And of course it has to fit in ROM, at two bytes per tile. If I go bankswitched, that will mean it has to fit in a 16K bank along with the other data for that level.

[vdub_bobby]

The only limitation I have is that the width has to be a power of two so that I can do a looped shift instead of a multiply. And of course it has to fit in ROM, at two bytes per tile. If I go bankswitched, that will mean it has to fit in a 16K bank along with the other data for that level.

So...rough calculation: that means 64x64 is the biggest (square) map? Does the "height" also have to be a power of two? Does it have to be square?

 

Just curious.

[Bruce Tomlin]

Haa haa! I found a bu-ug!

 

Wanna see a ColecoVision go nuts? (It's even more fun when it's an emulated ColecoVision going nuts.) Just "click" on any fixed object in the main map like a building or a fence or the water. I botched a comparison (off by one) and it tries to execute a script using a bogus address. I first noticed it last night when I was playing around with getting a Coleco emulator working on a chipped xbox, and when I accidentally pressed the fire button while standing in front of the table, the wizard left the house! The real fun is in the main map, though. It often hits the "oops" check in the script interpreter, but sometimes it leaves trash on the screen, and sometimes it even crashes and reboots. The cave doesn't have this problem, though.

 

Does it have to be square?

If you check, I believe you will find that the main map is already not square.

 

Since not having anything in the 32 to 64 range of width is a rather undesirable limitation, I just now looked into whether doing a multiply would be a bad thing. I was concerned early in development that it could be a performance problem if I had to do a multiply all the time, but the code to find the address of a tile is only called in three places, two of them in response to user actions, and third one inside the display engine. The display engine only calls it once, with a simple add to go to the next line. So I'm going to remove the width limitation.