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

hey jorge!

is it the same problem you had before? Forum Thread. did you use the right tools?

You catch me!… just kidding, sure I have the same problem before, so I used the cat command to produce a file with the same data x times (David Tucker told me to do this) and since it worked I didn’t bother to think about it anymore until now that the problem is here again, and I don’t have a clue about what has gone wrong. So I suppose that someone here can explain my this in the easy way (because I don’t really have the time to study all that electronic stuff right now… my dead line is coming fast) so I don’t have to create a new tread again when my code grows to 512 KB and beyond…

Regards

Jorgeche

does the padded rom run on the emulator?

i always use padromvb.exe to pad roms btw:
padromvb.exe infile.vb 19 outfile.vb

yes, the padded rom runs on the emulator, i will try tonight paddrom.exe again… but i didn’t have luck the last time i used it.

Thanks Krisse.

I have reduced the size of the ROM to 128KB again, but I got the same result, just a bar on the left of each display that somehow reacts to key pressing… indeed, I’m almost sure the game is playing and the problem has to do with display memory area (The VB run great every game I have, and the ones I’ve burned to flash memory such as Teleroboxer or Space Squash). So I dismiss that the cause is the grown in the ROM’s size and the padding.

I’m using the same compilation of the latest gccvb version from David Tucker I was using before when my engine ran fine in the VB.

Additionally, I have made tests initializing the column table and not, waiting and not for the screen synchronization… and I have run out of ideas… anyone?

Thanks for your help

Jorgeche

Is anyone there?, I have messed around with the ROM all the weekend and have found that the ROM filling is ok, the problem is a little more strange than I thought.

When I boot the ROM, it shows some random bars at the left side of both screens, and somehow reacts to key pressing… after pressing some buttons like a crazy, the system reboots itself and I can see for a second fraction the image supposed to be saw, but only on the right screen, in the left one the image is completely shifted to the right and I can see only a part of it. I now that the system reboots because I have put a counter that I can see in the right display, an it begins to count up every time the image is visible.

Now, I thought it had something to do with the virtual heap I created to emulate dynamic memory… initially I used 20000 bytes… now I have reduced that to 8192 (a quantity used in previous compilations which run perfectly), but nothing yet.

I have also checked that I’m not writing to world attributes when the VIP is rendering, and checked one hundred times the initialization functions provided in libgccvb, and all the routines are intact.

I have really no clue about whats going on… I have begun to read the official development manual published here, but still haven’t found anything useful.

Anyone?

jorgeche

still no luck? do you have backups of the source to go back to a point where the code is working on hardware? then you could add the changes you made since then one by one and test it every time to see what causes it to not run.

if you can’t find a solution maybe posting the source could be helpful for other people to have a look at it?

good luck!

Jmm, going back is the option I don’t want to take at this point because all the code had been rewritten in a pseudo objective fashion, and the hardware related control has not changed so much.

I don’t think I can publish the code until my grade because I’m pretty sure I will be accused of robbery… but of course I will release everything after that, I’m on the side of the Open Source!.

Well I will try to implement some things these days and will try again on the weekend…

If you can think of anything Krisse, please let me now to try it.

Not sure if this will help, but what I usually do when I get a weird bug is put in VIP_REGS[BKCOL] = 3; to try to pinpoint where the execution goes wrong (make sure you have the display enabled first with vbDisplayOn() and vbDisplayShow()). If the background turns bright red, then execution is fine through that point.

If you haven’t already, you probably also want to check your memory usage… the VB only has 64KB of WRAM, and with a large program it’s not that hard to use it all if you’re not careful. I’m sure there’s a better way to check, but the way I know of is if you go to the command line and type “objdump -s –start-address=0x05000000 –stop-address=0x05FFFFFF filename.o > filename.txt”, then you should see at the end a .comment section with some junk about the GCC version, but on the left of each line will be an address. Make sure the last address used isn’t larger than 500FFFF. If it is, then you’re trying to use more memory than the VB has. Of course to do this you need to make sure that you’ve still got your .o file (some of the bat files automatically delete them when they’re done, so modify the bat file if it’s deleting the .o’s).

I hope this helps.

DogP

Thankd DogP, I will try the VIP_REGS[BKCOL] = 3; tonight.

I got this from object.elf

Contents of section .text:
Contents of section .rodata:
Contents of section .data:

5000000 00000000 00000000 00000000 00000000 …………….
5000010 00000000 00000000 00000000 00000000 …………….
5000020 00000000 00000000 00001027 00000000 ………..’….
5000030 00000000 00000000 00000000 000000ff …………….
5000040 00000000 00000000 01000000 00000000 …………….
5000050 00000000 00000000 00000000 00000000 …………….
5000060 00000000 00000000 00000000 00000000 …………….
5000070 00000000 00000000 00000000 00000000 …………….
5000080 00000000 00000000 00000000 00000000 …………….
5000090 00000000 00000000 00000000 00000000 …………….
50000a0 0000ff00 00000000 00000000 00000000 …………….
50000b0 00000000 00000000 0c490107 1c490107 ………I…I..
50000c0 22490107 2a490107 30490107 37490107 “I..*I..0I..7I..
50000d0 3c490107 44490107 49490107 52490107 filename.txt
I get this:

