Jump to content
IGNORED

What language are Colecovision games written in?


Rudy

Recommended Posts

I assume its C or C++ but I really have no idea; I would like to know so I know what I have to learn in order to write games. I'm just getting started writing Atari 2600 games and since I assume I'll have to learn another language to do Colecovision games, it would help if you could give me some direction.

Link to comment
Share on other sites

Although C and other compilers do exist for CV it produces rather slow and bloated code. Originally all CV games were written in Z80 assembler, which is harder to code from scratch but over time you build up libraries of common routines and functions which with macros can result in reasonably fast coding.

C will let you produce your code quicker, but CV is a fraction of the speed of the lowest level PC, so you should use the fastest most compact coding system possible, which is assembler.

  • Like 2
Link to comment
Share on other sites

Although C and other compilers do exist for CV it produces rather slow and bloated code. Originally all CV games were written in Z80 assembler, which is harder to code from scratch but over time you build up libraries of common routines and functions which with macros can result in reasonably fast coding.

C will let you produce your code quicker, but CV is a fraction of the speed of the lowest level PC, so you should use the fastest most compact coding system possible, which is assembler.

 

 

I guess C waste more memory than Assembler, and might be harder to control the stack?

Link to comment
Share on other sites

 

I guess C waste more memory than Assembler, and might be harder to control the stack?

It does waste a lot of memory, but if the project does not need speed or memory its just far simpler and faster to express coding concepts in C.

The stack isn't such a mystery, but yes you do need to take control of it as with all things in assembler, the coder rather than the compiler is in charge, with great power...etc..

Edited by BrianBeuken
Link to comment
Share on other sites

It does waste a lot of memory, but if the project does not need speed or memory its just far simpler and faster to express coding concepts in C.

The stack isn't such a mystery, but yes you do need to take control of it as with all things in assembler, the coder rather than the compiler is in charge, with great power...etc..

The compiler assign your variable for you. In crtcv.map, it'll show you where your variable is on RAM. You have about 800 bytes that goes towards your project. The other memory is used for bios operation and libraries.

Link to comment
Share on other sites

I've done some projects in C and some projects in Z80 assembler. And occasionally some with both. There is also Borel Basic in another thread. It is something that could be useful to make games, but no-one has made a complete game with it so far.

 

I find that assembler takes longer to write (although assembler is easy enough to debug in BlueMSX if you import your symbol table), even though I've built up some good libraries. So to optimize programmer time, it seems that C is the fastest. If your game gets slow (which is so easy to do on the CV), you can recode the game in assembler, or just rewrite the slow sections in assembler, and it'll be 5 to 10 times faster perhaps. But then again, choosing a faster algorithms can make it hundreds of times faster. So usually there is a way in C if you're careful and learn all of the tricks.

Link to comment
Share on other sites

It is in general lot of faster and readable to code in C. the only real drawback is the debugging. It is lot of more confortable to debug YOUR assembler code with Blue MSX then the compiler generaded assembler code!.

 

however , a friend has built a build environment in C that generates symbol table for C. So when you load the symbol in BlueMSX, just above the assembly code, you see the corresponding C source , it helps a lot.

 

Personnaly my game are mainly done in C. Ghost'n Zombie, Exploding Foot are 100% in C. Smurf , Gamester81 and Battle of Hoth has some short assembly routines but are mainly done in C .

 

I would like to do my game 100% in ASM , but i have to admit i always have problem with the Z80 , my brain is 6502 oriented... and i have no time to really invest in mastering Z80.

Link to comment
Share on other sites

  • 2 weeks later...

 

Thanks for the response! How far have you gotten with the generic ZX Basic and colecovision? haroldoop had to heavily modify and integrate specific assembly compilers and libraries to get a Sega Master System variant going. I'm surprised that it works so well out of the box in this case.

Link to comment
Share on other sites

So one thing I was thinking of mentioning was that Donkey Kong is the only game that uses the OS7 Pascal entry points, which suggests that DK was actually written in Pascal. I don't know of any other game that uses those entry points though.

Link to comment
Share on other sites

So one thing I was thinking of mentioning was that Donkey Kong is the only game that uses the OS7 Pascal entry points, which suggests that DK was actually written in Pascal. I don't know of any other game that uses those entry points though.

 

Hopefully the stars align and someone with Coleco experience adapts this:

http://sourceforge.net/projects/z80-pascal/

  • Like 1
Link to comment
Share on other sites

It doesn't look usable, and hasn't really changed in the last two years.

 

 

Hopefully the stars align and someone with Coleco experience adapts this:

http://sourceforge.net/projects/z80-pascal/

 

 

Modem Chess and Modem Tank by Chris Brayman were both written in Turbo Pascal. Run on CP/M with a library for ColecoVision programming. So check out Turbo Pascal.

