Changing Text Color

[Serguei2]

I'm trying to change text color using load_color

 

 

#include <coleco.h>

#include <getput1.h>

void nmi(void) {}

void main(void)

{

vdp_out(0,2);

vdp_out(1,0xe2);

fill_vram0(0x2000,0x1800,0xf0);

upload_default_ascii(NORMAL);

duplicate_pattern();

paper (4);

cls();

/* print_at(X,Y,"Texte");*/

print_at(0,1,"SCREEN #1");

load_color (2);

print_at(0,3,"SCREEN #2");

screen_on();

loop:

goto loop;

}

 

Is there another way to change text color?

[newcoleco]

I'm trying to change text color using load_color

 

 

Is there another way to change text color?

 

The line "fill_vram0(0x2000,0x1800,0xf0);" is to set white color (15 aka F) and default background color (0) for the whole color table at video RAM 0x2000. The number 0x1800 is the size of the color table for Graphic Mode 2 aka Bitmap, which I usually reduce to only 0x800 as a text mode but some emulators don't like that.

 

As for writing a line of text in one color and another line of text in a different color on the same screen :

Because of the way the video chip works (TMS9928), a character has its pattern and color associated. The character number 65, which is the letter A, has its pattern at 0x0000 + 65*8 , and its color at 0x2000 + 65*8. And if you duplicate the pattern A for the character number 97 (which is ASCII number for 'a') but in a different color, that character will look like A but in a different color. And so printing "Aa" will look like "AA" but in different colors.

[Kiwi]

load_color is used to load the uncompressed color table from ROM to VRAM at 0x2000. There is load_colorrle to for rle compressed color table.

 

put_vram(0x2000, Colortable,1024); will do the same thing as load_color();. I usually compress graphic in rle format. Colors usually compress well with RLE. ICVGM have option to export tileset data either in uncompress file or rle file.

 

To change font:

 

I use fill_vram(0x2100,0xf1,512); to write 0xf1 to vram address 0x2100 to 0x2100+512, to color the font. Using 768 instead of the 512 will fill in the lower case colors.

example:

while(a==1){
if(frame==0){fill_vram(0x2200,0xf1,256);}
if(frame==3){fill_vram(0x2200,0xe1,256);}
if(frame==6){fill_vram(0x2200,0x31,256);}
if(frame==9){fill_vram(0x2200,0x41,256);}
if(frame==12){fill_vram(0x2200,0x31,256);}
if(frame==15){fill_vram(0x2200,0xe1,256);}

frame++;
delay(1);
}

Will make the font Uppercase letters flash.

Edited July 31, 2016 by Kiwi

[Serguei2]

I tried it but somehow, it's not working.

 

The compiler gives me "kiwi.c:20: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG" error

 

Here the code:

 

 

#include <coleco.h>

#include <getput1.h>

void nmi(void) {}

void main(void)

{

byte a;

byte frame;

a=1;

frame=0;

vdp_out(0,2);

vdp_out(1,0xF85);

paper(0xc);

upload_default_ascii(NORMAL);

duplicate_pattern();

cls();

screen_on();

while(a==1) {

if(frame==0){fill_vram(0x2200,0xf1,256);}

if(frame==3){fill_vram(0x2200,0xe1,256);}

if(frame==6){fill_vram(0x2200,0x31,256);}

if(frame==9){fill_vram(0x2200,0x41,256);}

if(frame==12){fill_vram(0x2200,0x31,256);}

if(frame==15){fill_vram(0x2200,0xe1,256);}

frame++;

delay(1);

}

}

 

And I'm not sure about Evelyn, the modified dog. It's a kind of joke.

[Kiwi]

Here's the fixed version.

#include <coleco.h>
#include <getput1.h>

byte a,frame;

void nmi(void) {}
 
void main(void)
{
//        byte a;
//        byte frame;
        a=1;
        frame=0;
screen_mode_2_text();
//        vdp_out(0,2);    
//        vdp_out(1,0xF85);
//        paper(0xc);
upload_default_ascii(NORMAL);
duplicate_pattern();
cls();
screen_on();
print_at(1,1,"KIWI");
 while(a==1) {

  if(frame==0){fill_vram(0x2200,0xf1,256);}
  if(frame==3){fill_vram(0x2200,0xe1,256);}
  if(frame==6){fill_vram(0x2200,0x31,256);}
  if(frame==9){fill_vram(0x2200,0x41,256);}
  if(frame==12){fill_vram(0x2200,0x31,256);}
  if(frame==15){fill_vram(0x2200,0xe1,256);}
  frame++;
  if(frame==18){frame=0;}
  delay(1);
 }
}

I recommend declaring variable globally. Colecovision only have 1024 bytes of RAM. I used screen_mode_2_text(); which is the mode to set up the video chip to use 3 pattern table with 1 color table. There's a hardware glitch using 1 pattern and color table version of screen mode text. I'm unsure what mode you are selecting, but the flashing text was done in screen mode 2 text. I added (frame==18){frame=0;} to reset the counter to 0. It should compile and work properly. You can enable paper(12) and then replace 0xf1, with 0xf0 to change the text back color to invisible color so the background color will shine though the letters.

