Pang for Colecovision

[Pang for Colecovision]

Nice, I love Pang. Played and beat every version of it ever!

[CV development on a mac]

If you hit Alt + Enter (at least on PC, I think it's the same on Mac) it'll stay windowed but use the entire window for the game screen, and from there you can hit ESC to toggle between full-screen and windowed like evg2000 said. The Mac version only runs well in full-screen mode (either full-screen windowed within Meka or actual full-screen) though, for some reason it doesn't update correctly all the time when in windowed (within Meka windowed mode I mean). I think Brock is working on it for the next update, but it's a minor problem unless you're using the debugger (and even then it's only just slightly annoying sometimes). It runs perfectly when full-screen so it's fine for playing games, but if you're just gonna play Coleco games I'd use MugRat instead since it seems to be flawless as far as I can tell.

 

The debugger in Meka will make your life infinitely easier though, it's amazing.

[CV development on a mac]

objcopy.zip

 

Oh yeah, I almost forgot, you need objcopy in the same folder as your source files or the makefile won't work. I'll attach that to this post.

[CV development on a mac]

Use Xcode (best developer environment of all time) with SDCC installed, http://sdcc.sourceforge.net/

 

Also, download Daniel Bienvenu's windows C package from this forum, his library files are invaluable even if you don't use them directly and just reference them on how to get a game up and running in C. I couldn't have gotten started without his amazingly helpful work.

 

Finally, use a makefile like this in Xcode (probably not the most elegant makefile, but it works for me just fine) and you can build just like any other Xcode project-

 

 

 

 

#########################################################################################

# Place pre-compiled .rel (object) files into the <object> folder so that they are #

# not removed when calling clean. #

# Place library files in the <lib> folder. #

# FUNCTIONS: build, all, copy, cleanup, clean #

#########################################################################################

 

# COMPILER VARIABLES #

CC = "/Developer/sdcc/bin/sdcc"

CCASM = "/Developer/sdcc/bin/sdasz80"

 

# FLAGS FOR COMPILING, LINKING, AND ASSEMBLY COMPILING #

#FLAGSC = -mz80 -c -V --std-c99 --all-callee-saves

FLAGSC = -mz80 -c -V --std-sdcc89 --main-return

FLAGSL = -mz80 --code-loc 0x8021 --data-loc 0x7000 --no-std-crt0

FLAGSA = -o

 

# LIST .S ASSEMBLY FILES HERE #

OBJLIB1 = crt0.rel decompress.rel

OBJLIB2 = spritesASM.rel soundASM.rel collisionASM.rel pointers.rel enemyAI.rel collisionHandler.rel menu.rel

 

# LIST .C SOURCE FILES HERE #

OBJ1 = main.rel input.rel graphic_data.rel sound_data.rel

OBJ2 = collision.rel sprites.rel

OBJS1 = screen00.rel

OBJS2 = screen09.rel

 

# BUILDS THE ROM, THEN CLEANS UP ALL FILES PRODUCED #

build : clean all copy cleanup

 

# THE TARGET IS RESULT.IHX, WHICH IS THEN COPIED INTO A BINARY #

all : result.ihx

 

# BUILD INSTRUCTIONS FOR COMPILING THE ROM #

result.ihx : $(OBJLIB1) $(OBJLIB2) $(OBJ1) $(OBJ2) $(OBJS1) $(OBJS2)

$(CC) $(FLAGSL) $(OBJLIB1) $(OBJLIB2) $(OBJ1) $(OBJ2) $(OBJS1) $(OBJS2) -o result.ihx

 

# SCANS FOR ALL .C SOURCE FILES USING $< OPERATOR #

%.rel : %.c

$(CC) $(FLAGSC) $<

 

# RULE TO BUILD .S ASSEMBLY FILES

%.rel : %.s

$(CCASM) $(FLAGSA) $<

 

# CONVERTS INTEL HEX FORMAT TO BINARY USING OBJCOPY AND DUMPS TO RESULT.ROM #

copy : result.ihx

