I am messing around at trying to get a simple emulator working on the Virtual Boy (nothing exciting though), however GccVB won’t compile a correct rom if I include the cpu core.

For example if I create a simple hello world program but include:

#include “z80/z80.h”
+ the various functions that the z80 is expecting (read memory, write memory, etc)

and compile like (using the batch file included in GccVB):

make c:\vbdev\emulator\ emulator

It compiles and runs perfectly

However if I actually include the z80 core (not just the header), like:

make c:\vbdev\emulator\ emulator c:\vbdev\emulator\z80\z80.c

It compiles perfectly but does not run. If I check the various debug options in Red Dragon it looks like nothing is being run at all (the first thing I do in main() is load a font, I can see in the debugger that it isn’t being loaded at all).

Any ideas?

Possibly a RAM overflow. Remember that VB has a slim 64KB of WRAM to use. If the core contains a lot of variable, arrays or structures, it may be using too much RAM. The linker script in gccvb does not check how much RAM a compiled program uses, so it can be difficult to track down these kinds of bugs.

One way to check is by using objdump to dump the section information:

objdump -t objectname.o > sections.txt

Where “objectname” is the name of the object file created by gcc. The create “sections.txt” file will contain many lines that detail all parts of the object file. The first few lines can be the most important:

SYMBOL TABLE:
07000000 l d .text 00000000
07001890 l d .rodata 00000000
05000000 l d .data 00000000
05000014 l d .bss 00000000
0500001f l d .comment 00000000

If the .comment section is placed too high in memory (say, 0500E000 or higher) then it’s quite likely to cause a stack overflow. If it’s greater than 0500FFFF, then you have a fatal overflow. These problems can only be solved by declaring large structures and arrays as const wherever possible.

It shouldn’t be too difficult to write a small program that can parse a sections.txt file and tell if there’s a WRAM overflow. The format is simple, and looks something like this:

Yeah, that sounds a lot like the problems I’ve had when I’ve overflowed my memory… BTW, are you the same Robert that worked on a few games (Space Invaders, a platformer, and Pac Man I think?) back when we only had VECC (Bluefish I think the name was)?

Are you working on the GB emu that you talked about then? If so, I’ve got a (very slowly) working one based off of gnuboy that I’ll send you if you want to look at it (it works thanks to Parasyte fixing the memory problem by rewriting the graphics part, along w/ a few other things). I did start to rewrite the CPU core in ASM, but I screwed something up and it didn’t work, then the project got put on hold 😛 .

DogP

Wow… surprised that you remember that, yeah I’m the same Robert. I lost interest in VB development waaay back then as I am eternally useless at soldering and never built a dev cart, but might have another go now if I get something worthwhile running on the system.

I’ve been trying to get Phoenix running, as it’s very simple hardware. I’m sure there’s lots of early arcade games that would be emulatable at a decent speed on the VB.

It’d be really cool of you if you could send that source code, thanks!

Cool… I’ll try to dig up the code and email it to you. I haven’t worked on it in a long time, so I’ll have to find the last working version.

DogP

I’d like a copy too if that’s possible 🙂

Me three. 😉

No.

Heh, j/k… 😀 . I’ll just post it on my webspace and put the link here when I get around to finding it.

DogP