object.elf: file format elf32-v810

Contents of section .text:
7000000 80bc0207 84a030b9 a0bc0005 a5a04201 ……0…….B.
7000010 c0bc0005 c6a00000 00a81000 e4c00000 …………….
7000020 e6d00000 8144c144 c50cf28d 80bc0105 …..D.D……..
7000030 00a80a00 05d40000 a244a40c f88d0570 ………D…..p
.
.
.
700ffa8 88008e00 94009a00 a000a600 ac00b200 …………….
700ffb8 b800be00 c300c900 cf00d500 da00e000 …………….
700ffc8 e600eb00 f100f600 fc000101 07010c01 …………….
700ffd8 11011701 1c012101 26012b01 30013601 ……!.&.+.0.6.
700ffe8 3a013f01 44014901 4e015301 57015c01 :.?.D.I.N.S.W.\.
700fff8 61016501 6a016e01 72017701 7b017f01 a.e.j.n.r.w.{…
7010008 83018701 8b018f01 93019701 9b019e01 …………….
7010018 a201a601 a901ad01 b001b301 b701ba01 …………….
.
.
.
7023e94 28342c33 3429002e 2e2f2e2e 2f2e2e2f (4,34)…/../../
7023ea4 2e2e2f2e 2e2f6e65 776c6962 2d312e31 ../../newlib-1.1
7023eb4 302e302f 6e65776c 69622f6c 6962632f 0.0/newlib/libc/
7023ec4 73747269 6e672f73 74726c65 6e2e6300 string/strlen.c.
7023ed4 7374726c 656e3a46 28362c31 29007374 strlen:F(6,1).st
7023ee4 723a5028 342c3334 29007374 6172743a r:P(4,34).start:
7023ef4 7228342c 33342900 r(4,34).
END

Could you tell me please if you see someting wrong? As long as I understand what the output says, is that the max address FFFF has been reached and surpassed by a long shot.

Thanks a lot!.

Actually, that looks fine… 07XXXXXX is ROM space, which you have plenty of… 05XXXXXX is WRAM space, which is limited. But you don’t have a .comment section from when you entered the command I posted? It may be different for the new gccVB, but with mine I get a .comment section, which shows the last addresses of the WRAM space used. You can’t just look at the .data section since that’s only initialized data… you need to also know how large the .bss section is since that’s the unitialized data. And you should be able to add up the size of the allocated memory from each .o file.

Maybe this will work better: objdump –headers file.o > file.txt . That should tell you all the sections along with the size and stuff. Here’s one before I had any uninitialized data:

file.o:     file format elf32-v810

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002000  07000000  07000000  00002000  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000028  07002000  07002000  00004000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000088  05000000  07002028  00005000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000000  05000088  070020b0  00001088  2**0
                  ALLOC
  4 .comment      00000026  05000088  05000088  00005088  2**0
                  CONTENTS, READONLY

and after I put in an “int test[4000];” global array:

file.o:     file format elf32-v810

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002000  07000000  07000000  00002000  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000028  07002000  07002000  00004000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000088  05000000  07002028  00005000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00003e80  05000088  05000088  00001088  2**2
                  ALLOC
  4 .comment      00000026  05003f08  05003f08  00005088  2**0
                  CONTENTS, READONLY

You can see that the size column of .data and .bss is the actual RAM usage (.bss being the new array of 4000*4bytes=16000=0x3e80). .comment is also in the RAM area, although I’m not sure why it’s there… which may be why it’s not showing up for you (David Tucker may have removed it in his build since it shouldn’t be necessary). So if you do that for all of your .o files and add up the size of all the .data and .bss sections, that should tell you the total RAM usage. The numbers are all in hex, and make sure it doesn’t exceed 0xFFFF.

Hope this helps.

DogP

Thanks DogP, so I did as you said and obtained the following results:

From all my .o files I got the following sizes:

.data 0x90
.bss 0x00

Now, from object.efl which is the file in wich I link all my object files I got:

.data 0x00000142
.bss 0x0000006c

Which is far from FFFF… so, the problem could not be about work RAM usage?… And if it was memory usage, should’n’t the emulators complain about it too?.

Thanks for your help… I have not checked yet controlling the background color… hope to have sometime today

Hmm… okay, well if it seems right that you’ve only got 430 bytes of memory allocated (both initialized and unitialized), then that’s probably not your problem. Of course without seeing what you’re doing I don’t know if that’s realistic. You could check it by adding an array and make sure that it goes up by the correct amount.

As far as the emulators go, no… at least last time I used too much memory RD didn’t seem to care… it’s still a valid memory address and I’m guessing either it overwrites memory somewhere else or just writes to nowhere, but I don’t believe that it wraps like it does in real hardware (when I was working on the Gameboy emulator for VB I used WAY too much memory… it still booted on RD, but wouldn’t do anything on the real VB).

Also, I’m not sure if you’re using objects or not, but if you are, you probably want to check out DanB’s OBJ Pointer Demo if you haven’t already. I remember him talking about how the emulation of OBJ’s isn’t correct which caused things not to appear when they should be.

DogP

Wait, that doesn’t sound right… I just read back and you said you’ve got a virtual heap of 8K (I assume you’ve just got it defined like char heap[8192];). You should at least see that amount being allocated.

DogP

Indeed:

#define HEAPSIZE1024 2048 //10
#define HEAPSIZE256 2560 //30
#define HEAPSIZE128 4120 //15
#define HEAPSIZE32 3200 //100

//each block size

#define BLOCK1024 1024
#define BLOCK256 256
#define BLOCK128 128
#define BLOCK32 32
typedef struct Heap{
//dynamic memory
//BYTE *mem1024; //uses object memory
BYTE mem1024[HEAPSIZE1024];
//BYTE *mem256; //uses object memory
BYTE mem256[HEAPSIZE256];
BYTE mem128[HEAPSIZE128];
//BYTE *mem128; //uses object memory
BYTE mem32[HEAPSIZE32];
//BYTE *mem32; //uses object memory
//allocated objects
void *allocObject1024[HEAPSIZE1024/BLOCK1024];
void *allocObject256[HEAPSIZE256/BLOCK256];
void *allocObject128[HEAPSIZE128/BLOCK128];
void *allocObject32[HEAPSIZE32/BLOCK32];
}Heap;

and my main class: GameEngine has a total size of 19668 bytes which doesn’t appear in those outputs… strange…

I have defined a global array: int global[10000]; and my bss goes up to 40108…

Now, I’m defining my gameEngine object inside the main() function… should I put it in the global scope?… that way my bss grows up to 19766 bytes.

Should not the linker complain if I exceeded the working ram area? If I declare a global array: int arrayG[100000]; I get:

/usr/local/v810/bin/ld: region ram is full (output/object.elf section .bss)
collect2: ld returned 1 exit status
make: *** [object.elf] Error 1

If I declare the same array inside main(), it links without errors.
and the size of the bss goes back to 108…

How can I know how much RAM it takes all the calls and local variables?…

Let me clean it:

#define HEAPSIZE1024 2048
#define HEAPSIZE256 2560
#define HEAPSIZE128 4120
#define HEAPSIZE32 3200

//each block size

#define BLOCK1024 1024
#define BLOCK256 256
#define BLOCK128 128
#define BLOCK32 32
typedef struct Heap{
//dynamic memory
BYTE mem1024[HEAPSIZE1024];
BYTE mem256[HEAPSIZE256];
BYTE mem128[HEAPSIZE128];
BYTE mem32[HEAPSIZE32];

//allocated objects
void *allocObject1024[HEAPSIZE1024/BLOCK1024];
void *allocObject256[HEAPSIZE256/BLOCK256];
void *allocObject128[HEAPSIZE128/BLOCK128];
void *allocObject32[HEAPSIZE32/BLOCK32];
}Heap;

Hi, yesterday I read a lot about object file’s sections, memory distribution, etc., and learned that all the calls to functions, parameters passing and local variables are located in the stack. Now, I don’t now were the stack starts, and from there which way it grows (up or down).. I suppose it grows up and starts were the bss ends (because the address of gameEngine).

I made some tests yesterday and reduced my gameEngine object to 12000 bytes, put it in the bss section, and checked the addresses of some local variables to see were in the stack are created, well the max address was in:

0x0500FF40

I couldn’t find one with a greater address, but it was the same address before and after shrinking the size of the classes and remove some function calls.

Yeah, it’s been a while since I’ve done compiler stuff, but IIRC all local variables will go onto the stack, including local variables of main. You can keep it from doing this by declaring them static (like: “static int variable[40];), or if you make them global they’ll automatically be static. You could also manually add up all declarations from your source and see how much you’re actually using.

You might want to try emailing Parasyte… I haven’t talked to him in a long time, but he used to be around a lot and definitely knows a lot more about this than I do. He may know of a better way to determine actual memory usage. You could also compile your own version of RB/RD that checks/logs any WRAM memory access.

DogP

All willl try, thanks for your help… I think I should ask David Tucker about recorsion, because I remeber the last time I tried to use it, it didn’t compile, but now recursion works… If recursion works… I don’t what to believe I have allocated the 64KB of RAM available… but I don’t have the knowledge to measure it, I have tried to pass to functions as much pointers as I can, and made sure that the big memory usage is all condensed in one single object (my gameEngine)… and visible in he BSS now.

Will keep trying… thanks a lot.

Cool, yeah… I’m not sure whether this is the cause of your problem, I just remember having a similar weird problem when one of my programs got too large and that ended up being the cause. I just remembered about something though… not sure if RB does it, but I know in RD you can put a watch on a memory range… maybe you can watch 5010000 to 5FFFFFF and run your program, then you’ll know whether it’s going out of bounds.

And I’m not sure what your recursion does, but if you’re not careful you can definitely eat up the stack REALLY quickly.

DogP