PkK

How about just entering the competition with something a little less polished? A puzzle game can be fun, even if there is no intro / outro or it has only very few levels. Philipp

While I've read a lot of Lovecraft's works and am a homebrew programmer, making his works into video games would be a difficult task: His stories live from a horror of the unknown and undescriptable. The reader wonders about the things that are too horrible for the narrator to describe. This won't work when the shoggoth is a pile of pixels on a computer screen (and maybe even less on a 15 color 256x192 screen that has even further limitations). Philipp P.S.: I haven't played "Call of Cthulhu: Dark Corners of the Earth"; I've heard it's a good game, but full of unfixed bugs.

People have been programming for the ColecoVisionin C now for years (and posting about it here and elsewhere). Currently there exist two "ways" to go: - The libraries by Marcel and Daniel with Daniel's tools. So the compiler used was an oldversion of HITECH-C in a CP/M emulator inside windows. Now Daniel is porting this to the sdcc compiler (currently the easiest way to go on Windows). See http://www.geocities.com/newcoleco/ for more information. - My libraries and tools, which were designed to work with sdcc from the start (currently the easiest way to go on GNU/Linux, however there exists a tutorial on how to use it with Cygwin on Windows). See http://www.colecovision.eu/ColecoVision/development for more information. Philipp

This sound like you're using thegraphic's chip's undocumented bitmask functionality of the color and pattern tables. It has such a side effect on sprites, which emulators don't show. Here's the description I posted to the colecoprogramming mailing list when I encountered it in 2006: And this after having a closer look:

I often encountered such problems when I started programming. With time and experience they became less and less common. Now they are very rare. Philipp

More than a year has passed since the last release of of the libcv and libcvu libraries. Today libcv 0.17 and libcvu 0.10 have been released. What's new in libcv 0.17: libcv: Made default value from cv_get_controller_state() for no key pressed / error 0xf as documented in cv_input.h (was 0xff). libcv: Increased speed of cv_memtovmemcpy_slow() from 8.9 µs / Byte to 8.4 µs / Byte. libcv: Improved cv_vdpout() speed a bit. What's new in libcvu 0.10: libcvu: Made cvu_play_music() play notes one octave higher instead of undefined behaviour for notes that demand frequencies lower than the CV's sound chip can do. libcvu: Fixed cvu_play_music() bug that made notes 1/60 s longer which was a problem for long multichannel tunes, where voices drifted from each other. libcvu: Changed default speed of music from 12 sixteenth notes per second to 10 sixteenths notes per second for more accurate music playback on PAL ColecoVisions (both NTSC and PAL ColecoVision's vint frequency are divided evenly by 10). libcvu: Fixed bug that made sprites with negative y coordinates appear one pixel off their correct position. libcvu: Improved comments in cvu_sound.h These libraries are meant to be used with the sdcc compiler. They can be downloaded from http://colecovision.eu/ColecoVision/development/libcv.shtml Some simple demo programs that show how to use the libraries are included. Introductional tutorials and tools for ColecoVision development can be found at http://www.colecovision.eu/ColecoVision/development/ Philipp P.S.: These are the libraries and tools that have been used to create ColecoVision games such as "Search for the Stolen Crown Jewels" and it's sequel, "Schlange CV", "Monster Masher" and "Cye".

I have to US NTSC ColecoVisions. They work fine using European ColecoVision power supplies. Philipp

http://www.colecovision.eu/ColecoVision/development/ Has programming information, tools and some tutorials. Philipp

out (0xbe), a Works fine for me. Philipp

Something like this?

Should be no problem. I hope I find time to really make the test cart. Philipp

Here comes a small improvment. Again only modes 0-3 work (the single player mdoes) and it'S still rather incomplete. Philipp CG2.rom.gz