objcopy --input-target=ihex --output-target=binary result.ihx result.rom

 

# CLEANS UP ALL FILES EXCEPT FOR RESULT.IHX #

.PHONY : cleanup

cleanup :

-rm -f *.rel *.lst *.sym *.lnk *.map *.noi *.asm *.ihx

 

# REMOVES RESULT.IHX #

.PHONY : removeihx

removeihx :

-rm -f *.ihx

 

# CLEANS UP EVERY SINGLE FILE IN FOLDER EXCEPT SOURCE FILES #

.PHONY : clean

clean :

-rm -f *.rel *.lst *.sym *.lnk *.map *.noi *.ihx *.asm *.rom

 

 

 

To debug I took the Mac Meka port and made an .app out of it so you don't have to install allegro- http://www.smspower.org/forums/viewtopic.php?t=13308 it's around the middle of the posts, the file you want is MekaOSX.dmg (2.38 MB).

 

Meka has the best debugger I've ever seen, it'll seriously make your life 100 times easier. You can watch RAM, VRAM, and registers all in real time.

[can we have a list of the coleco developers?]

As a programmer I can say unless you're paying a decent amount of money no one is going to be interested. Ideas are basically worthless since the person doing the bulk of the work (i.e., the programmer) generally already has a billion ideas for games that they can draw from, so unless you're paying them it's just never going to be worth their time. Really the only way is to learn to program and just do your idea yourself, unfortunately.

[Is the Colecovision more powerful than the Atari 5200?]

unless one vastly outstrips the other in all regards (i.e. Coleco VS Atari 2600).

 

How does the Colecovision display 128 colors?

 

Uh, dithering? Hah.

[Is the Colecovision more powerful than the Atari 5200?]

You can easily say that "on paper" one system should be more powerful than the other, for example the PC Engine versus the SNES; PC Engine on paper looks basically like a really beefy NES, but if you look at the library there are games that match the best SNES and Genesis visuals of the era. So technically the SNES would be a "more powerful" system, but it had a shit-slow, half-retarded CPU that held it back.

 

In reality there's just too many factors involved to give a definitive answer unless one vastly outstrips the other in all regards (i.e. Coleco VS Atari 2600).

[How Popular are CV Homebrews?]

Maybe it is none of my business..but I was curious as to how many each CV homebrew sells? Ten's? Hundred's? Thousands?

 

For the 5 games I released so far, sales were in the 58 to 92 range.

 

Philipp

 

I was curious if any of the publishers have tried using ebay to increase sales? It always seems like you see games start cropping up on ebay relatively shortly after they come out (Pier Solar for example) and sell for way more than the original price. It seems like it might be worthwhile to print up an extra batch of copies and open an Ebay store to sell them through, but I could be wrong (obviously small publishers have probably tried this already). Probably for the amount of profit they make it just isn't worth the time to deal with ebay fees, retarded ebay users, selling one at a time, etc.

[Team Pixelboy News Bulletin - January 1st 2011]

Black Onyx was relatively easy, because it kept VDP access to a few subroutines that did their thing and got the hell out of there. Also, it helped that IY always pointed to a flags byte, so I could use IY-1 for its more efficient addressing mode with BIT/SET/RES instructions.

 

Girl's Garden was much worse because it had DI/EI instructions scattered all over the place, enabled and disabled the VDP interrupt in many places, and would poke addresses and data bytes to the VDP as the code went along. And it even used the HALT instruction to wait for an interrupt. I had to use macros to map RST instructions to EI and HALT just because I ran out of ROM space if they were changed to CALL instructions. (Oddly, DI ended up mapped to an empty macro.)

 

I was constantly worried that I wouldn't be able to make it work. I just kept tweaking things until it stopped flaking out, then played it a lot with my fingers crossed.

 

Hah yeah, that's how Pitfall 2 was. Stupid VDP writes all over the place with DI/EI scattered everywhere. Plus the game used about 99.9% of the rom space so there was very little to work with. Fortunately I was able to use an MSX compression scheme I found to compress most of the graphics and free up a lot of space along with axing all the stupid keyboard input code. Thank God too because I needed every available byte to get things working, I think I had like 10 free bytes when it was finished, haha.

