10 replies to this topic

[Kiwi]

I'm having a bit of a problem, and I do not understand. The program went fine until line 1200. Now the program reboots. It well under the 32KB limit, which is now 17.2 KB. I guessed first it was the function size issue, which might have a limit of 255 lines. Void have 2 byte, not exactly what the number are for, I'm guessing it was for ID#,pointer to keep track of line # number. Then I remove the function from that tree and made it own tree so that function could stop and call the new function. Still the same issue, strangely. If I remove the statement completely, the program runs perfectly. I organized the program as logically as I can, so that Warning messages from the compiler would disappear. Still reboot.

The function is called, TownScene. There is 6 different area that you can go to, which is branched into an if statement with series of loading sprite and tiling the scene from a function.

I think the only thing I can try now is to get a number or value from TownScene(), end that function to go back to main(), then select the statement that was selected from TownScene(). Try moving the image data to it own textpad if the SDCC compiler have a limit, I don't feel comfortable doing that. If I must move the images it it own file, I will do it. I like to keep thing in one place.

Any idea appreciated.

Edited by Kiwi, Mon Sep 6, 2010 11:35 PM.

[youki]

I didn't read what you wrote in detail , i will read later when at home.

But Personaly i try to never do function that have more than about 20 lines.

But your problem is may be just a problem of RAM not ROM.

Stack overflow for instance . Or Stack corruption because you used to much RAM.

There is only 1k of RAM (used for the RAM and the stack) on a colecovision. It is very small. If you have lot of global variables or if you use recursivity for function call. you reach easly the limit... and generally the effect is a reboot...

Edited by youki, Tue Sep 7, 2010 1:44 AM.

[GroovyBee]

Get the compiler to produce a map file. Look at the RAM usage to see if there is anything unexpected in there.

[newcoleco]

If you are making a recursive function (a routine that calls itself) and each time it needs more variables and/or tables, you increase the risk of RAM corruption. Consider that you have not really more than 512 bytes of RAM.

I remember that Hi-Tech C compiler certain have an issue with the number of lines... Ms Space Fury project was on the edge of this kind of limit and my solution was simply to split up the source code into multiple files. Each function/routine I was able to extract from the main file like showing a splash screen for a few seconds was enough to save my problem of that time. But, your problem is different because I don't think SDCC does have such a limit of number of lines. However, if you split your code into multiple sub-routines instead, you may find the code more easier to read and easier to maintain as well... and maybe it will help you to find the potential problems and find solutions.

[Kiwi]

This is what the void main(void) looks like at the moment.

void main(void)
{
reset:
disable_nmi();
fool=0;
gameover=0;
pass=0;
weapon=0;
money=0;
blksmith=0;
screen_mode_2_text();
logo();
title();
// load_colorrle(COLORRLE);
pause();
cls();
ScrollScreen();

Story();
fill_vram(0x2000,0xF1,1024);

loadInterface();
LOADthroneRoom();
KingScene();
if (gameover==1)goto reset;
SweepSprites();
loadInterface();
LOADtown();
TownScene();
SweepSprites();
if (gameover==1)goto reset;
SweepSprites();


pause();
}

I think I should move all of the code that are just a script for that section intergrate them into the main case since they aren't exactly function. I do have functions that will need to be called in order to reset the interface, clearing all text boxes, and clear only the dialogue function. Then I got function that build the graphic screen, which I will leave alone. Trying to think why is the program have to know what's in those function when they aren't being called. Then trying to think what's the different between void, and static void.

If anyone want to take a look at my code, I post an attachment in this post. Delete the Laura() function, and the game will work.

[attachment=172549:Text Adventure.zip]

Thanks.

[GroovyBee]

Can you attach the compiler's map file?

[youki]

I'm not sure it is the cause of your pb but you didn't put "Static" when you declared :

const byte WomanRLE[] = {

an sometimes you invert static const and const static in your definitions.

[Kiwi]

GroovyBee, on Wed Sep 8, 2010 3:15 AM, said:

Can you attach the compiler's map file?

Sure, I attached crtcv.map, crtcv.sym and main.o(just in case).
[attachment=172584:compiler sym map o files.zip]

youki, on Wed Sep 8, 2010 3:15 AM, said:

I'm not sure it is the cause of your pb but you didn't put "Static" when you declared :

const byte WomanRLE[] = {

an sometimes you invert static const and const static in your definitions.

Fixed that, I forgot to add the static before the const.

Edited by Kiwi, Wed Sep 8, 2010 10:38 AM.

[Kiwi]

Solve the problem. It was the Kiwi text logo rising from the bottom of the screen animation was the problem. It filled up every 4th RAM, which result of the reset of the game before it reach/at the title screen. There wasn't 16 byte to spare after the Kiwi logo animation.

//	byte i,j;
//	j = 192;
//	i = 0;
//	for (i=0;i<112;i++)
//	{
//		sprites[3].y = j;
//		sprites[4].y = j;
//		sprites[3].colour = i;
//		sprites[4].colour = i;
//		update_sprites(5,sprgen);
//		j -= 1;
//		delay(1);
//	}

Seems like the for() statement is the problem. Perhaps it is creating 4 new variable at every loop, which result filling up the RAM effectly. After commenting out this code, the RAM is normal, mostly zeros. My second project I started helped me see if there's a bug with the RLE code. I'm going to change the code because I wanted to keep the animation. Well, the good news, I can keep working on this project ^_^. I'm glad for the helpful commented. It helps a lot, since I can use the advice above to help locate the bug. Off to complete this thing!

[GroovyBee]

I can't see why that section of code would cause RAM corruption unless there is a bug in update_sprites or the delay function. Try commenting out those function calls and trying it again. Also try setting variable "j" to 192 - your logo sprite height with all function calls present and see if that works.

[Kiwi]

The game is still broken . What I can do now is to split them into 2 rom/part, which I will have the CVSD cartridge handy soon. After all the original game on the black and white screen TI-83+ was in fact split into 2 part due to the file size issue. I can't find the reason why it would reboot on title screen. I can't really blame my cats for the cause of the problem. Assembly coding is an option, which I have to gather material to learn this stuff. I can't get the assembly compiler to work. Right now, I can simplify the gate/town scene, just enough so you have the necessary stuff to leave that section and the chose your dialogue stuff will have to go. Hopefully I can add one more scene before reaching part 2.

EDIT: It might be the compiler.

Edited by Kiwi, Thu Sep 16, 2010 2:17 PM.