PkK

There would also be a --sdcccall N option to set the default. The final change of default ABI, if it happens would change the default in case of absence of --sdcccall N or __sdccall(N), and set the default for the precompiled standard library.

There has been some work on a change of the ABI in SDCC. It is not yet decided if the change will go ahead. Basically, such a change would break existing asm code (as the way parameters and return values are passed)¹, but would give an improvement in code size and speed. In particular, the new ABI would pass some parameters in registers, would pass the return values in different registers, and for some function the cleanup of stack parameters would be done by the callee instead of the caller. More details can be found in the SDCC feature request: https://sourceforge.net/p/sdcc/feature-requests/732/ Work is happening the in the breaktheworld branch, where the new ABI is the default, and mostly working (in particular, banked calls, i.e. for the ColecoVision using a Megacart is not yet working there). ¹ There is a way to mark individual functions as using the old ABI via __sdcccall(0) to continue using existing asm functions from C code compiled for the new convention.

If you want code (as opposed to data) in banks, AFAIK the current state of the Z80 backend in SDCC is insufficient. No matter which hardware you use (my Megacart, other Megacarts, Sega Master System Mappers, Z180, eZ80, etc). I'll have to look at it to see how much needs to be done to get it fully working. AFAIK some people still use it (e.g. Alan Cox for FUZIX), but they modified the linker, as the linker as it comes with SDCC was not sufficient for them.

If you don't want to use separate banks for code and data, even with the 4K banks, you could just configure the two adjacent 4K banks as a single 8K bank. With the new firmware you also have the option of configuring two adjacent 8K banks as a single 16Kbank. So we have (among others) the following options: 1) A 24K fixed area followed by a 4K switched area and another 4K switched area. 1a) Use this as a fixed 24K area followed by a 8K switched area. 1b) Use this as a fixed 28K area followed by a 4K switched area. 2) A 16K fixed area followed by an 8K switched area and another 8K switched area. 2a) Use this as a fixed 16K area followed by a 16K switched area. 2b) Use this as a fixed 24K area followed by a 8K switched area. For my own projects, I intend to use 1), but the hard- and firmware is quite flexible.

Support for bank switching for code in banks in SDCC is still incomplete. For data in banks it works using named address spaces from the Embedded C standard (see section 3.5.5, "Non-intrinsic named address spaces" in the SDCC manual).

Finally found a bit of time today for this. The new firmware works fine and I'll use it as default. So bank size can now be switched between 4KB and 8KB at runtime.

Sorry for the noise, I guess I misread the table.

Well, while I have working prototypes, there might still be changes. In particular, today, I worked on the limited support for different bank sizes in the default firmware. See the updated README for details. However, I have not yet tested this new firmware version in hardware. But if it works well, I might just make this the new default firmware, as it still provides all the functionality of the old version. README

Bankswitching works by writing specific addresses. The 4K bank size is a choice I made, since I assume it to work well with my coding style (have 1 large 24K non-switched are for common code, 1 switched area for level data, 1 switched are for level-specific code). When one wants one switched 8K bank, one could just set the two adjacent areas in logical memory to adjacent areas in physical memory. But all this is not a hardware limitation: With a different firmware on the CPLD one could use a different bank size. Originally, I wanted to have the bank-size configurable at run-time, like CBAR in the Z180 MMU, but my original design was too much for the XC9536XL CPLD used. And the bigger XC9572XL is much more expensive. I'll probably revisit that to see if maybe I can fit a somewhat restricted variant of configurable bank size into the XC9536XL, as there are still some unused CPLD resources left when using the current firmware. I've attached my current documentation draft. README

The cart color of Schlange CV 1.0 is stated as black in that document, but it actually is red. Also, Bankruptcy Builder comes with overlays for the controllers. I'd suggest to add text explaining the column headers, especially those that are only a single character. The length of that list is quite impressive. How about adding a column for multiplayer mode (non-existent vs. taking turns vs. simultaneous)?

The flash chip is socketed, not soldered, and can be removed from the board using PLCC pliers.

