PkK

Dear fellow ColecoVision developers. I haven't posted here in a long time, and haven't found time to develop anything specifically for the ColecoVision (or the Sega 8-bit systems) in a long time. But I have still been working on the Small Device C Compiler (SDCC), which many of us use to write games for the ColecoVision, either directly or as part of a downstream project. The first release candidate (RC1) for SDCC 4.4.0 is available in our SourceForge File release system: https://sourceforge.net/projects/sdcc/files/ In addition to the source package, binaries are available for amd64 Windows, amd64 macOS, and amd64 GNU/Linux. If you have time, please verify it and report your positive or negative results. In addition to various bug fixes, notable features added since the 4.3.0 release are: * Optimizations for rotations. * struct / union parameters for hc08, s08 and mos6502. * Many bug fixes for -ms08 --stack-auto. * struct / union return support for hc08 and s08 (caller side only). * Generalized constant propagation. * New command line option --syntax-only to only parse the input. * Added C99 header inttypes.h * Added library functions imaxabs, imaxdiv, llabs, strtoimax, strtoll, strtoull, strtoumax, wcsncmp, wcstoimax, wcstol, wcstoll, wcstoul, wcstoull, wcstoumax * New r800 port to better support the ASCII Corp R800 and Zilog Z280. * Changed the default calling convention for r2k, r2ka, r3ka, tlcs90, ez80-z80 from version 0 to 1 (this is an ABI break, and will require changes to user-written asm functions or their declarations). * Improved optimizations for code speed for stm8, pdk, z80 (and related). * New mos65c02 port to better support the WDC 65C02. A full list of changes can be found in the ChangeLog: https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.4.0-rc1/sdcc/ChangeLog Philipp (SDCC 4.4.0 release manager) P.S.: there is currently a survey at https://terminplaner4.dfn.de/EQgiMIYKQafCQLtr where you can state which SDCC ports you use or intend to use.

I'm not sure I understand what you are trying to say about the technical aspects of bankswitching. But it won't get you 16K from an 8K chip. You could map 16K into the space used by an 8K chip, but you'd still need a physical 16K of (E)PROM. Unless you've used up all the 32K of program space available without bankswitching, bankswitching provides no benefit. As we see from historical games, which typically don't even use the full 32K, the size of the EPROM wasn't the bottleneck for most game development (the price of (E)PROM and the development toolchain were the relevant limits). And I really don't see how this could have "saved" Coleco: to me, the size of the cartridge memory seems quite unrelated to the causes of the Video game crash.

Using jp instead of call that way is called "tail call optimization". It is a standard optimization done both by assembler programmers and compilers (e.g. SDCC).

The library is written partly in asm (for low-level stuff and some of the speed-critical parts), partly in C. The demo is then written in C. There used to be more asm in the library, but the compiler has gotten much better over time. So recently, some of the hand-written asm from years ago got replaced by C code, since the compiler now generates code that is at least nearly as good, and often better than the old hand-written asm. Even today, it can make sense to have a look at the asm the compiler generates for speed-critical parts to check if hand-written asm could be faster. But often, the compiler, when using the right optimization options will generate good-enough code. IMO programmer time is most efficiently spent looking closer and longer at the parts that are really speed-critical and leaving the rest to the compiler, instead of writing everything in asm.

My library comes with a demo "cursersmooth", that shows a cursor on-screen that can be moved both by the joystick and by using the roller controller as a trackball. I only tested it with the roller controller and super action controllers though, not the driving wheel.

If you don't use the ColecoVision BIOS, you have all the RAM to yourself. The BIOS will just pass interrupts to your code, and no BIOS routine using any RAM will ever get involved. None of my ColecoVision games do use the BIOS routines, so I can freely use the whole RAM.

SDCC 4.2.0 has bee released today.

Release Candidate 1 for 4.2.0 has been prepared. Source, documentation and binary packages for amd64 GNU/Linux, 32 and 64 bit Windows and amd64 macOS are available in corresponding folders at the usual place: http://sourceforge.net/projects/sdcc/files/

