Robin Gravel's Blog

That's just the coleco.h library. FIRE3 and FIRE4 is available for getput.h on page 27. I personally use both getput.h and coleco.h.

 

Keep in mind, colecovision hand controller don't have fire3 or fire4 button. That only on the Super Action Controller.

Ok. Not all Colecovision owners have a Super Action Controller either.

 

For complexe gameplay, I use the keypad instead.

To answer some of your questions. Two reason I split source code if the source code is taking very long time to compile, I move the offending code to another source code, like enemy behavior for Challenger, so I can focus programming the main source code, which takes a minute. I only compile the enemy behavior code if I need to make a change. Another reason is bankswitching. I have 8 source codes in the folder to build a 128KB game. Each bank is 16KB.

And for need to have more sprites. You can redefine the sprite pattern on demand at a cost of cycles. I experimented having 2 bank of sprites loaded to VRAM. All I had to do is to bankswitch to another VRAM bank for the sprites.

For example: http://atariage.com/forums/topic/286613-new-years-beach-party-garbage-pick-up/

Beach Clean Up switch vram bank to 0x3000 when he picks up an item, then switch bank to 0x3800 when he drop an item. So it can take up 16 slots instead of 32 slot, so I can add additional sprite graphics. The sprite graphic other than the player are duplicated. It's like how NES CHR-ROM worked. In screen_mode_2_text(); There's only 1 color table, which is at 0x2000. So address 0x2800, and 0x3000 are not used by the VDP. So you can stash your data or addition graphic there.

To answer some of your questions. Two reason I split source code if the source code is taking very long time to compile, I move the offending code to another source code, like enemy behavior for Challenger, so I can focus programming the main source code, which takes a minute. I only compile the enemy behavior code if I need to make a change. Another reason is bankswitching. I have 8 source codes in the folder to build a 128KB game. Each bank is 16KB.

 

And for need to have more sprites. You can redefine the sprite pattern on demand at a cost of cycles. I experimented having 2 bank of sprites loaded to VRAM. All I had to do is to bankswitch to another VRAM bank for the sprites.

 

For example: http://atariage.com/forums/topic/286613-new-years-beach-party-garbage-pick-up/

 

Beach Clean Up switch vram bank to 0x3000 when he picks up an item, then switch bank to 0x3800 when he drop an item. So it can take up 16 slots instead of 32 slot, so I can add additional sprite graphics. The sprite graphic other than the player are duplicated. It's like how NES CHR-ROM worked. In screen_mode_2_text(); There's only 1 color table, which is at 0x2000. So address 0x2800, and 0x3000 are not used by the VDP. So you can stash your data or addition graphic there.

 

Thanks for the tips and for your patience. It's very helpful.

 

The offending and the enemy and the challenger thing is hard to me to understand. But if splitting files makes the compiler faster, I understand that.

 

Splitting files to make games bigger than 16k is fine too, even if Colecovision can handle games to 32k without bankswitching, I think.

 

Maybe it's time for me to re-read Colecovision programing manual if I missed something.

 

If I need help, I'll drop a line in the forum.

 

After I worked on my game so far, I'm on the right track.