[Team Pixelboy News Bulletin - January 1st 2011]

bug is due to the NMI on the Coleco

 

Thanks again, Coleco, for that brilliant bit of engineering.

 

Haha! I owe you a big thanks; I studied how you dealt with the NMI in your source code for Black Onyx, without that knowledge I probably would never have forged ahead with the conversion out of sheer frustration at how stupid that feature is.

[Team Pixelboy News Bulletin - January 1st 2011]

No, the Pitfall II bug is due to the NMI on the Coleco. It wouldn't happen on the SG-1000 because you can mask the interrupt. I couldn't fix it without breaking other things unfortunately.

[what innovations has nintendo really brought the industry?]

Silpheed on Sega CD uses polygons for enemies, you can enable the debug menu and rotate the enemies on their axes.

[Controller input issue driving me crazy]

Why won't the Coleco recognize button 2 when you're pressing diagonal up/left? I've tried using both my own input routine and the Coleco bios routine and neither will poll button 2 when UP and LEFT are held. I've even watched a few commercial game's RAM addresses where they hold the button press and it won't work either which leads me to believe this is some issue with the Coleco.

[My projects]

I'm working on a sample written in assembly codes that I think will somehow answers this question. I will post a message in a few hours with the results.

 

Awesome, I've been curious about that for a while since the limit is so severe.

 

 

The background art for that new game looks great, especially considering that you're not using a bitmap screen mode.

 

Thanks! I take a lot of time doing the art to make sure it fits in the 256 tiles. I use the extra VRAM space to decompress nearly everything to so the trade-off is well worth it.

[My projects]

Concerning the AI , you could define some patterns path for your enemies and according to the position of the player you make follow the pattern path to your enemies in one way or other.

 

Concerning the 5th sprite, i never check the flag. Just depending how my sprites can move , i change before each redraw the order of some sprites (not all).

 

Ah that might work, each map could just have a bitmap for paths sprites can take.

 

On the sprites, I'm retarded, I just remembered the bit flag gives you the number of the fifth sprite, hah. How many sprites can you get on a line before the flickering becomes too much? I haven't experimented yet, but it seems like you could have at least 6 without it being too bad, but then I haven't tried it yet so I'm probably wrong.

[My projects]

Couple questions for the programmers out there- How do you guys generally handle AI routines for enemies? I'm thinking of setting up simple X1 and X2 boundaries for each enemy and then just having them run back and forth until the player is on the same X, at which point they attempt to attack the player. I'd really like to implement some rudimentary pathfinding though so they can move around and chase the player, but I can't think of any simple way to do it that doesn't require a ton of code.

 

Also, the 5th sprite thing, do you guys just check every NMI for the 5th sprite flag and then figure out which sprites are on the same X by comparing all the X coordinates of sprites on screen, or is there a faster way where you don't have to do comparisons for them all? I don't like using the Coleco bios routines because they take way too long and they always destroy all your registers.

[My projects]

God of war on Colecovision!!!

 

I looking foward for that one. It looks very promising!

 

So PitFall 2 arrives soon?

 

Haha, thanks. Yeah I'm excited about Pitfall 2, I put a lot of work into it although I think it would have been easier and less time consuming to just code the game from scratch, hah. I'm very proud of the results though and very thankful Luc gave me the opportunity and motivation to do the game.

[My projects]

Well since I just finished up (finger crossed for no further bugs) Pitfall 2 for Pixelboy I figured I would make a topic for my two projects since I can devote all my spare time to them now. The first is the raycaster game I've been working on (titled Gestalt), I haven't updated the video yet so I won't bother linking to the old one. The second is a side-scrolling action/adventure game titled Radiant: I Will Murder Your God which I put a very early video up of the first screen just to show some basic interaction-

 

http://www.youtube.com/watch?v=5x51y_83pjI

 