For a long time, I wanted to make a Megacart, but often, I found very little time for ColecoVision development. Today, I finally did a sucessfull basic test of some Megacart prototypes I soldered yesterday. Spec: * Up to 512 KB of memory-mapped Flash, via bankswitching. * Fixed 24 KB memory area, two switchable areas of 4 KB each (different configurations would be possible with different firmware in the CPLD). * 64 KB of EEPROM for savegames (not memory-mapped, slow serial access). * Fits into the short cartridge cases I use for the Homebrew kit (http://www.colecovision.eu/ColecoVision/development/Homebrew kit.shtml) Today's test: * Used both AT49F040A and SST39SF040 512 KB Flash chips * Switched bank two two different parts of the Flash, checked that the expected, different values were read from fixed address. * Wrote a byte into EEPROM and read it back. Originally, I started working on my Megacart design for a T&T game, but I don't think I'll be able to find the time to finish that game anytime soon.

Also, there currently is a survey on use of various SDCC backends: https://terminplaner4.dfn.de/xudoK5vzYi3oIX6O If you would like to see support in SDCC for a device not yet supported or if you use the mcs51 backend for a device that has support for dual dptr, please state so (and which device it is) in a comment.

Dear SDCC users, Today the first Release Candidate (RC1) for SDCC 3.9.0 has been created. As always it has been put online in our SourceForge File section. https://sourceforge.net/projects/sdcc/files/ If you have the time, please verify it and report back with the positive or negative results. There have been various improvements, both features and bug fixes since SDCC 3.8.0. The full ChangeLog is at https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLog. The following is a list of particularly noticeable new features. * Support for struct / union assignment. * Optimizations in the stm8 backend relevant to soft float increase Whetstone score by two thirds. * Improvements in rematerialization in the stm8 backend improve code generation for struct, union and arrays. * New stack allocator reduces stack space usage for the stm8, z80, z180, gbz80, r2k, r3ka, tlcs90 backends. * New ez80_z80 backend for eZ80 in Z80 mode. * Removed deprecated sdcclib utility. * New pdk14 backend for Padauk µC with 14-bit wide program memory. * New in-development pdk15 backend for Padauk µC with 15-bit wide program memory. Philipp Klaus Krause SDCC 3.9.0 Release Manager

Today, I have released libcvu 0.17 (http://www.colecovision.eu/ColecoVision/development/libcv.shtml). * Minor efficiency improvement in cvu_get_sprite_x(). * Fix behaviour of cvu_get_sprite_y() for sprites off the upper edge of the screen. * Fix cvu_memcpy_compression() return value. * Fixed incorrect use of restrict on function pointer in cvu_init_huffman(), cvu_init_rle() and cvu_init_lzk(). The last fix was the main motivation, to ensure that the current libcv/libcvu works well with current SDCC. Philipp

Dear SDCC users among the ColecoVision programmers, today the first Release Candidate (RC1) for SDCC 3.8.0 has been created. As always it has been put online in our SourceForge File section. https://sourceforge.net/projects/sdcc/files/ If you have the time, please verify it and report back with the positive or negative results. In previous release 3.7.0, no binaries were released. 3.8.0 has binaries gain, though the list of binary platforms changed. For 3.8.0, binaries are released for GNU/Linux on amd64, Windows on amd64, macOS on amd64, Windows on x86. However: Unlike previous binary releases, the windwos installer have not been checked by the Release Manager (my only machine with a Windows installed needs a new poer supply, which hasn't arrived yet). There have been various of improvements, both features and bug fixes since SDCC 3.7.0. The full ChangeLog is at https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.8.0-pre1/sdcc/ChangeLog. The following is a list of particularly noticeable new features. * Additional general utility function: bsearch() * Support for rematerialization in the stm8 backend reduces register pressure and stack usage * Merged upstream GNU binutils 2.30 * All Python code is now fully compatible with both Python 2.7 and Python 3.6, so Python 3 can be used instead of Python 2. * Regression testing for diagnostics. * Improved handling of local bool variables in the mcs51 backend substantially reduces code size. * Large memory model for stm8 for 24-bit codespace allows using more than 32KB of Flash for code. * New optimizations for calls to some standard library function (printf(), puts(), strcpy()). * The type of true and false from stdbool.h change from int to bool. * New C2X mode (--std-c2x, --std-sdcc2x, #pragma std_c2x) adds support for one-argument static_assert variant. * Intermingling of declarations and statements (ISO C99). * Support headers for AX8052 devices. * Adopted GCC 8.2 regression tests (execute part of the GCC C torture tests). Philipp Klaus Krause SDCC 3.8.0 Release Manager P.S.: Apart from the improvements in stadnard compliance, there is now "big" new feature relevant to ColecoVision programming. But there some smaller improvments in code generation for the Z80 and many bugfixes. P.P.S.: This version is a bit more strict about use of the "restrict" keyword than the previous one; I have already made the necessary fix in libcvu for it to work with this SDCC, and will release a new libcvu version soon.

Slides and a video of the talk can now be found at: https://fosdem.org/2018/schedule/event/fame_development_colecovision_sega_8bit_systems/ Philipp

FOSDEM talks are recorded an uploaded to https://video.fosdem.org/, e.g. my 2015 talk on SDCC. Philipp

At FOSDEM 2018, there will be a talk on "Game development for the ColecoVision and Sega 8-bit systems". The talk will be 2018-02-04 15:50 in room AW1.121 at the Université libre de Bruxelles. Naturally, part of the talk will be about SDCC and its z80 backend, as well as about the libcv/libcvu libraries. The libraries were originally written for the ColecoVision, but evolved into something that now allow easy development of games portable between the ColecoVision and the Sega 8-bit systems. The talk is just 30 minutes so it will have to be more of an overview than an in-depth talk.I will also be around for discussions during that weekend. More details on the talk can be found at: https://fosdem.org/2018/schedule/event/fame_development_colecovision_sega_8bit_systems/ Philipp

Most of my games are still available on cartridges: http://www.colecovision.eu/buy.shtml Philipp

It has been a while, but I decided to release new versions today, so everyone can profit from all teh small improvements that accumulated over time. libcv / libcvu changes: Suggested compiler: SDCC 3.6.0 or newer libcv: Basic SMS port demos: Basic SMS port libcv: Specify preserved registers for asm-implemented functions. libcv: Optimize return address handling in cv_vmemset_fast(), cv_vmemset_slow(). libcvu: Specify preserved registers for asm-implemented functions. libcvu: Replaced some macros by inline functions. demos: Add machine detection demo. libcv: Add delay to cv_voutb(), cv_vinb() to always meet graphics chip timings. libcv: Improve cv_vmemtomemcpy_slow() speed. libcv: cv_get_r() to get the contents of the Z80 refresh register r. libcv: Fixes in support for super action controller spinners and roller controller. demos: Fix cursorsmooth demo for roller controller. png2cvs changes: Updated to automake 1.15.1 Update for libpng 1.6 (vs. old 1.2) Improved error messages. png2cv changes: Fixed autotools stuff. Update for libpng 1.6 (vs. old 1.2). Fix missing include. Improved error messages. compression utilitites changes: Fix for machines with CHAR_BIT > 8. Added --help to display simple usage info for huffman_analyzer and huffman_encoder. Added -o to specify output filename for huffman_analyzer and huffman_encoder. I guess the highlight is the support for developing games portable across the ColecoVision and the Sega 8-bit systems. It has be come quite easy to write source code that canbe compiled into a game that works on ColecoVision / SG-1000 / Mark III / Master System. Philipp

A deal about the right to call the ColecoVision flashback "ColecoVision flashback" I guess? Philipp

So far, this problem seems to be restricted to Facebook. I'm not on Facebook, so I might underestimate the importance of Facebook pages to some people. But I guess other sites such as YouTube have different policies which might make it a bit harder to take content down. And taking down a real website would probably be much, much harder than that (I know http://opcodegames.com/is down, but that apparently was a decision on ocodes's side). Philipp

Would the US trademark even affect you, since you are based in Canada? Philipp

The level data is only about 2 bits per tile. So there is not much potential for furhter reduction. Those about 2 bits are needed (the levels should not be fully random - I want lower or higher probabilitires of rocks in some places, want to make sure the sulphur nodes are distributed fairly, etc. Otherwise, Io already uses pseudo-randomness for the levels (via C rand()) to e.g. decide which of the 8 different-looking empty ground tiles is used for a given location. Philipp