For a short game, it takes a long time and patience to make. I had to study the C programming stuff, and translate the TI-83 code into C. I really love the graphic chip of the Colecovision and the vast amount of resource out there is enough for me to start coding for it. ICVGM, again, is awesome. I have to draw a lot of graphics for such small 9 by 6 window. I want to see how far I can push the limitation. Furthermore, working with ICVGM and programming in C relaxes me and made me more confident that I am making a game with graphics. There's more variation and control than Wario Ware DYI. Yet both things almost have the same amount of colors, 15. I can make my games much longer than 16 seconds, and have bunch of stockpiled data stuff up to 32KB.

As for my game, I think it should be finished in 2-3 weeks. I built all the town graphics. All's left is to tile them in and draw the human sprites. The game is creeping up to 16KB. Hopefully it'll be under 18KB when I finish the town. I'm praying I get part 2 under 28KB, so I have data left over for sound effects, which I have to do hours of research and play around. The TI-83 BASIC version was split into 2 parts because the Calculate only had 24KB of RAM, and 160KB of Flash memory. The TI-83 version had ASCII pictures, and one Pic1 file for the ending. Each part weight about 20K each. So, Colecovision cartridge only goes up to 32KB. Fortunately, RLE compression is awesome enough to keep the filesize down. If I need more space, I'm going to rework the logo screen to gain 2KB, if I get closer to 32KB. Then rework the title screen and redraw the dragon. I already fixed the letters and make the background colors blue to match the sky.

I changed my menu program to make the control more responsive than ever!!!

Old code:

        
enable_nmi();
choice:
       print_at(3,16,"Choose a choice below.");
       print_at(3,18,"   Yes, I will help you.");
       print_at(3,19,"   Where is the dragon? ");
       print_at(3,20,"   No I cannot help you.");
       f = 18;
       e = 0;
       put_char(3,f,0x01);
       delay(2);
       while (e==0)
       {
               if(joypad_1&(UP|DOWN))
                       {
                               print_at(3,f," ");
                               if(joypad_1&DOWN && f!=20)f++;
                               if(joypad_1&UP && f!=18)f--;
                               put_char(3,f,0x01);
                       }
               if(joypad_1&FIRE1)e++; 
               delay(1);
       }

Then the new code:

enable_nmi();
choice:
print_at(3,16,"Choose a choice below.");
print_at(3,18,"   Yes, I will help you.");
print_at(3,19,"   Where is the dragon? ");
print_at(3,20,"   No I cannot help you.");
f = 18;
put_char(3,f,0x01);
delay(2);
while (!(joypad_1&FIRE1))
       {
	if(joypad_1&(UP|DOWN))
                       {
			print_at(3,f," ");
			if(joypad_1&DOWN && f!=20)f++;
			if(joypad_1&UP && f!=18)f--;
			put_char(3,f,0x01);
			delay(3);
		}
               
       }

The old code had delay(1); outside the if(jp1..), if I increase delay to 4. Then people would be thinking, what the heck? My controller isn't working. In other word, the controller would be less responsive because it might be on the delay(255) loop when pressed. The new code, I move the delay() inside the if statement at the last entry. So when people move the joypad up or down, the movement is instant instead of a probability of the arrow not moving on command.

I made a 6 choice menu selection for the town, putting delay inside the if statement was a great idea. Thanks Bruce for giving subtle hint that something is wrong and made me think what could I make the control better.

I had a chance to take a look at Newcoleco response to his sprite routine and try it out in my scratch program. It didn't work, but I need to study the sprite_t more and hopefully the flickering would be sped up. I will analyze it later when I'm not so tired. Analyzing is what I do most in my life... so I should solve this case eventually.

Hopefully next week, I will have that SD UUULLLTTTAAAMMMIIITTTEEE CARTRIDGE for my Colecovision. Saves me buying an EPROM burner, wafer boards, and ERPOMs. I'm dead curious how my game run on the real Colecovision. I really hope graphic corruption won't occur. The game uses the VRAM a lot. On the plus side, I finally get to play CV version Mario Bros.

In real life stuff, my dad's sick. I pray for my dad's recovery. He's in the hospital. He was in unstable condition, but slowly becoming better.