Jump to content
IGNORED

My ColecoVision devkit - August 2011 News


newcoleco

Recommended Posts

For those who wanted news from me, this is part of the news...

 

Hello,

 

It's been a while I've really coded ColecoVision stuff... difficult to go back coding but I did.

 

Reccently, I've not only uploaded my ColecoVision devkit source code to a SVN server, but also I'm experimenting to add back SuperAction controllers support. Why this support was removed in the first place? because I wanted to save previous cpu time and bytes in the ROM file needed to catch the spinner ticks and decode the 3rd and 4th fire buttons.

 

Dale Wick is hosting the SVN server at adamcon.org and he will confirm if the modified version works with a SuperAction project of his own in a playable alpha state I will say... that he plans to show me this saturday (August 27, 2011) at the CCJVQ meeting. Luc Miron (Pixelboy) will be at this meeting too selling ColecoVision homebrew games and answering questions... a kind of Coleco party in perspective!

 

While back into the devkit codes, I've cleaned up a little bit the source code and modified at least one thing : screen_mode_2_text() and screen_mode_2_bitmap() no more set screen ON by default (Why? because programmers including me tend to update the VRAM (Video RAM) right after calling these methods and it's a bad idea to massively update VRAM while the screen is ON).

 

Homebrewers ColecoVision who are using this devkit you have 2 options from (not) now : accessing the SVN server (as a guest or even an official contributor), or waiting my Coleco web site to update.

Link to comment
Share on other sites

Ok, I've just seen a potential disaster which involve my devkit and CCI2.

 

The generated ROM file when compiling with a not proper CCI2.EXE (which is the case if you've downloaded my devkit during the last year or so) generates an empty zone filled with zeros from $8021 to $8047 which means that every time the NMI is executed, a bunch of NOP instructions is executed before the real NMI function, slowing down artificailly the execution of your codes.

 

I'm fixing that by adding a jump call in CRTCV.S file, the case of the improper CCI2 will not be resolved anytime soon I'm afraid. In fact, I'm planning to program CCI3 which will not only resolve this issue but allow using the full potential of the SDCC compiler and a little bonus if I've time.

 

So, if you are reading this message and still using my devkit dated year 2010 with an improper CCI2.EXE program, you should immediatly check my Coleco web site to download an updated version (build # should start by 2011) that will at least fix this issue.

 

It's because of stupid errors like that that my devkit version is still beta.

Edited by newcoleco
Link to comment
Share on other sites

  • 10 months later...

New version compiled this july 2012. Visit my web site

 

http://www.ccjvq.com/newcoleco

 

What's new?

  1. Improved in size coleco and getput libraries
  2. Updated CCI3 = Added Compile All button and use oldralloc flag by default if no "max nodes" option selected
  3. Added lib4ksa library = lib4k with superaction controller support 3rd and 4th fire buttons and spinners support covering the spinner on SuperAction controllers, Driving Module (sterring wheel) and Roller Controller (Trackball).

With the new CCI3, it's now faster to compile a project for prototyping, but when it comes to compile a final version, better use max nodes set at maximum (slow) in order to get the very best improvements.

The idea of using a seperate library for projects that need spinner support and 3rd and 4th fire buttons support is to avoid unnecessary codes in regular projects.

Improvement in size for some routines in coleco library and a little bit also in getput saving a couple of bytes.

 

Preliminary tests confirms that Compile All button on the new CCI3 is working fine, the improved libraries are working nicely and reduce rom size for a couple of bytes, and the new SDCC version help to save around 100-200 more bytes. SDCC is still very slow for me, taking 3 hours to compile DACMAN (a 24K project) with it, but the "oldralloc" option set by default when no max nodes is specified compiles in less than 5 seconds.

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

Well I've switched now to using SDCC 3.2.0 and so far I'm liking it. The CCI3 option to include optimizations seems to me like it defaults to too many optimization nodes (30000 I think). I tried it at about 12000 and still the compile is pretty slow, but it at least produces good results.

 

The new SDCC (I was using 2.9.7 previously) as expected, has different bugs. I guess now that I'm more up to date I should create some test cases for my problems. They all centre around my heavy use of unsigned char for a wide variety of calculations. Changing the type to int however caused most of those bugs to disappear. So there you go.

 

I have not yet got useful results out of hitting the Compile All button in CCI3 (which was a feature request that I made to Daniel). I'm not sure if I'm not patient enough or if it's a problem with the button.

 

Overall good work though Daniel on the latest version of the Coleco and getput libraries.

Edited by hardhat
Link to comment
Share on other sites

Well I've switched now to using SDCC 3.2.0 and so far I'm liking it. The CCI3 option to include optimizations seems to me like it defaults to too many optimization nodes (30000 I think). I tried it at about 12000 and still the compile is pretty slow, but it at least produces good results.

 

This depends both on personal preferences and on the nature of the program compiled. I've compiled some things at --max-allocs-per-node 100000000 in the past. I also intend to make some improvements to the way sdcc generates tree-decompositions this or next year, which should also improve the code quality / compilation speed trade-off.

 

The new SDCC (I was using 2.9.7 previously) as expected, has different bugs. I guess now that I'm more up to date I should create some test cases for my problems. They all centre around my heavy use of unsigned char for a wide variety of calculations. Changing the type to int however caused most of those bugs to disappear. So there you go.

 

Please create testcases, and file bugs at sdcc's sourceforge bug tracker for the issues you find.

 

However, them being related to unsigned char seems a bit odd to me, since I also use this data type heavily (mostly in the form of uint_fast8_t), so it should be well-tested. I'd expect the less-used data types, such as float or long long to be more problematic.

 

Philipp

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...