PkK

Well, sdcc is an compiler, which means it is meant to transform a higher language (in this case C) into asm. But it also comes with the sdasz80 assembler and you can use inline asm from within C functions (though I prefer to keep my asm stuff in separate files and do not use inline asm). Philipp

You definitely want to go with sdcc (http://sdcc.sourceforge.net) for the compiler; it is simply the best there is these days for the ColecoVision (also the IAR one sometimes generates smaller code for the Z80 than sdcc does). The linker sdcc uses emits a .map file that shows memory usage (code size and global variables). Both my tools (http://www.colecovis...on/development/) and Daniel's are meant to be used with sdcc. Philipp

IMO, the CV is the wrong platform for this. For hobby and leisure, restricted hardware capabilities are fine. Also again the target demographic (particular job and CV owner) is just too small. Philipp

I guess it would be hard to get this right: A big problem for homebrew programmers is the already small CV community. So we need to reach at least a substancial fraction of players. Sure, arcade ports are always popular, but with different game concepts we 're already down to often less than 50 copies. With an erotic game this problem becomes even worse: Not only do we loose part of the community by choice of genre, but we will again loose part of the community by choice of sexual prefences. And of course there are those that don't want to see anything sexual in their video-games at all (this might even include game distributors creating another problem). Essentially, creating an erotic ColecoVision game will result in all the effort for making a ColecoVision game, but only have a potential of maybe 10 copies or so sold. Philipp P.S.: Also IMO, making a good erotic game for the CV is as hard as making a good lovecraftian one: For Lovecraft, the story is everything, since it is all about the unknown horror, so you can't show it graphically. For an erotic game, the CVs graphic capabilities are essentially not good enough to create atmosphere visually, so you need a good story to do that. P.P.S.: Of course the problems mentione mostly apply to ColecoVision games where the erotic aspect is the main focus. The situation looks better for games where this is only a side aspect. Once I get around to making some Tunnels & Trolls games, there most likely will be romance options.

I don't think a light-gun game would be popular. Light-guns only work with CRT TVs; few people have one these days. Philipp P.S.: Edit: capitalized "crt" into "CRT".

Not that many. Other authors are more productive. The list can be found at http://colecovision....coVision/games/ Philipp

Well, there's basically two ways to get more colors in an object: * Use background tiles in addition or instead of sprites. * Use different sprites for the top an lower parts - the 4 sprite limit is per line.

If you want to program in C, I would suggest to have a look at teh tutorial here: http://www.colecovision.eu/ColecoVision/development/tutorial0.shtml and also at the demos that come with libcv/libcvu at http://www.colecovision.eu/ColecoVision/development/libcv.shtml Philipp

Well, homebrew releases are made in relatively small numbers, there is a lot of economy of scale in printing costs, most buyers prefer boxed games. So if I offered unboxed versions of my homebrew games the price difference would be less than 10%. I guess that's not worth it in general. On the other hand I am planning to release Cye 1.2 later this year, and I intend to make at most 50 carts (since many gamers will already have an earlier Cye release). I haven't decided about the box yet (previous Cye games used square boxes like SCJ2, current games uses boxes with more stnadard dimensions). Maybe I should consider not using a box at all. Or just use rather simple boxes this time. Philipp

One option would be these homebrew kits: http://www.colecovis...ebrew kit.shtml Philipp

The ColecoVision has pixel-accurate colission detection hardware for collisions between sprites. However, this functionaily is not commonly used by games. And unfortunately, it seems to be one of the first things to fail when the voltage supply at the graphics chip is too low (low voltage is a common problem on ColecoVisions due to voltage switch dirt buildup and power supply degradation). So if you use it be prepared for players complaining that your game doesn't work even though other games are working on their systems. Early beta versions of SCJ3 did use it, then I changed it to detect if the colission detection is working at startup, but in the end I just went with always using the software fallback, that I needed anyway for when the hardware didn't work. You can access the whole 32K directly. Bank selection is only required is you're using some custom hardware to go over the 32K limit. Low for non-Coleco controllers, but many player will have the super action controllers from Coleco. Philipp

It has been some time since I released a new version of abc2cvm, my tool for transforming music from abc files into a format useable with my library libcvu. However, recently, new features were needed to be able to handle the sonatas by Giuseppe Domenico Scarlatti, as used in my recently-released game Cix, resulting in this new release. Here's the list of changes since 0.12: 0.13: -Allow content other than the identifier in V field (clef, name, etc). -Removed default support for ! line breaks (conflicts with ! decorations). -Print warning for deprecated + decorations by default. -Added support for ! decorations. -Added upport for $ line breaks. -Added support for I header to enable old linebreak and decoration syntax. -Clearly distinguish errors and warnings in messages. -Fix handling of zero-length output notes that can occur with long grace notes. -Support for tenuto decoration. The tool can be found at http://www.colecovision.eu/ColecoVision/development/abc2cvm.shtml Philipp P.S.: The attached .pdf contains music used in my game Cix, using some of the new features in abc2cvm. Sonatas.pdf

These are the versions of libcv and libcvu used in my recently released games Search for the Stolen Crown Jewels 3, Bankruptcy Builder, Shunting Puzzle and Cix. Here's the list of Changes compared to the previous versions: 0.22 / 0.14: Suggested compiler: sdcc 3.3.0 or newer libcv: Support for more efficient initialization, as used by sdcc 3.3.0 in crt0.s. libcv: Some documenting comments in cv.h. libcv: Support for interrupt for roller controller and super action controller wheel. libcv: Move startup code to _CODE section in crt0.s for more flexible ROM use. libcv: Documented BIOS stuff in header in crt0.s libcvu: Support for roller controller and super action controller wheel. demos: Removed assembler variables in cursor32 Makefile. demos: Recreated cursor.png.sprite.c. demos: Added cursorsmooth demo for spinner. libcvu: Fix include guard in cvu_compression.h. libcv: Use only Unix line endings. libcvu: Use only Unix line endings. This version of the library interacts with the new initialization mechanism for global variables in sdcc, so it will not wor with sdcc releases older than 3.3.0, nor will older versions of libcv work with sdcc 3.3.0. The libararies can be found at http://www.colecovision.eu/ColecoVision/development/libcv.shtml Philipp

A new version of sdcc, the compiler used with both Daniel's and my ColecoVision development tools, has been released today. Compared to the previous release, there are many improvements relevant to Z80, and thus ColecoVision development. Here's the release announcement from Maarten: A new release of SDCC, the portable optimizing compiler suite for Intel MCS51 based (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based (z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A) and Microchip PIC16 and PIC18 microprocessors is now available. Sources, documentation and binaries compiled for x86 Linux, x86 and x64 MS Windows and Mac OS X universal binaries are available ( http://sdcc.sourceforge.net ). SDCC 3.3.0 Feature List Many small improvements in code generation for the z80-related ports - merged smallopts branch lospre (currently enabled for z80-related and hc08-related ports only) - merged lospre branch More efficient initialization of globals in z80, z180, r2k and r3ka ports. Inclusion of tests from the gcc test suite into the sdcc regression test suite led to many bugs being found and fixed. Split sdas390 from sdas8051 Merged big parts of ASxxxx v5 into sdas New pic devices (synchronization with MPLABX 1.60). (Except for very old MCU-s.) New script which disassembles those hex files, in which MCS51 code there is. (mcs51-disasm.pl) Added the PIC16F1788 and PIC16F1789 devices. C11 _Alignof operator. C11 _Alignas alignment specifier. C11 _Static_Assert static assertion.

Well, the cart most likely will be the small type I've used for all my games so far (since that's waht I have). The box most likely will either be the square one I used for SCJ2, Cye 1.0 and Cye 1.1, or the new type I used for my most recent four games. The latter is close in dimensions to the standard ColecoVision boxes, but close in material to the SCJ2 / Cye 1.0 / Cye 1.1 boxes. Philipp

I might not be unreasonable to assume I'm a bit biased, but this is my list, starting with the very best, and ending with the good ones: Bankruptcy Builder Cix (for some reason always transforms the real name into Ȼi̅x̅) Cye Schlange CV Monster Masher All of these have a simultaneous two-player mode that combines elements of competing and cooperating. For the games that have an alternatin two-player mode, I prefer the ones that alternate after each level (instead of only after a player death), e.g.: Boulder Dash and the games from the Serch for the Stolen Crown Jewels series. Philipp

Some years ago, I wrote Cye, a puzzle game, which has some similaritites to Sobokan and Boulder Dash, and is essentially a port of Kye. Unlike Kye, Cye has a simultaneous, cooperative two-player mode. Since there were not many ColecoVision games of this type, and ColecoVision gamers tend to prefer arcade ports, I only made a limited run of 50 copies. But the game sold out very quickly, so I made 20 copies of Cye 1.1, which has the same gamplay as Cye 1.0, but nearly all single-player levels are different. A few years have passed. Cye 1.1 is sold out, the sdcc compiler and the other tools and libraries have improved since. This made it possible to make Cye 1.2 with more levels than the previous versions. Cye 1.2 includes all levels from Cye 1.1 and all except for 10 from Cye 1.0. It also contains 2 new two-player levels, for a total of 41 levels. I also made some changes to the graphics, and updated the demo. More information on Cye and the demo can be found at http://www.colecovis...games/Cye.shtml Here's a screenshot: and for comparison an old screenshot of the same level from Cye 1.0: I consider the game complete, but will do more testing to ensure it works well on real hardware, both NTSC and PAL. Also I haven't yet decided which type of box to use or how many cartridges to make. Philipp

Sorry for the bad lighting conditions. Back left: SCJ2 box, front right: SCJ3 box, back right: SCJ box, front left: Fan-made SCJ2 box in standard box style and size. Philipp

The boxes are standard size in two dimensions, but a bit bigger in the third dimension. They are also made from stronger material compared to the standard boxes. Basically, the box type is similar to the high-quality one I used for SCJ2, and Cye but in a more standard size. Philipp

It was first sold at the German convention Retrobörse 2008 in Karlsruhe. Later, remaining stock was available through Good Deal Games. A total of 20 copies were made. More information on the different versions can be found at: http://www.colecovis...games/Cye.shtml Philipp

I've been selling homebrew kits for some years. A homebrew kit contains all the materials that go into a cartridge. The classic homebrew kits use a DIL / DIP EPROM, and require soldering (except for the homebrew kit CV prototype, which has a socket, but is more expensive than the others). Now I've added another line of homebrew kits. These use a PLCC EPROM and do not require soldering. More information on the homebrew kits is available at: http://www.colecovis...ebrew kit.shtml Philipp

Well, most ColecoVision games do have this alternating two-player mode. As far as gameplay is concerned, just displaying a message telling players to hand over the controller would be equivalent (and not require a second controller). In most of my games, I implemented a simultaneous two-player mode, one doesn't a the two-player mode at all, and the others have the alternating one. Implementing and debugging a simultaneous two-player mode can be substancial effort, since you need two players to really test it. But IMO it is worth it since a simultaneous two-player mode is more fun. And I intend to continue implementing a simultaneous two-player mode for all games were it makes sense to do so. Still I wonder what other players think about this. Is the two-player mode important to you? Do you often play games in two-player mode? Philipp

Now all cartridges have been assembled, and all games are in their boxes:

With Telegames UK the other¹ store that has carried my games in the past is on board for this release as well. They too, have also ordered some more "Search for the Stolen Crown Jewels 2". Philipp ¹ Once there also was gameconsoles.com / Midnight Sun, but it seems they no longer exist.

Well, I intend to send the games before the end of next week to them. I guess Good Deal Games will make them available upon arrival, but the exact time will depend on shipping time, and time time for customs formalities. Philipp