Jump to content
IGNORED

What language are Colecovision games written in?


Rudy

Recommended Posts

I think when the CV was released a Pascal compiler should be available, I remember saw some Colecovision documents and even some sourcecode written in Pascal.I think for the games released back then, most was written in Pure Assembler, But who knows, I think Spectravideo and Atari used Assembler only.

  • Like 1
Link to comment
Share on other sites

 

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.

 

my attempts were different from Haroldo

 

What Haroldo did was trying to fork it by getting only the .asm from it, patching this .asm for compiling at WLA-DX, and then using WLA-DX for compiling it.

 

What i did was using ZXBasic-Compiler only (without WLA-DX), using a Bash script (on Linux, perhaps might work on OSX/Darwin as well, and all other Unix-based operating systems - i have no idea on how to do it in other operating systems, like ReactOS, Haiku, ArOS and others - i saw somewhere someone tried to convert that .sh into a .bat, somehow, and about how to install dd on those operating systems that is lacking it? ) that converts the resulting .bin file into a .rom file, and at './library' i have custom libraries that accesses the display, joypad, sound, etc.

 

At most, what you must care in overall is to avoid ZX-Spectrum specific commands - getting this assured, it's almost guaranteed that everything will work fine

 

about extending Boriel’s ZX-Basic compiler this way, the goal i’m dreaming about is to be able to compile to all kind of z80 machines (computers, game consoles, arcade machines, handhelds, etc.)

Link to comment
Share on other sites

  • 3 weeks later...

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.

 

 

If you already have chosen efficient algorithms, and have some function called in an inner loop that has a big impact on the speed of your game, and a look at the compiler-generated code shows ineffciencies, and you are willing to really think about how to do the calculations fast in assembler, then assembler is the right tool for that function.

 

Often, however, hand-written assembler would only be marginally faster than hand-written assembler code, and assembler code written without putting a lot of effort into making it very efficient might even be worse than compiler-generated code. And the sdcc compiler keeps improving. My games first written around 2006-2008 often had about a dozen functions written in assembler. When I now look at them again, many of them would be adequately handled by the compiler. I sometimes removed asm functions and went back to the C version, because the improvements in the compiler, with the C version now being as good or nearly as good as the asm version.

 

There are some functions for which I noticed sdcc would generate rather bad code many years ago. I kept them around and used them as a benchmark while working on sdcc. Numbers that show how sdcc improved over time can be found at http://sdcc.sourceforge.net/mediawiki/index.php/Z80_code_size - even though the graphs are old).

 

Philipp

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... ).

 

--max-allocs-per-node. The defualt is equivalent to --max-allocs-per-node 3000. Lower numbers make sdcc faster, but the resulting code worse. I rerely set it to valeus lower than the default. AFAIR, the release version of Bankcrupty Builder was compiled with --max-allocs-per-node 1000000. For the code speed vs. code size trade-off, there's also --opt-code-size and --opt-code-speed.

 

Philipp

Link to comment
Share on other sites

  • 4 weeks later...

 

If you already have chosen efficient algorithms, and have some function called in an inner loop that has a big impact on the speed of your game, and a look at the compiler-generated code shows ineffciencies, and you are willing to really think about how to do the calculations fast in assembler, then assembler is the right tool for that function.

 

Often, however, hand-written assembler would only be marginally faster than hand-written assembler code, and assembler code written without putting a lot of effort into making it very efficient might even be worse than compiler-generated code. And the sdcc compiler keeps improving. My games first written around 2006-2008 often had about a dozen functions written in assembler. When I now look at them again, many of them would be adequately handled by the compiler. I sometimes removed asm functions and went back to the C version, because the improvements in the compiler, with the C version now being as good or nearly as good as the asm version.

 

There are some functions for which I noticed sdcc would generate rather bad code many years ago. I kept them around and used them as a benchmark while working on sdcc. Numbers that show how sdcc improved over time can be found at http://sdcc.sourceforge.net/mediawiki/index.php/Z80_code_size - even though the graphs are old).

 

Philipp

I would contest the statement that hand written assembler would only be marginally faster, but it really does depend on the code, and what you were trying to do.. I like C, I would really like to try it out on the CV soon. I'm very curious to see how well the SDCC works.

 

 

 

Link to comment
Share on other sites

  • 3 months later...

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. :-)

I've read that Forth was used often for 2600 games.

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...