Updated versions of ColecoVision programming tools

[PkK]

Following the release of sdcc 3.1.0 a few weeks ago I have released

updated versions of my programming tools for the ColecoVision and

updated the Tutorial at

http://colecovision....tutorial0.shtml to

ensure that it works with current Versions of Windows, Cygwin, sdcc and

my tools.

 

As usual, everything can be found at

http://colecovision....on/development/

 

List of Changes (excluding tutorial):

 

libcv/libcvu (the libraries):

 

0.20 / 0.13:

Suggested compiler: sdcc 3.1.0 or newer

libcvu: Moved tunings to separate files.

libcv: Removed obsolete inb.s and outb.s.

libcvu: Fixed Makefile bug that prevented scientific equal tuning from

being built.

demos: Fixed music demo Makefile that still used .o instead of .rel in

some places.

Added MAX_ALLOCS_PER_NODE parameter in build system.

libcvu: Qualify some more pointers as restrict.

libcv: Slightly more efficient usage of bool in

cv_set_sprite_magnification() and cv_set_external_video().

Made build system more flexible to work better with nonstandard tool paths.

demos: Cleanup *.lk in stars demo.

 

png2cv (a tool to create ColecoVision graphics from png images):

 

0.14:

-Fixed include of stdint.h.

-Use PKG_CHECK_MODULES for libpng12 and to build reliably on Cygwin.

-Removed obsolete RLE support thorugh --rle option.

-Removed leftover --black option in usage message output.

 

png2cvs (a tool to create ColecoVision sprites from png images):

 

0.6:

-Fixed missing array dimension on non-binary mode.

-Use PKG_CHECK_MODULES to for libpng12 and to build reliably on Cygwin.

 

abc2cvm (a tool to create music for use with libcvu from abc files):

 

0.12:

-Added error message for out-of-range pitch.

-Added missing auxiliary configuration files.

 

Philipp

 

P.S.: If you have any feed back or encounter any bugs or usability

problems, please let me know.

[Pixelboy]

Thanks for all your efforts, Philipp!

[youki]

Hi Philip ,

 

Thanks for all your work.

 

I have a paranormal bug with SDCC (i use old version , but tested the one from last week the problem is the same). Unfortunaly it is so paranormal that it is hard to explain and impossible to reproduce outside my context.

 

i have a an array that is more or less an predefined array of pointer in rom.

 

 

const void* test_map[5][5] =

{

{screen1,screen2,0,0,0},

{screen2,screen3,screen3,0,0},

{0,0,0,0,0},

{0,0,0,0,0},

{0,0,0,0,0},

};

 

And currently if you look all value of the pointers in the second column (and only that one!) , all are "OR"ed with 0xFF .

 

Let say the value of screen2 is : 0x83DB , if you read : test_map[0][1] , you got : 0x83FF (0x83DB OR 0xFF )

 

if in this example you read test_map[3][1] , you got 0xFF , instead of 0.

 

And what is weird , is that if for instance , you defined a 2nd array that is EXACTLY the same than the first to have something like :

 

 

const void* test_map[5][5] =

{

{screen1,screen2,0,0,0},

{screen2,screen3,screen3,0,0},

{0,0,0,0,0},

{0,0,0,0,0},

{0,0,0,0,0},

};

 

 

const void* test_map2[5][5] =

{

{screen1,screen2,0,0,0},

{screen2,screen3,screen3,0,0},

{0,0,0,0,0},

{0,0,0,0,0},

{0,0,0,0,0},

};

 

and if you read the same values in test_map2 , the results are correct!!!!

 

Then if you remove test_map (the first one) ... and read again test_map2 , now the results get wrong!!

 

Very strange, and seems very contextual.

 

So for now i have found a workaround because anyway i don't think i will use a newest version of SDCC for my current project.

 

 

A side that , Can we found somewhere a version of PNG2CVS already compiled for windows? i would need it, but don't want install cygwin and etc.. to compile it.

 

Thanks.

[PkK]

[…]

Very strange, and seems very contextual.

I've tried to reproduce the issue, but couldn't (unsurprisingly, since you said it was context-dependant). My only guess at the moment is that maybe you're running out of RAM. There's only 1K in the ColecoVision, at the array needs 50 bytes. If there's lots of other things in RAM, maybe the stack is overwriting your global variables? What does your .map file state about the size of your _DATA area?

