Hi, I have made a lot of progress on my engine and is working really well… in the emulator, because I can’t make it work in the real VB, I suspect it has something to do with the fact that my code has grown a lot, and now the compiler creates the files not bounded to powers of 2:

232 kbytes object.elf
172 kbytes vbJaEngineDemo.vb

This is when I create the ROM in a ext3 partition, if I make the linker to output the ROM in a FAT partition, the size changes to:

256 kbytes vbJaEngineDemo.vb

I make a:
cat vbJaEngineDemo.vb vbJaEngineDemo.vb vbJaEngineDemo.vb vbJaEngineDemo.vb > vbJaEngineDemoPAD.vb

to create a file that sizes 1 MB, but when burned to the flash memories, it simply doesn’t run in the VB.

Could someone explain me please what is all that about filling the memories with the same data until fill the 1MB.

Regards
Jorgeche

Just for the shake of posting… just kidding, I’m pretty sure now that the stack grows down…

void main(){
int i;
int j;
}

i’s address: 0x0500FFA4
j’s address: 0x0500FFA0

Still more difficult to know how much the stack grows… 🙁

Oh yeah… you’re right… since the local variables are on the stack, the size will grow down… or up, depending whether you’re talking CS or EE 😛 (some draw memory with higher addresses at the top of the drawing, others draw it at the bottom). So yeah, if you use too much memory, you’ll overwrite your static memory, and then go into the 04XXXXXX memory space (unless they start the stack at 05FFFFFF which would also work because memory only decodes the lower 16 bits). Maybe you should declare an initialized global variable and keep checking it to make sure it hasn’t been modified (either in your running program, or put a watch on that memory location in the emulator). Or you could just log all WRAM access in the emulator and check the log to make sure it looks right.

DogP

No, indeed, I have avoided recursion, I just tried it almost 6 months ago and remember that it didn’t link, but now it links… just made a test, I was forced to drop any recursion in the design stage… and better I did. :-). I will check that in RD tonight. Wrote to David to see if he has an idea.

Running out of ideas… declared this:

int global;
void main();{
.
.
.
}

global has and address 0x0500008… and no change of its value… never…

I will check those outputs from RD tonight, thanks for all your help DogP.

In an strange turn around it worked again!… now I see that the problem was not memory related, I don’t know why, but I’ve managed to make the ROM work again by calling this function in the game’s main loop:

void verify(int i){
//turn on the display
vbDisplayOn();
//setup column table
vbSetColTable();
//this just puts WRLD_ON on layer 31
vbActivateWorldShow();
//set brigth
vbFXFadeIn(FADEDELAY);
}
//game’s main loop
while(true){
GameEngine_handleInput(&gameEngine);
GameEngine_update(&gameEngine);
GameEngine_render(&gameEngine);
//this is the function
verify();
}

I can’t figure it out why that exact combination makes it work, and why if I put the call before the infinite loop it doesn’t.

Now, all those functions are called in the gameEngine’s initialization, and after loading a game world.

Thanks again for your support.

Cool… glad you got it figured out!

DogP

good news! thanks from me as well, pat. ;D

I wish the Virtual Boy had more RAM lol

Confusing