PkK
-
Content Count
480 -
Joined
-
Last visited
Posts posted by PkK
-
-
On 1/4/2020 at 10:26 AM, alekmaul said:Nice, I think 8KB is better than 4KB, because it is easier to have gfxs & code in the same bank (very practical with other megacart PCB)
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.
-
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).
-
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.
-
1
-
-
On 12/13/2019 at 10:31 PM, Ikrananka said:I do show hand controller overlays for Bankruptcy Builder
Sorry for the noise, I guess I misread the table.
-
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.
-
1
-
-
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.
-
On 1/25/2019 at 6:24 PM, Ikrananka said:I have been updating NIADs Collectors List and in particular the homebrew section. Attached is my current work in progress for your info. Be aware that this may contain errors but as far as I know is the most comprehensive, up to date, list currently available. Note that it does not yet contain any 2019 releases, such as Fireworks Factory.
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)?
-
The flash chip is socketed, not soldered, and can be removed from the board using PLCC pliers.
-
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.
-
3
-
-
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. -
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-
4
-
-
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
-
3
-
-
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 ManagerP.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.
-
3
-
-
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 -
FOSDEM talks are recorded an uploaded to
https://video.fosdem.org/, e.g. my 2015 talk on SDCC.
Philipp -
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 -
Hi sorry to ask but were your games ever released on Roms so that people who were not in the scene at the time these came out can still play them today?
Most of my games are still available on cartridges:
http://www.colecovision.eu/buy.shtml
Philipp
-
1
-
-
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
-
2
-
-
Without software intellectual property (eg. games), I don't think the Coleco brand is worth anything. I don't know what kind of deal they made with AT Games if they have no software IP.
A deal about the right to call the ColecoVision flashback "ColecoVision flashback" I guess?
Philipp
-
1
-
-
[…] all homebrewers, fan sites, podcast owners, YouTube channels, etc, SHOULD be at least a bit worried that at any given moment, the same could happen to them.
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
-
If need to be, I might recycle myself as a MSX developer, or go back toying with the devkit for DS and PSP games, or even Android.
... will not have the same deep connection as with my first videogame system (special place in my heart), but I think I will survive.
Would the US trademark even affect you, since you are based in Canada?
Philipp
-
Just a weird thought. but what about double using the graphic data as music data.
The background starts as terrain which you had to store anyways
Make the music data, store it in what ever format you use. Then use that music data to generate random terrain for each level perhaps with a random start point to read from.
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
-
The issue is that they also filed for the Trademark in the EU
I don't think they did. Or if they did, they didn't get a trademark.
Philipp
-
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Another working Megacart
in ColecoVision Programming
Posted
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.