Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

149 Excellent

1 Follower

About PkK

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

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