Jump to content

PkK

Members
  • Posts

    509
  • Joined

  • Last visited

1 Follower

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Europe

Recent Profile Visitors

14,916 profile views

PkK's Achievements

Dragonstomper

Dragonstomper (6/9)

157

Reputation

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