83 replies to this topic

[haroldoop]

Very impressive!
About the sound: You could use MVSTracker to create background music. It's available at http://www.pascalora...?news=30&cat=22

[Bruce Tomlin]

After a small detour to tighten up my 68K assembler, make it possible to assemble Z80 and 68K code in the same source file, make a serial interface board, and get Macsbug up and running, I finally got around to rewriting the screen display routine to work like the Coleco version. Now it only checks for changeable tiles at the end of each row of tiles, which avoids lag when there are a lot of changeable tiles on the map, especially inside the castle. This reduced the number of changeable tile checks from 560 to 14.

I also noticed that I forgot to put in the item use/drop code. So now except for sound, it has finally reached feature parity with the Coleco version, plus a few improvements like a bigger screen, full-color sprites, and fixing the tiles that had color limitations on the Coleco.

At this point, I'll probably get the music working, then switch over to porting Tubes from the 7800 version, since I can probably get it finished much sooner. As Steve Jobs says, "real artists ship".

 rpg68_003.bin   31.89K   115 downloads

[Bruce Tomlin]

Yeah, it's been a while, but I've been spending the past few weeks trying to get a cartridge board with EEPROM save working. This included fixing bugs in my GAL assembler program, which let an error in my logic descrption screw up the resulting chip.

But now I've gotten it to the point where I have a nice little save/load library which can be switched between the three types of I2C chips (7-bit, 1-byte, 2-byte addressing), and battery RAM. This lets me use battery RAM in an emulator, and my EEPROM (chip selected with the /TIME line) in a real cartridge, with auto-detect. I even made a new build system with a real makefile instead of a cheap shell script.

Since I normally use a version of MESS to run my code, and MESS still doesn't support battery/EEPROM backup on the Genesis, I have things set up so that I can fake out battery RAM by using the start of console RAM instead.

Today I got save and load working nicely. It has three saves in a 256-byte 24C02, 80 bytes each with 4 bytes spare per save, and maybe another 4 bytes more if I tweak things. I should also be able to put a high score table into Tubes using either a 128 or 256 byte chip. And my board takes SSOP and TSOP chips, so I can even scavenge the chips from old DIMMs if I want to.

But I would like to get the Coleco music code finally translated over before I release a new version. I'll probably just translate the Z80 to 68K, rather than trying to run it on the Genny's Z80. Since I'll only be using the PSG, there won't be much need for the other CPU. (If I was doing PCM, then I would absolutely need the Z80.)

[Heaven/TQA]

hahaha... "real artists ship"... so i am not an artist...

[Bruce Tomlin]

This morning I sat down and was going to debug until I got that sound code working right. After much Macsbug-fu, I got the sound working right, then the game crashed when a text window scrolled. Half an hour later, I realized that I had mis-placed a buffer and it was overwriting the sound variables.

So anyhow, here it is. This version should save games with any emulator that supports standard battery RAM, though it is specifically designed to save to a 24C02 EEPROM on the cartridge board that I have been working on.

 rpg68_004.bin.zip   14.49K   74 downloads
Now that I have achieved parity with the ColecoVision version, I can finally start moving this thing forward.

[Bruce Tomlin]

I haven't worked on it for a couple of weeks now, so I'm uploading version 5.

I added a cool "dark cave" effect and equipping items.

 rpg68_005.bin.zip   15.26K   108 downloads

Edited by Bruce Tomlin, Thu Jul 12, 2007 6:30 AM.

[Arjak]

Sorry to necro-post, but have you considered working on this again? I think it's an outstanding idea and I would hate to see it die like this...

[Bruce Tomlin]

The current state is that I gave up on 68000 assembler as too unmaintainable, and I am partway through converting it to C. About three months ago I ported over most of the code that hadn't already been ported to C. The main thing right now is that I need something to replace the ad-hoc programming language that used assembler macros. The other things I still haven't ported over are sound, game save memory, and text compression. And of course, once I finish porting stuff, I still need to finish the game engine (minor things like combat, etc.)

In the end, most of the game data will be in one or more text files that get converted to a .C file so that it will be much easier to work on it without having to tinker with the game engine code. Also, the data compiler will do the text compression for me. (I had added it as a feature in my assembler, which made it a lot easier to use and made the Sega port easier, but I'm not going to hack gcc for it.)

And for those who are thinking the question, the chance of this ever making it to the Colecovision is pretty low. It's not zero, since a lot of the engine code has already been written, and I'm not really using any Sega-specific stuff like scrolling support. (I'm still sending a complete name table to scroll the screen, and I still need delay frames to keep it from going too fast.) But it would require me to squeeze it into a cartridge whose slot never saw bank switching back in the day, and the only reason to do it is "because it's there". There are very good reasons why I picked the Sega Genesis as my homebrew platform of choice, and linear addressing is one of them.

[Pixelboy]

Bruce Tomlin, on Tue Dec 15, 2009 8:50 AM, said:

And for those who are thinking the question, the chance of this ever making it to the Colecovision is pretty low. It's not zero, since a lot of the engine code has already been written, and I'm not really using any Sega-specific stuff like scrolling support. (I'm still sending a complete name table to scroll the screen, and I still need delay frames to keep it from going too fast.) But it would require me to squeeze it into a cartridge whose slot never saw bank switching back in the day, and the only reason to do it is "because it's there". There are very good reasons why I picked the Sega Genesis as my homebrew platform of choice, and linear addressing is one of them.

As you know, I'm currently overseing the development of a ColecoVision cart PCB with 64K support and also savegame support. But considering the CV has only 1K of RAM, and that your RPG may get pretty large if done on the Genesis, I have to wonder if 64K would be enough to fit your development needs to begin with, if you were to do a CV port...