[Serguei2]

I compiled the program without errors.

 

But I get this when I clicked on the link button.

 

 

Try to link project : robin

Multiple definition of _main

C:\robin\ColecoVision\robin>sdcc -mz80 --code-loc 0x8024 --data-loc 0x7000 --no-std-crt0 ../crtcv.rel ../cvlib.lib ../getput.lib ../comp.lib hello.rel kiwi.rel

Multiple definition of _nmi

C:\robin\ColecoVision\robin>objcopy --input-target=ihex --output-target=binary crtcv.ihx result.rom

 

Still, the program runs fine but it would be greater if I don't get error when I click on the link button.

 

I do my best to understand how to program Colecovision games, most of times, using codes from games included with CV-dev kit or using the manual.

 

All the tutorials I found in the web are dead.

[Kiwi]

It seems like you have multiple source files in one file. Makes sure that the source file .c is in it own folder(delete everything but the source file). I use CCI3, which have a file browser. And when you compile, bunch of files are created. And then link to make a ROM. If it create a ROM and then it should be bootable in BlueMSX.

 

I have one video tutorial made, http://atariage.com/forums/topic/218447-how-to-make-a-colecovision-title-screen/

 

I really should make more of those video tutorial to get other people started.

 

I used the source code and manual to understand how to use the functions too.

[Tursi]

 

 

warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG

 

I'm not a fan of this completely unhelpful message, but what it means is that you have a conditional expression which never changes. (Other compilers will call it "Conditional expression is constant"). Because the condition never changes, the compiler did not bother to produce code for the unused path.

 

In this case you used a while (a==1), since it's always true, no conditional testing or branching was generated.

[Kiwi]

 

I'm not a fan of this completely unhelpful message, but what it means is that you have a conditional expression which never changes. (Other compilers will call it "Conditional expression is constant"). Because the condition never changes, the compiler did not bother to produce code for the unused path.

 

In this case you used a while (a==1), since it's always true, no conditional testing or branching was generated.

Yeah, the warning went away when I took out the local variables and made them global. I also get that warning when I do...

if(a=0){DoThis();} and sometimes forget why something didn't work after I link it and run the ROM. It could say that '=' should be '==' instead of being vague. I think global variables get assigned 0 when they are declared at the start of the game and they are at a fixed RAM address. And it get changed to 1, which made that warning go away.

Edited August 15, 2016 by Kiwi

[Serguei2]

It seems like you have multiple source files in one file. Makes sure that the source file .c is in it own folder(delete everything but the source file). I use CCI3, which have a file browser. And when you compile, bunch of files are created. And then link to make a ROM. If it create a ROM and then it should be bootable in BlueMSX.

 

I have one video tutorial made, http://atariage.com/forums/topic/218447-how-to-make-a-colecovision-title-screen/

 

I really should make more of those video tutorial to get other people started.

 

I used the source code and manual to understand how to use the functions too.

 

I removed some files and the compiler runs fine.

 

 

 

I'm not a fan of this completely unhelpful message, but what it means is that you have a conditional expression which never changes. (Other compilers will call it "Conditional expression is constant"). Because the condition never changes, the compiler did not bother to produce code for the unused path.

 

In this case you used a while (a==1), since it's always true, no conditional testing or branching was generated.

 

I edited the code like this:

 

 

#include <coleco.h>

#include <getput1.h>

byte a,frame;

void nmi(void) {}

void main(void)

{

a=1;

frame=0;

screen_mode_2_text();

upload_default_ascii(NORMAL);

duplicate_pattern();

cls();

screen_on();

print_at(1,1,"KIWI");

loop:

if(frame==0){fill_vram(0x2200,0xf1,256);}

if(frame==3){fill_vram(0x2200,0xe1,256);}

if(frame==6){fill_vram(0x2200,0x31,256);}

if(frame==9){fill_vram(0x2200,0x41,256);}

if(frame==12){fill_vram(0x2200,0x31,256);}

if(frame==15){fill_vram(0x2200,0xe1,256);}

frame++;

if(frame==18){frame=0;}

delay(1);

goto loop;

}

 

Thanks for the help, guys.

Edited August 15, 2016 by Serguei2

[Tursi]

I think global variables get assigned 0 when they are declared at the start of the game and they are at a fixed RAM address. And it get changed to 1, which made that warning go away.

 

Be careful with that when you move between development environments - it's only true if the startup code does so. The CRT I started with didn't zero memory at startup (or load initialized data), for instance, so variables had a random value until they were assigned in the code. It is part of the C specification, but implementations vary, especially if you write your own startup code!

[Kiwi]

 

Be careful with that when you move between development environments - it's only true if the startup code does so. The CRT I started with didn't zero memory at startup (or load initialized data), for instance, so variables had a random value until they were assigned in the code. It is part of the C specification, but implementations vary, especially if you write your own startup code!

I do make sure that majority(all if I can remember) of the variables in the game use get loaded with a value. I don't have an EPROM burner to test my game at an unknown state. Ultimate SD cartridge reset all the variable to 0 before booting the game.