I can't speak for all SDCC developers, but me and two other developers intend to focus on improving standard-compliance this summer (and thus for 4.3.0).

The new calling convention was found by 1) Adding flexibility to SDCC so it can handle nearly any register for arguments in any order. 2) Doing lots of experiments to see what works best (for SDCC). 3) Choosing what worked best as new convention. Note the "(for SDCC)" in 2). It turned out that current SDCC can't handle a large number of register arguments well. When more arguments are put in registers, on average, SDCC spends too much effort shuffling data around in registers, and is hindered by a lack of free registers. One aspect it that the arguments are considered one at a time, so also the number of arguments, not just the total amount of registers matters. Example: if the ABI has one int argument in hl, the other int in de, but for code generation the opposite would be better, an assembler programmer would just use ex de, hl. But SDCC currently can't do that well (on the other hand, if it is a single long argument, SDCC will use ex de, hl if codegen prefers the upper and lower half swapped). So the new ABI is something that works very well for SDCC; for assembler programmers it surely is a step forward too, but assembler programmers could use more register arguments well than SDCC can. IMO this new calling convention should be good enough for the next 10 years or so. Philipp P.S.: A few details: https://arxiv.org/abs/2112.01397 P.P.S.: I haven't looked at MDL recently. When I did a while ago using it on some code generated by SDCC, I found more MDL bugs than potential for improvement in SDCC. But the bugs are fixed now, and I assume MDl has progressed further, so the situation is likely different today.

An SDCC 4.2.0 release is expected in February. For those of you that want to use 4.2.0, now is a last chance to check if there are any issues affecting you that could still be fixed before the release. Major changes since 4.1.0: * C23 memset_explicit * Support for --oldralloc has been removed from the z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends. * gbz80 port now uses more efficient block-initalization of global variables (users of custom a crt0 need to adapt theirs). * Full support for __z88dk_callee for the z80, z180, gbz80, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka, stm8 backends. * Support for __raisonance, __iar and __cosmic calling conventions for stm8. * Support for a new __sdcccall(1) calling convention in the stm8 port AS NEW DEFAULT. * Support for a new __sdcccall(1) calling convention in the gbz80 port AS NEW DEFAULT. * Support for a new __sdcccall(1) calling convention in the z80, z80n and z180 ports AS NEW DEFAULT. * Support for a new __sdcccall(1) calling convention in the r2k, r2ka, r3k, tlcs90 and ez80_z80 ports. * Removed support for --profile for gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends. * The z80n port Z80N Core minimum version has been raised from 1.0 to 2.0. * Improved rematerialization support in the stm8, gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends. * The gbz80 port was renamed to sm83. * New in-development mos6502 port. Philipp (SDCC 4.2.0 release manager)

SDCC has gone ahead with this. In the upcoming SDCC 4.2.0, the default ABI uses register arguments.

Banking support for Z80 has improved recently in SDCC, so a current SDCC (the compiler) should do okay for the megacart. I don't know about the linker situation, though.

Do you have the Cygwin package libMagick-devel installed?

I'll try to look into it when I find time. When I wrote the tutorial, MagickWand was not required (png2cv up to 0.17 used libpng instead), and I forgot to update it for the png2cv 0.18. You could try to use older png2cv 0.17, which doesn't require MagickWand. It should work just as well as current png2cv 0.18 for ColecoVision, Sega SG-1000 and SC-3000 development (but lacks some features for improved Sega Mark III and Master system support).

Some Emulators have support for debugging at the assembler level, via an integrated disassembler. However, many programmers write their programs in C, and being able to have symbolic debugging would help with program development. We can't have that on the hardware (the ColecoVision hardware doesn't support it), but we could have it in emulators. Being able to set breakpoints in C code, or quickly see the content of variables would be helpful. I think it could be possible to create an interface for GDB, the GNU debugger, in an emulator. But I'm not an emulator author (apart from an experimental ColecoVision emulator that I wrote long ago, and that worked for some ColecoVision games only), so someone else would have to do that. What I think I could do, however, is to make the z80 backend in SDCC emit ELF binaries with DWARF debug info, suitable for use with GDB.