A side that , Can we found somewhere a version of PNG2CVS already compiled for windows?

Not yet.

i would need it, but don't want install cygwin and etc.. to compile it.

Thanks.

It shouldn't be hard to compile using a C compiler for Windows, such as MSVC or mingw, the only external dependency is libpng12, which can be found compiled for windows e.g. at http://gnuwin32.sourceforge.net/packages/libpng.htm

 

Philipp

[youki]

the Size of the _DATA area is 422 bytes.

 

But why this array goes in RAM ?, i would expect it goes in ROM.

 

how to make it goes in ROM?

 

screen1 , screen2, screen3 etc... are well in ROM.

 

 

the array contains only pointers to ROM. And its content is fixed and won't change.

 

Here how it is defined.

 

 

const byte screen1[size_MAP_Y][size_MAP_X] = {
{1,1,1,1,1,1,1,1},
{2,5,5,5,5,5,5,5},
{1,1,1,8,1,1,4,1},
{6,6,6,8,1,1,4,1},
{5,5,5,5,5,5,5,2},
{2,2,2,7,2,2,2,2}
};



const byte screen2[size_MAP_Y][size_MAP_X] = {
{9,10,3,3,3,11,3,3},
{1,1,1,1,1,1,3,3},
{3,3,3,3,3,3,3,3},
{1,12,12,12,12,12,7,6},
{1,13,13,13,13,13,7,6},
{2,2,2,2,2,2,2,2}
};

const byte screen3[size_MAP_Y][size_MAP_X] = {
{3,3,3,3,3,3,3,3},
{3,3,3,3,18,3,3,3},
{3,3,3,15,2,16,14,3},
{3,3,3,15,3,3,14,3},
{3,3,3,3,3,3,14,3},
{2,2,16,16,17,17,2,2}
};



const void* test_map[WORLD_SIZE_Y][WORLD_SIZE_X] =
{
{screen1,screen2,0,0,0},
{screen2,screen3,screen3,0,0},
{0,0,0,0,0},
{0,0,0,0,0},
{0,0,0,0,0},

};

 

Thanks.

[PkK]

the Size of the _DATA area is 422 bytes.

 

But why this array goes in RAM ?, i would expect it goes in ROM.

 

how to make it goes in ROM?

Make it const.

 

screen1 , screen2, screen3 etc... are well in ROM.

 

 

the array contains only pointers to ROM. And its content is fixed and won't change.

The compiler doesn't know that without const:

 

const void* test_map[WORLD_SIZE_Y][WORLD_SIZE_X];

 

Is an array of pointers to const void*. It will be placed in RAM.

 

void* const test_map[WORLD_SIZE_Y][WORLD_SIZE_X];

 

Is a const array of pointers to void*. It will be placed in ROM.

 

const void* const test_map[WORLD_SIZE_Y][WORLD_SIZE_X];

 

Is a const array of pointers to const void*. It will be placed in ROM. And I believe this is what you want here.

 

Philipp

[youki]

Thanks a lot!!

 

const void* const test_map[WORLD_SIZE_Y][WORLD_SIZE_X];

 

It is what i need!.

 

Using that my previous problem is gone . But some others strange things appeared. i have to dig in. But again thanks a lot for your help!

[youki]

More information about the strange things that i have.

 

I have the feeling that there is problem when something is in RAM somewhere between 0x706F and 0x70A1.

 

My test_map was (before i put it in ROM) allocated between 0x706F and 0x70A1.

 

Now since i put the test_map in rom , i have another array that is now allocated between 0x7073 and 0x70A5 , and now this array have suddenly problems. (previously , before i move the test_map to rom, it was allocated between 0x70A5 and 0x70D7 , and i had no problem with that one)

[PkK]

More information about the strange things that i have.

 

I have the feeling that there is problem when something is in RAM somewhere between 0x706F and 0x70A1.

 

My test_map was (before i put it in ROM) allocated between 0x706F and 0x70A1.

 

Now since i put the test_map in rom , i have another array that is now allocated between 0x7073 and 0x70A5 , and now this array have suddenly problems. (previously , before i move the test_map to rom, it was allocated between 0x70A5 and 0x70D7 , and i had no problem with that one)

 

You're probably overwriting that memory unintentionally from some other part of your program. Maybe a buffer overflow or writing via an unitialized pointer.

 

Philipp