Anyway the programming isn't time-consuming, but designing is taking much longer than I anticipated. I hope to have one of them out by the end of the year with the other shortly following. I'll post up new vids as I hit milestones for anyone who is interested.

[MSX to Coleco]

Have any of you guys done a port from MSX to Coleco yet? Assuming the game only uses 1k RAM (or can be modified to only use 1k), what are the hurdles? I was looking at the MSX and it appears to have a ton of built in bios routines like the Coleco, so I assume getting around those is the first major problem. Any specific advice for someone who is dabbling in it?

[Any progress you can show?]

Awesome, thanks for the tip, that should make a big difference. I hadn't even thought about that, but after researching how some other people did raycasters on old systems I saw double buffering come up alot. Right now though I'm using VRAM for decompression of the maps so I'll have to move some stuff around, but that should work great.

 

Starting another thread is not a bad idea, I have a few questions that you guys could help me with since obviously you all know the VDP WAY better than I do.

[Any progress you can show?]

 

Do you mind sharing how the writes to the VDP are done ? Could imagine there are a few ways for speeding things up, which most likely

you already know. Here is some of the stuff I used to do for the TI when dealing with the VDP.

 

Should in some extent also work for the colecovision I guess:

* Guess the game screen is in graphics1 mode, so you should be able to have multiple pattern and screen image tables in the 16K VDP ram.

 

1. Fill inactive pattern/screen image table while the VDP registers point to the active pattern/screen image table

2. Switch VDP registers to now point to the filled tables, updating the screen display

3. And back to 1

 

Anyway, looking forward seeing more of your project

 

It's entirely in assembly:-) I'm curious about what you mean by switching pattern tables, is that what double buffering is? I hadn't thought of that-- that would remove the annoying wave as the screen updates. I have a section of VRAM dedicated to the viewing window, so basically the way it's working is it clears 64 bytes of RAM for an 8 tile column (it was 11 tiles, but this way I only have to write color to one color table instead of 2 which means I can actually add color back in), then scales one slice of the texture to the lower nibbles of each tile, then on the next angle pass it scales to the upper nibbles and then ORs each nibble with the other. Every two passes it writes the full tile column to VRAM. I'd love to be able to hold the entire screen in RAM then just do one huge update, but the Coleco only has 1k so that's out, I can fit at most 2 tile columns at once in RAM without sacrificing other areas of the game.

[Any progress you can show?]

 

Some questions:

 

-Why does it switch to a third-person view in the cave?

 

-How does that health system for each part of the body work? Will having certain sections of the body critically injured cause side effects? (Example: Having your arm severely wounded causes your dexterity and other such stats to be temporarily affected, while severe head wounds could cause death, etc.)

 

Thank you for the kind words. It switches to third-person just so I can test that engine, normally that would be reserved for special rooms and things like that. Since the viewing window is so small I decided some overhead parts would be a good way to break things up and allow for different puzzles. The health for body parts will affect things exactly like you say, severe head wounds will cause death, but other injuries will affect other things (like walking speed, attack strength, etc).

[Any progress you can show?]

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

 

http://www.youtube.com/watch?v=KxO5yePdH4E

[Causes of VRAM Corruption ?]

I just use a bit flag that's always at $7000 for any routines that write to VRAM so you can test BIT X, (IY+$00) without having to load anything. The NMI does an EX AF, AF' to preserve flags then checks the flag, if it's set it jumps to the end. After the VRAM write you remove the flag and do a IN A, (BF) to acknowledge the interrupt. That cleared up all my VRAM corruption problems. I used a MSX decompression routine and had to use this method or half the time it would decompress garbage data since it would get interrupted in the middle of writes by the NMI.

[Any progress you can show?]

Oh cool, thanks! I'll upload a new video once I get some bugs ironed out. I have to finish Pitfall 2 first, but after that I'll have plenty of time. The next will show the overhead view mode and the battle system.

 

Also, thanks for all the music you post on here, I modified one of yours for the opening song because I couldn't figure out how to do drums. I changed all the melodies and bass, but the beat is the same.