PkK

Not just Windows. I use Debian GNU/Linux for development, and the tools should work just fine on many other systems too (for sdcc, the compiler both newcoleco and me use, tehre even are daily automatic tests to ensure that it works on lots of different systems (http://sdcc.sourceforge.net/snap.php), including Linux, Windows, MacOS, Solaris, FreeBSD, NetBSD (for many of them the tests are even done on different architectures). Philipp

IMO, the ColecoVisions originally built for RGB output give a great picture. These days my preferred setup is one of those combined with a SCART-to-HDMI converter. Philipp

I've bought cheap, "untested" ColecoVisions a few times, some from the US, but mostly from Europe. I always got a working ColecoVision, but most of the time with a broken power supply. Philipp

It will be available at least at the usual places for my games: GoodDealGames (US) and Telegames (UK). If there is more, I'll report in in this thread. Philipp

Which, however, would only work with certain box types. Philipp

Bankruptcy Builder also comes with overlays: http://www.colecovision.eu/ColecoVision/games/Bankruptcy%20Builder.shtml Philipp

After some further graphics adjustments, the addition of another level, lots of testing and debugging, Cye 1.2 is now nearly ready. Last weekend I burned the EPROMs and assembed the cartridges, next weekend I will put them into the boxes together with the manuals. Philipp

Don't forget that you will need a PAL BIOS for a PAL machine. I never bothered to check if there are any differences other than the region byte. But if that byte is wrong, some games won't work as intended. Philipp

Sure. But we're talking about mockups here, and the dicussion was boaut how to realize the graphics. Other aspects would be a different topic. Philipp

The NES one in this video looks interesting. Monochrome or not, dithering is definitely something to consider for Doom on the CV. Philipp

I don't see a godd alternative: It is a FPS, with 3D graphics and I want to keep the Doom atmosphere. If the ColecoVision had a few more colors, especially shades of gray, and a few graish colors, I might be able to do with less colorful walls. Philipp

Maybe a custom ammo/health/armor display would make more sense on the ColecoVision though. Philipp If I really find a lot of time I might actually try this one some time.

A few years ago I worked on a Tunnels and Trolls for the ColecoVision, too. My game would have been based on the RGB (I got a T&T license for the ColecoVision with the royalitites to be paid in games, not money). I developed a techdemo for a giant scrolling map (see http://atariage.com/forums/topic/118543-colecovision-tt-rpg-very-early-techdemo/ for a techdemo ROM), and also a Megacart to be able to fit more content into the game. But since then I simply did not have enough time to complete such a project. This might be different next autumn, so I might be able to complete it for early 2015, but I cannot make any promises. Philipp Edit: My game will most likely be based on the current version (7) of the T&T game rules, not the version of the rules that was current back when the ColecoVision as released (4 AFAIK). Edit2: I see that there was progress an controversies since I last worked on T&T. Apparently the 7th edition is no longer the current version, so I'll have to look into the deatils of this some more.

Paypal can be quite annoying. Years ago, Paypal froze my account, and they kept insisting that I give them a scan of a national id card. German law states that everyone has to have a national id card or a passport. I don't have a national id card, and Paypal wouldn't accept the scan of the passport. I don't even remember how I got it finally resolved, but it took quite some time and effort. Then, half a year later, I had the same probem again. About half a year ago, they again froze my account, this time also disabling the ability to recive money. They presented a list of things I should provide online. With each item I provided, the list got shorter by one. In the end there still was a notice, that my account is frozen until I would provide everything in the list, but the list was empty at that point. However, this time I was able to resolve the issue by email. I do not use a separate bank account, but in Germany, when someone sucks money out of my account, I can can order my bank to undo it, as long as I do so within two months. Philipp

I fixed the peephole issue and implemented support for named address spaces in ROM. Something like this should work now (sdcc 3.3.1 #8837 or later): void setb0(void) // The function that sets the currently active memory bank to b0 { *((volatile char*)0xffff); } void setb1(void) // The function that sets the currently active memory bank to b1 { *((volatile char*)0xfffe); } __addressmod const setb0 spaceb0; // Declare a named address space called spaceb0 that uses setb0() and reisdes in RAM __addressmod setb1 spaceb1; // Declare a named address space called spaceb1 that uses setb1() and resides in ROM const spaceb0 int x = 42; // An int in address space spaceb0 spaceb1 int *y; // A pointer to an int in address space spaceb1 const spaceb0 int *spaceb1 z; //A pointer in address space sapceb1 that points to a constant int in address space spaceb0 The variables will be placed into areas of the same name, so you can use linker options -b to place the named address spaces into memory. Again, you might also want to have a look at section 3.6.2 of the sdcc manual. Philipp

If you do please also include information on the working / not working / barely working / whatever condition. The mattel one only seems to list loose vs CIB in the condition column. Also a comment field, so things like French whatever version don't have to go into the condition field like they do in the mattel databse. Philipp

A few years ago, I made my own MegaCart. But I never found enough free time to make a game that really required it, and I found the use from sdcc too cumbersome (similart to how this one works). So I started on building support for bank-switching into sdcc. I just had a look at the current state. It would work for bankswitched RAM, but needs a bit of work for the ROM. When I find a bit of time, I'll fix it. Once that is done, using the MegaCart from sdcc should be much simpler. We would use named address spaces (see section 3.6.2 in the sdcc manual, which also contains a small example of how this works for RAM). You just write a function to switch to a particular bank, declare banks for your variables and then just access them normally: void set_bank_a(void) { *((volatile char*)0xffff); } void set_bank_b(void) { *((volatile char*)0xfffe); } __addressmod set_bank_a bank_a; __addressmod set_bank_b bank_b; const bank_a char d = 'c'; // A const char in bank a. const bank_a char *const bank_b c = &d; // A const pointer in bank b that points to a const char in bank a. char f(void) { return *c; // sdcc will automatically insert the calls to set_bank_a() and set_bank_b() as necessary. } Actually, sdcc already generates correct code for the function f() in this example, but messes up the initialization of c and d (sdcc behaves as if they were in RAM). sdcc will try to minimize the calls to the bank selection function, and will only insert the minimum number necessary. Read "Optimal Placement of Bank Selection Instructions in Polynomial Time" for the details. However, it does not yet do inter-procedural analysis, so it doesn't know which bank is active after a function call. Philipp P.S.: All this is about data in banked memory, not calling functions in banked memory. To me, the latter problem seemed less interesting from a theoretical computer science perspective, so I never bothered with it.

There seems to be a bug in the current (revision #8835) sdcc pephole rules that results in the access being optimized away despite the volatile. Until it is fixed, compile with --no-peep. Also the variable is unnecessary, a simple *((volatile char*)0xFFFF); is sufficient to generate a read access. Philipp

In case you also consider C programming, you might want to have a look at the tutorials at http://colecovision.eu/ColecoVision/development/tutorial0.shtml http://colecovision.eu/ColecoVision/development/tutorial1.shtml http://colecovision.eu/ColecoVision/development/tutorial2.shtml Philipp

My current compession tools (rle+huffman, http://colecovision....mpression.shtml) result in a total size of 3867 bytes for the data (675 for the color data, 3192 for the pattern data), and another 512 bytes for the huffman tree (which typically is shared between all compressed data in a game, and could be considered part of the decompression program). This compression has the nice property of needing nearly no RAM during decompression. Philipp P.S.: Decompression into VRAM with LZ77 could be a nice idea for good compression ratio, but quite slow decompression.

Speaking of giant maps, I made a techdemo for what was intended to become part of a T&T game years ago: http://atariage.com/forums/topic/118543-colecovision-tt-rpg-very-early-techdemo/ No VDP magic there, just procedural map generation. The map size is 32768 x 32768 tiles, tile size is 8 x 8 pixels. I wish I was a productive as Daniel, and would be able to complete games more often; but I just don't find much time for ColecoVision programming these days. At least prgramming in C instead of asm helps a lot. Philipp

A good EPROM programmer will cost a bit, but last (as long as the software is updated). I use an old Willem (no longer in production), but the software works under wine on Linux. Philipp P.S.: My 30 minutes of free WLAN at the airport are about to expire, why can't they just give unlimited time?

Well, has anyone seen graphics corruption in any of my games caused by accessing the graphics chip at any time? Even the demo programs that come with my tools access the memory graphics memory at any time. It can be done safely, but it takes a bit of extra effort (that the libcv/libcvu libraries can handle): Basically there sre two issues: 1) The timing. My library has a fast function for writing to video ram, that takes 5.87 µs per byte (to be used when the screen is off or during the time you consider "safe"), and a slow one that takes 8.4 µs per byte (to be used at any other time). Using the wrong one leads to video memory corruption when writing, or wrong data when reading. 2) vint corrupting the setting of the graphics memory address; corruption here can again result in corruption of video memory or data read. Here the solution is to detect this corruption, and fix it. Have a look at libcv/src/cv_set_write_vram_address.s, libcv/src/cv_memtovmemcpy_fast.s, libcv/src/cv_memtovmemcpy_slow.s and libcvu/src/cvu_memtovmemcpy.c for the details in how you can write safely to graphics memory any time. Philipp P.S.: libcv/libcvu can be found at http://www.colecovis...ent/libcv.shtml

It can be done safely any time. Philipp P.S.: I can provide details later, if there is interest; have to catch a flight now.

All my games update video ram and registers while the graphics chip is rendering. When I first started programming it took some time to get things right, but I am quite sure none of the published games has any graphics corruption (at least not due to this issue). Philipp