PkK
Members-
Content Count
480 -
Joined
-
Last visited
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by PkK
-
At FOSDEM 2015, there was a talk on SDCC: https://archive.fosdem.org/2015/schedule/event/8bit_compiler/ there is also a blog post on what happened in SDCC since the talk up to the SDCC 3.6.0 release: http://www.embecosm.com/2016/06/14/recent-updates-to-sdcc-in-release-3-6-0/ Philipp
-
Since a few hours, there is SDCC 3.6.0: Most relevant for ColecoVision programmers are probably the improved standard support and various bugfixes in the Z80 backend. Philipp
-
I recommend the tutorials at http://colecovision.eu/ColecoVision/development/tutorial0.shtml Philipp
-
We could really use a playmusic command for c language - hint hint
PkK replied to digress's topic in ColecoVision Programming
Are you aware of the facilities in libcvu and of abc2cvm? See http://colecovision.eu/ColecoVision/development/tutorial2.shtml Another example from a libcvu demo is attached. Philipp 12duets.pdf Music.rom -
I compile using the usual ./configure make installation as root via make install Philipp
-
png2cv is a tool that creates ColecoVision characters for bitmap mode from .png images. 0.16 NEWS: -Fixed help message option text. -Renamed --monochrome option to --bitmap-text. -Added --bitmap option. -Added support for SMS mode 4. -Fixed RGBA support. Donwload from: http://colecovision.eu/ColecoVision/development/png2cv.shtml The improvements for ColecoVision development are minor, but it is a step towards a unified envrionment for writing ColecoVision / SegaMasterSystem games. The new support for mode 4 is still rather basic. In particular it always assumes the TMS9918A palette. Philipp
-
Schlange CV has red carts. Philipp
-
OK. Philipp
-
Yellow lightning symbol in the upper right. Philipp
-
I made a mistake when testing a few days ago. I accidentially had a PLCC32 to DIP32 adapter in my Batronix instead of the PLCC32 to DIP28. Sorry for the confusion. Actually my setup (Batronix BX32P Barlino II with firmware 2.34 and prog-express 3.7.3 on Debian GNU/Linux) works with the SST27SF512 70-3C-NHE. I noticed this today, when I put a 27C256 in the bruner and it didn't work. Then I noticed that I had the wrong adapter installed. When I put in the correct one, both the SST27SF512 and the AT27C256 worked fine. Again, sorry for the confusion. Philipp P.S.: youki, the 27C256 are here now. If you want, I can send them by tomorrow.
-
I was able to contact the otehr person who received Homebrew kits with SST27SF512 70-3C-NHE. They encountered no problems so far, and use a variant of the Willem EPROM burner. Looks like the problem is on the Batronix side. You can still have the 27C256, which should arrive at my place within a few days, maybe already tomorrow. Philipp P.S.: I had a Willem 3.1 before, but replaced it with the Batronix, since the Batronix had better Linux support.
-
Best way/device to test/develop software?
PkK replied to juice2839's topic in ColecoVision Programming
I just burn EPROMs, and put them in a pcb with ZIF socket (essentially the same as the "Homebrew kit CV prototype"). Back when I started writing games, there was no real alternative. And by now, for years I never experienced a problem on real hardware that I could not reproduce in the simulator, so the effort for testing on real hardware is not that much, as I don't have to burn that many EPROMs. I still do quite some testing on hardware, mostly to try the two-player mode with a friend. But when you go to another place for the testing, the relative effort of burning/erasing EPROMs is not that much either. Philipp -
I opened a ticket with them last night, too since we are using slightly different EPROM burners (BX32 vs. BX32P), software versions (3.6.2 vs. 3.7.3) and possibly operating systems. Philipp
-
I was able to reproduce the issue using my BATRONIX BX32P Barlino II with the latest firmware and prog-express on my Debian GNU/Linux system. These PLCC 27SF512 chips came from Farnell earlier this year when I ordered 27C512, as I had run out of PLCC 27C512. At most two people received them in homebrew kits CVs. I do not know yet if there is a problem with the chips or on the BATRONIX side. Since finding out might take time, for now I can offer to replace the PLCC 27SF512 by PLCC 27C256. But with the holidays it might take a bit of time (I just ordered a small number of 27C256 from a supplier other than Farnell). Philipp
-
I'll look into the issue in the next few days, and report back here. Philipp
-
libcv has support for spinners: http://colecovision.eu/ColecoVision/development/libcv.shtml Philipp
-
Did you put the small woodpüieces into their place above the PCB? Philipp
-
The homebrew kits come with either 27C256 or 27C512 EPROMs. These are common EPROM types that should be supported by virtually any EPROM burner and software these days. I'm using a BATRONIX myself. When using 27C256 the whole 32K of the EPROM are visible to the ColecoVision. When using 27C512, the upper half of the 64K EPROM is visible to the ColecoVision. Philipp
-
Though using goto without a need to do so is usually considered bad style. Alternatives for infinite loops: for(;; while(true);
-
It's not clear what you mean by "ending point". What is the desired behaviour? Philipp Edit: Typo.
-
Your code tries to assign 2 | (20 << 3) into LevelStruct.bonus. LevelStruct.bonus cannot hold values that big, so something is lost when converting the constant 2 | (20 << 3) into a 3-bit bitfield. The result is 0. LevelStruct.nbbricks, on the other hand, does not have an initializer, and according to the C standard, is to be initialized to 0. So your code is correct C to initialize both LevelStruct.bonus and LevelStruct.nbbricks to 0. We still give a warning in SDCC, since we consider it quite likely that this is not what was intended by the author of the code. Philipp
-
Normally, the live-ranges should be connected by the time they reach register allocation (non-connected ones should have been split). This problem does not affect correctness of the generated code, but it can force two variables to go to the same register, potentially resulting in slightly less efficient code. Philipp Edit: Two variables that, of course, are not alive at the same time.
-
Most of my tools and libraries fro ColecoVision programmng have received an update. You can find them at http://colecovision.eu/ColecoVision/development/ List of Changes in the current versions: libcv 0.23 / libcvu 0.15: -Suggested compiler: sdcc 3.5.0 or newer -Clarified license as LGPL-2.1 -libcv: Name change of sdcc function pointer call helper. -libcv: Made cv_vinb() and cvu_voutb() inline for speed. -libcvu: Speed up playing of music, elimiate dependency on integer division, fix synchronization of multivoice music when vint frequency is not a multiple of sixteenth_notes_per_second. abc2cvm 0.14: -Renamed configure.in to configure.ac and cleaned up file. -Updated to autotools 1.14.1. compression tools 0.3: -Fixed handling of file open errors. png2cv 0.15: -Fixed help message. -configure.ac cleanup. png2cvs 0.7: -configure.ac cleanup. Philipp
-
SDCC 3.5.0 has just been released. Alan Cox' FUZIX has brought the Z80 suport in 3.4.0 a bit more into the spotlight, resulting in improvements since, which also benefit ColecoVision developers. A recent presentation on SDCC can be found at http://video.fosdem.org/2015/devroom-embedded/8bit_compiler.mp4 See below for the announcement with the list of the most important changes. Philipp -------- Forwarded Message -------- Subject: [sdcc-user] SDCC 3.5.0 Released Date: Wed, 24 Jun 2015 11:55:29 +0200 (CEST) From: Maarten Brock <[email protected]> Reply-To: [email protected] To: [email protected], [email protected] Hello SDCC friends, Today a new release of SDCC was made. We are now at version 3.5.0. You can get it at: http://sourceforge.net/projects/sdcc/files/ So what's new? * --disable-non-free configure option * Changed default language dialect from --std-sdcc89 to --std-sdcc99 * Reorganized and updated manual * Reduced memory consumption (most noticeable for high --max-allocs-per-node) * Faster compilation for stm8 (most noticeable for high --max-allocs-per-node) * atoll() function for conversion of strings to long long * __z88dk_fastcall and __z88dk_callee calling conventions for more efficient function calls and better compability with z88dk * --lospre-unsafe-read renamed to --allow-unsafe-read And of course numerous feature requests and bug fixes are included as well. Once again I hope you will enjoy using this new release. Maarten Brock SDCC 3.5.0 Release Manager
-
Assuming byte is a typedef to unsigned char, all the warnings are right. unsigned char can't hod -1. signed char cannot hold 254 or 175. Philipp