To start press one of the numbers 0 to 4 [the otehrs arent't working at themoment] It's a simple duel against an AI-controlled ship, designed as a boss battle for the game. The level will restart one the thrid number in the upper left corner reaches 1000 or you die. The upper left number is your energy. You die when it reaches 0. It reloads when doing nothing. All actions cost some energy. The number below it is the reload counter. You can't fire missiles or change color while it is nonzero. Philipp CG.rom.gz

No. I haven't looked for something like that though, since I mostly use classic music for my games. Philipp

Well, using midi2abc and abc2cvm works for simple midi files, however it will generate output for use with my libraries (which work with sdcc not HITECH-C). Some of the music in Schlange CV hase been done that way. Philipp Thanks for your anwser. I will look for these tools. Could you give me detail on the format used by your libraries? I think i could convert it to a format i can use. It's a rather primitive format, which I intend to replace by a better one one day, but that probably won't happen this year. Music is just arrays array of 16 bit values, each value is one note. You need an array for every sound channel you use. The special value 0xffff marks the end of the music. Let bit 0 be the least significant bit in the 16 bit value, bit 15 the most significant one. Let [n,m] be the m-n+1 - bit integer consisting of bits n, n + 1, ... , m. [0, 1] is the loudness, where the default value of 2 stands for mezzo forte, 3 for forte, 1 for mezzo piano, 0 for piano. [2, 3] is the note length, where 1 is 25% (staccato), 2 is 50% (unsused), 3 is 75% (default), 0 is 100% (legate or ties). [4, 7] is the note length, where 1 is a 1/16 note, 2 is a 1/8 note, etc, with 0 being a 1/1 note. [8, 11] is the halftone (C is 0, C# is 1, D is 2, etc); the special value 0xf stands for a pause. [12, 15] is the octave. I suppose you probably could just use the music playing functions from libcvu and replace the calls to cv_set_frequency() and cv_set_attenuation() with whatever Daniel's library uses to set frequency and attenuation of tone generators. They're written in standard C so they will probably compile with HITECH-C with just some minor changes. Philipp

Well, using midi2abc and abc2cvm works for simple midi files, however it will generate output for use with my libraries (which work with sdcc not HITECH-C). Some of the music in Schlange CV hase been done that way. Philipp

Well there's always a completeness / complexity tradeoff. I thought about this a bit and think that a resonable testcart would include the following functionality: Noninteractive tests: - RAM test - VRAM test - BIOS checksum - Detect PAL/NTSC - ROM checksum - 5th sprite bit - sprite collission bit - +5V line voltage Interactive tests: - Sound channels - Noise channel - Controllers (incl. SA and Roller) - Controller ports - Graphics output This is what can be done by something that plugs into the cartridge port (much more could be done otherwise, but I don't think it would be worththe effort). It should allow to detect and diagnose nearly all ColecoVision problems. I just designed the pcb for such a test cart. Philipp

There's tack, which I never used, but it has a Z80 backend and C, Pascal and MODULA-2 frontends. Philipp

I don't think there will be that much diversity in C compilers used for ColecoVision development. Probably sdcc, HITECH-C 3.09 and maybe HITECH-C 7.80PL2 will be used: For HITECH-C 3.09 there exist lots of tools and it's the compiler most people use. sdcc and HITECH-C 7.80PL2 generate the best code. Some time ago I compared three sdcc version, HITECH-C 7.80PL2, ADC 5.02 and z88dk 1.8. You can see the results in the table at the bottom of http://sdcc.wiki.sourceforge.net/Philipp%27s+TODO+list We see that in terms of code size and standard C support sdcc and HITECH-C 7.80PL2 are the best compilers. According to the compilers' websites sdcc and z88dk are free software. HITECH-C (HITECH-C 3.09 for CP/M is non-free freeware) and ADC 5.02 are nonfree, a HITECH-C 7.80PL2 license costs $295, an ADC 5.02 license costs $745. Philipp

I do not know of any. The instructiuons at http://colecovision.eu/ColecoVision/develo...tutorial0.shtml should do, they might look a bit complicated due to the use of Cygwin when used with Windows, but it's not a problem for someone using sdcc on a Unix like GNU/Linux or at least familiar with Unix. Philipp

Well, there's rather long comments in the header files documenting each function and there are some sample programs that come with the libraries. Two short tutorials exist. However there's certainly more documention for the old Hi-Tech compiler. The libraries do not yet support the spinner wheel on the super action controller and the roller controller. I do not know of any other limitations. There are more tools and documentation for the HITECH-C approach. On the other hand there are some advantages to using sdcc over HITECH-C: It's still maintained and being improved, it generates better code and supports a larger subset of the C standard. sdcc and the tools for it are easy to use with standard unix tools such as make or sed. xmess and Meka do. VColeco works with wine. AFAIK Meka. However I suggest using multiple emulators for testing. I mostly use xmess, sometimes Meka, more rarely my own emulator or VColeco. There are some tools for use with sdcc. However they are command line utilitites, not GUI applications: png2cv creates tile data from .png graphics png2cvs creates sprite data from .png graphics abc2cvm is for music, cvmtuning can be used when playing music using a tuning different from the common ISO and scientific tunings. Then are some compression utilities, too. There currently is no dedicated tool for sound creation. Philipp

On the 11th I was at the Retrobörse in Karlsruhe. The person next to me was (among other items) selling Lynx homebrews. I no longer know his name, but he has a source for the materials needed. There's a thread about the Retrobörse in these forums. Philipp

Yes (you couldn't easily use this mechanism from interrupt handlers though). Philipp

It is not read-only. However there is no R/W signal available at the cartridge port, so you can't easily distinguish between read and write accesses. So each address has to be used for either reading or writing. Acessing flash is a little bit complicated. You need to do that 55/AA sequence for erasing of sectors, etc. Doing that with the ColecoVision would require to place the CPLD in between the cartridge port and the flash to insulate the flash from all the thing that can happen on the cartridge port. This would require a bigger CPLD. Philipp

I can agree about the different robustness of parts from different controllers, but I believe one reason that hand controllers "fail" is because they get used a hell of a lot more. Where as the novelty of the Roller Controller or Driving Module tends to wear out after a while and then they get put away, partially because there weren't too many games programed for either. Plus you have to have 4 C-cell batteries (or the Parma-Power Pack) on hand to use the Driving Module unless you've modded it to run off of the console's power like me! Having touched (and completly disassembled) a roller controller for the first time just a few days ago I'm tempted to write a game for it. However that would significantly reduce the already tiny number of potential customers of homebrew games even further. And I still have four ColecoVision game projects to complete and release that are not designed for the roller controller. Philipp