Jump to content

PkK

Members
  • Content Count

    480
  • Joined

  • Last visited

Community Reputation

129 Excellent

1 Follower

About PkK

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Europe

Recent Profile Visitors

14,276 profile views
  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. Sorry for the noise, I guess I misread the table.
  6. 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
  7. 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
  8. 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)?
  9. The flash chip is socketed, not soldered, and can be removed from the board using PLCC pliers.
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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.
  15. 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
×
×
  • Create New...