Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by PkK

  1. 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.
  2. 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.
  3. 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.
  4. SDCC 4.2.0 has bee released today.
  5. 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/
  6. 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).
  7. 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.
  8. 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)
  9. SDCC has gone ahead with this. In the upcoming SDCC 4.2.0, the default ABI uses register arguments.
  10. 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.
  11. Do you have the Cygwin package libMagick-devel installed?
  12. 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).
  13. 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.
  14. 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.
  15. 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
  16. 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.
  17. 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.
  18. 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
  19. 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
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  • Create New...