PkK

It seems there was a bug in a corner case in the detection of the polygon in which Qix is in. The attached version should have it fixed. Philipp Ȼix3.rom.gz

Another update. This version already has all the basic gameplay. There's Qix and Sparcs. When enough of the area is filled, you get to the next level (Qix gets a bit more active in higher levels, and there are more Sparx). Still missing: * Difficulty selection (currently always easy - you go to the next level when 50% of the area are filled). * Two-player mode * Multiple lives - dying currently halts the game * Game end screen * Interlevel screen * Score keeping It needs some genral polish, and probably some bugfixes, too. Philipp Ȼix2.rom.gz

Another small update, this time with a moving Qix, that can destroy Stix. The Qix in this demo is the type I will use for advanced levels, earlier levels will use a more harmless Qix (the final game will have Sparx type enemies, too, so Qix shouldn't be too dangerous by itself). Philipp Ȼix.rom.gz

No, I mean the thing designed by Eduardo, but IMO in the "official" thread there's too many thing put into one thread, and my question has a well-defined focus, which makes it unlikely to descend into another "when will it be there", so I made a new thread. The information I'm looking for is what hardware at which I/O or memory address, etc. I remember having read such information a few years ago, but I don't know how much has changed since. Philipp

Where can I find the technical documentation for the SGM? Is there a ColecoVision emulator that emulates the SGM? Philipp

Thanks a lot for that list (which, to me is suprisingly long)! Philipp

Sure, but like with the Atari module, it would be Intellivision gaming, not ColecoVision gaming. Philipp I don't think adding some RAM and an auxiliary sound chip to the CV is "adding too much". I'd say it's just right, actually. The more you add, the further it gets fom ColecoVision gaming. Adding RAM is not that big a step. A sound chip IMO is. When you add a different graphics chip or CPU, it's definitely no longer ColecoVision gaming (more like gaming on some other console through an expansion module, just this time it is not an established console like the Atari). That doesn't have to be bad. Even I have some ideas about cool things that can be done with added hardware. But IMO they're no longer ColecoVision gaming. Philipp

Still, ColecoVision gaming can be advanced, and innovated when writing games for the (original*) ColecoVision hardware. Just like music for a medival instrument might be advanced, or someone might come up with an innovative new fighting technique for an ancient weapon. Philipp * Doing something using more advanced hardware can be fun and interesting, but when adding too much t simply no longer is the ColecoVision.

Sorry, here's the correct opcode link: http://opcodegames.com/ Philipp

While I am not a lawyer, I find it hard to imagine the game to be in the public domain in any currently existing jurisdiction on this planet. In most western countries the game is in the public domain, if the creators have been dead for about 70 years. In no signatory of the Berne convention or TRIPS is the game in the public domain unless the creators have been dead for at least 50 years. So when looking for a state, in which to make and sell the cartrigdes legally, have a closer look at the laws in states which signed neither: Afghanistan, East Timor, Eritrea, Ethiopia, Iran, Iraq, Kiribati, Marshall Islands, Palau, San Marino, Sao Tome and Principe, Seychelles, Somalia, Turkmenistan, Tuvala, Vanatu. Philipp

Is there a complete (or at least mostly complete) list of ColecoVision games that notes which ones are arcade ports vs. other ports vs. games originally made for the ColecoVision, or some other easy way to obtain this information? Philipp

How about some homebrew games? Their quality is up to that of the original games, and surpasses them in somecases. newcoleco is one of the veterans: http://www.ccjvq.com/newcoleco/ opcode games are popular,especially around the forums here: http://www.ccjvq.com/newcoleco/ there's some more developers out there, though most of them did not make as many games as the above two. This includes me: http://colecovision....coVision/games/ Philipp

I've been experimenting a bit. Here's an early techdemo (no enemies, no score, when you touch your styx the game just stops, same for some exception conditions, not yet optimized for speed, qix doesn't move, etc). But the basic thing is there: Make lines and have the non-qix part filled. Philipp Ȼyx.rom.gz

Not really. I've thought about it a bit more, and started programming, but there's nothing presentable yet. Philipp

It seems I remembered wrongly (maybe from playing some other Qix clone: I thought the player was also allowed to move along the borders between old blocks). That makes implementing the game a lot easier. Philipp

I'm currently considering writing a Qix-like game for the ColecoVision (see http://en.wikipedia.org/wiki/Qix for an introduction to Qix). However there is one issue that I could not yet come up with a solution for, related to the restriction on the number of colors in the ColecoVision: With arbitrary line locations allowed, there can be the situation of filled_color next to line_color next to unfilled_color, which the ColecoVision in general cannot handle. I see two possible workarounds: 1) Coarse-grained line position: One would not be able to draw lines at arbitrary places, but only on a 32x24 or so grind on the screen. 2) Do not show lines. This would allow movement of the player only along the contour of the current area (similar to the Gals Panic game), not along any previously drawn line (as in Qix). Which of these would you prefer? Philipp

This depends both on personal preferences and on the nature of the program compiled. I've compiled some things at --max-allocs-per-node 100000000 in the past. I also intend to make some improvements to the way sdcc generates tree-decompositions this or next year, which should also improve the code quality / compilation speed trade-off. Please create testcases, and file bugs at sdcc's sourceforge bug tracker for the issues you find. However, them being related to unsigned char seems a bit odd to me, since I also use this data type heavily (mostly in the form of uint_fast8_t), so it should be well-tested. I'd expect the less-used data types, such as float or long long to be more problematic. Philipp

Sorry for having missed this thread for so long and replying so late. The Europen ColecoVisions I have this byte set to to 50. And I take care in my libcvu library to use this byte in the music playback routine to get the speed correct. Philipp

Dear ColecoVision developers, a little later than usual (I try to sync it with sdcc releases) here comes the update of my ColecoVision library and tools. There's less changes than in previous releases, which may be due to the tools getting more mature or due to only about half a year passing since the previous update. The updated libcv can be found at http://colecovision....ent/libcv.shtml libcv changes since 0.20: 0.21: Suggested compiler: sdcc 3.2.0 or newer libcv: Initialize RAM to zero in crt0 to ensure that global and static variables are initialized to zero as required by the C standard. libcv: Do not explicitly initialize cv_vint_handler and cv_vdpreg[0] to zero (since they're implicitly initialized anyway). demos: Make sprites transparent in compression demo. The updated compression tools can be found at http://colecovision....mpression.shtml compression tools changes since 0.1: 0.2: * Fixed empty path stack error message in huffman_encoder. * Code cleanup in huffman_analyzer. * Fixed bug that could result in wrong character frequency counts in huffman_analyzer. Philipp P.S.: Have a look at http://www.colecovis...on/development/ for more ColecoVision development tools, and tutorials on how to get started in ColecoVision development using them.

Thanks, the link is fixed now. There is no such suite currently, just the tutorial on how to get everything installed at http://colecovision....tutorial0.shtml Philipp

sdcc 3.2.0 has been released today. http://sdcc.sourceforge.net sdcc is the C compiler that both Daniel's and my ColecoVision toolkits and libraries use. It currently is the best¹ C compiler targeting the z80 and keeps improving. Also I hope that my work on sdcc may somehow excuse that all my homebrew game projects are far behind schedule. Philipp ¹ Most extensive standard compliance, smallest code size for typical benchmarks using suitable optimization options. A comparison of sdcc and some other C compilers for the z80 and related architectures can be found at https://sourceforge....i/z80 code size Edit: Fix link.

AFAIK MacOS is just another Unix since MacOS X. In that case sdcc and the tools from http://colecovision.eu/ColecoVision/development/ should just work (without needing any of the cywin stuff) as they do on Linux. Philipp

There are tutorials for programming the ColecoVision in C using sdcc at http://colecovision.eu/ColecoVision/development/ the library there also comes with some example programs written in C. Philipp

You're probably overwriting that memory unintentionally from some other part of your program. Maybe a buffer overflow or writing via an unitialized pointer. Philipp

Make it const. The compiler doesn't know that without const: const void* test_map[WORLD_SIZE_Y][WORLD_SIZE_X]; Is an array of pointers to const void*. It will be placed in RAM. void* const test_map[WORLD_SIZE_Y][WORLD_SIZE_X]; Is a const array of pointers to void*. It will be placed in ROM. const void* const test_map[WORLD_SIZE_Y][WORLD_SIZE_X]; Is a const array of pointers to const void*. It will be placed in ROM. And I believe this is what you want here. Philipp