I've always been using objcopy from GNU bintuils, not the variant that comes with SDCC. I guess the latter has support for some additional feature relevant to some uses of SDCC (maybe handling debug info for MCS-51?), but for the simple task of converting a .ihx to a .bin either should do.

The new release is ready (and tested to work with both SDCC older and newer than 4.1.12): http://www.colecovision.eu/ColecoVision/development/libcv.shtml

I see the problem (an incompability with some SDCC versions), and will prepare another release to fix it. In the meantime, the previous version (http://www.colecovision.eu/ColecoVision/development/libcv-0.26.tar.gz) should work with your SDCC 4.1.0.

SDCC is a C compiler. You need it to compile C source code into ROMs for the ColecoVision. The colecovision library (libcv) is a C libraries that allow you to access the ColecoVision hardware from your C code. libcvu provides a few convenient helper functions as a slightly higher-level interface above what libcv provides. For the tutorial, you need them all. The tutorial indeed uses make (which is commonly used on GNU/Linux and other Unices). On Windows, you can get make via cygwin, as shown in the tutorial you linked.

I just found Bitsy, which AFAIK, hasn't been mentioned here yet. It is meant to make it very easy (should even be suitable for children once they can read and write) to create simple games: https://bitsy.org/ There are a few sample games on the Website. Usually, Bitsy is used to create Browser games, but there also is a tool to compile Bitsy to C source for the ColecoVision: https://github.com/haroldo-ok/bitsy-converter

What error message did you get building on Cygwin? I do most of my development on Debian GNU/Linux, not every release gets tested with Cygwin. I've attached a precompiled version, built with SDCC 4.1.12. Warning: On "make" (by default, i.e. no EXTRACFLAGS set), the library is built for the SDCC version installed. Then, a library built with SDCC older than 4.1.12 will not work when linked to games compiled with SDCC 4.1.12 or later or vice versa. libcv-0.27-prebuilt.tar.gz

Today, I released another update: libcv 0.27 / libcvu 0.20. http://www.colecovision.eu/ColecoVision/development/libcv.shtml The main goal of this new version is compability with newer SDCC. It is meant for use with 4.0.0 and later; unlike the previous release, it also works with SDCC 4.1.12 and later. Some functions hand-written in asm for performance long ago have been reverted to C code, since SDCC now generates code as good as the hand-written asm for them.

Today I released a new version of my cross-platform libraries libcv and libcvu, and also a new version of png2cv. The libraries and tools are designed to make it easy to target multiple Z80-based platforms in a game. They originally started out as tools for ColecoVision development, but now also support the Sega 8-Bit systems. Typically, games written for ColecoVision will just work on the Sega 8-Bit systems, except for input (Sega doesn't have the keypad), and games written for Sega SG-1000 will just work on the ColecoVision and the other Sega 8-Bit systems. Using the full power of the more advanced systems, like the Sega Master system, usually takes a bit more effort. But I have written cross-platform games that do so (when run on a Mark III or Master System they use slightly better graphics than when run on a ColecoVision or SG-1000). http://www.colecovision.eu/ColecoVision/development/libcv.shtml Included in the libcv / libcuv tarball are eight simple demo programs, that show how this cross-platform support works. From a single source, both a ColecoVision version and a Sega version is compiled. This release is meant for use with SDCC 4.0.0 to SDCC 4.1.11. Except for two of the demos, everything should also work with the older SDCC 3.9.0. SDCC 4.1.12 and newer will be supported by a future libcv / libcvu release.

I haven't released them on cartridge yet. But my libcv / libcvu library is designed to make it easy to target both the ColecoVision, SG1000 and SMS/MarkIII in a game. ColecoVision vs. the others are compiled from the same source, with different #ifdefed codepaths. in just a few places. SG1000 vs SMS/MarkIII can even be changed at runtime (one can e.g. detect the system on which the game is running, and use the additional graphics capabilities of the SMS/Mark III, if available). I did this for some of my ColecoVision games, and submitted some of them to coding competitions at smspower.org.