Jump to content

PkK

Members
  • Content Count

    470
  • Joined

  • Last visited

Community Reputation

123 Excellent

About PkK

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Europe
  1. 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.
  2. 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
  3. 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
  4. 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.
  5. 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
  6. FOSDEM talks are recorded an uploaded to https://video.fosdem.org/, e.g. my 2015 talk on SDCC. Philipp
  7. 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
  8. Most of my games are still available on cartridges: http://www.colecovision.eu/buy.shtml Philipp
  9. 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
  10. A deal about the right to call the ColecoVision flashback "ColecoVision flashback" I guess? Philipp
  11. 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
  12. Would the US trademark even affect you, since you are based in Canada? Philipp
  13. 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
  14. I don't think they did. Or if they did, they didn't get a trademark. Philipp
  15. Compression (RLE and Huffman) is used for graphics data (tiles and sprites). I even have my own Megacart pcb design that I could use (and intend to use for some future projects). But Io was meant to be a 32K game, and I don't want to change that now. I've recently made a few improvements in SDCC to bring Io code size down a bit (SDCC now generates better code for switch statements and some comparisons). I'll see how much I can fit into Io in the summer. One option I'm currently considering is handling it similar to what I did in SCJ3. * Additional levels (with the second graphics set for Io). * Some sound (I'm not that good at sound, so these will rather be very short music sequences corresponding to what happens in game) * Longer Music for the level won / lost / intro screen only (so as to not interfere with the music-like in-game sound). This will also keep the total length of the music short (and thus the required ROM space low). Philipp
×
×
  • Create New...