Edited by hardhat
Link to comment
Share on other sites

Doesn't the choice of programming language much depend on the efficiency of available compilers? I don't know if the selection of C compilers for Z80 systems has improved greatly in the last few years, and thus made it a more viable option. With the limited system resources most earlier consoles had, the tools to generate executable code need to be aware and optimized for that, i.e. not wasting a lot of RAM when you only have a total of 2K (?) available including system memory.

 

Are there any good Forth compilers for Z80, possibly with support for ColecoVision? I suppose that would generally be a good candidate vs pure assembly code, although I admit Forth is not a language for everyone - I never quite wrapped my head around it despite I really wanted to. I know that the Swedish company Datatronic were fans of Forth, and developed several programs and games for the VIC/C64 in that programming lanuage. Once compiled, the machine code almost gets impossible to follow with calls to the runtime all the time. If a Z80 compiler would emit the same properties, it'd make your ColecoVision homebrew almost impossible for others to hack the binary. :-)

Link to comment
Share on other sites

Well basically everyone who does C coding on the ColecoVision is currently using SDCC and it's z80 code generation. It is powerful enough and the code generation does improve over time, do to contributions of people like PKK (who works specifically on the z80 part). There is 1k of RAM (fast access) and 16k of Video RAM (slow access) which if managed carefully can support a wide variety of games. C doesn't inherently allocate memory, but instead leaves those decisions up to either the programmer or the support libraries that are included.

 

There are several support libraries written by several different people. So for example Marcel's does everything with the hardware directly, but Daniel's lib4k uses the ColecoVision BIOS wherever possible. Different strategies, so different memory overhead requirements.

 

There are certainly Forth compilers for Z80. I've used one on CP/M on the Adam. But I never developed specific ColecoVision libraries for it. It is stack based, and is very similar in feel to PostScript which I really mastered for some projects for work. I am still quicker at programming in C. So if it is speed of programming that I'm trying to maximize, I'll personally choose C over Forth, given the choice.

 

Following assembled code isn't as bad as you say, since the operations still need to be done, and any code that works efficiently can't waste time doing irrelevant obscure things. There are always valves in any program that make for good points for hacking. And compiled Forth would be no different.

Edited by hardhat
Link to comment
Share on other sites

Well basically everyone who does C coding on the ColecoVision is currently using SDCC and it's z80 code generation.

 

I'm still using the Hi-Tech C compiler. It works. It has some quirks, but I seem to have found all the ones that hindered me. I tried sdcc once or twice, but ran into too many troubles. The main thing was the compiling and linking, which seemed to take ages, if it worked at all.

Link to comment
Share on other sites

 

I'm still using the Hi-Tech C compiler. It works. It has some quirks, but I seem to have found all the ones that hindered me. I tried sdcc once or twice, but ran into too many troubles. The main thing was the compiling and linking, which seemed to take ages, if it worked at all.

 

Interesting to hear you say that. I tried PKK's tool chain and convinced Daniel to convert his toolchain to work with SDCC because I was impressed with the code generation, and the reliability of the compiler. Frequently I would write code that would cause Hi-Tech C to crash, which was quite frustrating for me.

 

With optimization options turned off, I find SDCC to be faster than Hi-Tech C (maybe twice as fast). When I'm coding, that is how I usually run it. I've never had any issues with linking when I use either a Makefile or when I use Daniel's CCI3.exe. And since it is Open Source, I can run it on Mac, Windows or Linux with no issues.

 

But I don't specifically want to get you to switch to SDCC -- do whatever works for you. It's just most programmers that I've talked to use SDCC these days. I truly believe that it isn't the tools, it is the game that matters. I previously use Aztec C before I used Hi-Tech or SDCC. I quite liked it at the time, but these days the C syntax it uses is archaic.

 

And I can say with confidence that everyone seems to use a different assembler if they write code in assembly. It is completely amazing to me that there are that many different z80 assemblers. I use an open source one from z80.info, that I document here:

 

http://www.adamcon.org/~dmwick/mayan/

 

with some good samples for use with Adam or ColecoVision games.

  • Like 1
Link to comment
Share on other sites

I used Hitech C to make Ghost'n Zombie. Then swichted to SDCC for other games . (on recent version of SDCC you have an allocation parameter (don't have the name in head now) to set in the command line to avoid it take ages... ).

 

But recently, i have recompiled Ghost'n Zombie with SDCC . (first i forgot about the allocation parameter it took 40 minutes to compile!!, then with the right parameter it takes about 30 secondes).

 

Something i noticed, SDCC has produced a smaller code. But when i play the SDCC version of Ghost'n Zombie it is slower. i have some slowdown i didn't have with HitTech C , and the game in generally is clearly a little bit slower.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...