Original Post

Hi all,

I have recently joined the ranks of the VB collectors and am looking to begin homebrew development. I have written and published other console games and am really looking forward to getting my hands dirty with the unique system we all love so much.

Clearly the first hurdle is putting together a development system. I have recently made a FlashCart which is capable of holding the binaries of the commerical ROMs. I have tested it with Jack Bros and a few others all work fine, this however is not my goal. I want to be able to upload my own (initially) novice level homebrew “hello world” programs. Before commiting to this I have tried to load some of the exitstng homebrew ROMs.
Thus far I have tried:

Reality Boy Demo,
EXAMPLE, (form the VB compiler)
Virtual E-cursor Demo

none of these work (varying sizes from 8K to 512K)

Not all of these work with Reality Boy either. πŸ™
(what am I missing?)

Is there any security checksum or byte boundary I need to observe before these ROMs will work successfully on genuine VB hardware?

Any tips from those of you with working Flash Carts?
Can anyone get Pong to work and what are the steps?

(To summarise I am using a homemade flashcart (1MB) in a real VB that works fine with commerical ROMS uploaded to it, (I own the originals) but does not work with homebrew ROMS)


P.S. I’m VERY serious about developing for this machine so anyone who is able to help will most likely be assisting me on my way to releasing a new homebew VB game in 2007.

13 Replies

you should try some other, newer homebrew stuff. virtual pong, reality boy demo and virtual-e cursor demo are all very old which is probably the reason they don’t work on hardware. one that works for sure is blox (1.1). maybe try that one?

Thanks for the suggestion.
Hmm, Blox 1.1 does indeed work beautifully. (Nice work Christian!)
but what is going on with the others? I notice there are game “headers” at the end of the ROMs and I have also read that they must be in 256,512,1024K sizes..

(I even tried “embedding” one of the other shorter binaries into the 1MB JB and Blox binaries, preservng the game header info. (since much of the “middle” ROM is blank anyway) but as you would expect with such a longshot failed too. πŸ™‚

I guess I will need to try to compile a hello word of my own, but if I can’t get much else to work I would expect it to fail. I must be missing something..

Any more ideas, anyone?

I have no idea about the technical stuff I’m afraid, but I’d like to offer my help on the musical side of things. If you need someone to make music for your game in the future, then please ask πŸ™‚
It certainly is encouraging to see experienced people like yourself interested in the vb!:)

to get smaller games to work on your cart, you first need to pad them to 1024k, then split even and odd parts like as it seems you already did with correctly with other games. ^_^
to pad the roms you need runnerpack’s padromvb.exe which can be found in the bin/ directory of the gccvb package.

hmm splitting up the roms into odd and even parts is not neccesarry on virtualzoas flashcart. i have the same flashcart. it comes with 16bit flash for maximum flexibility so only one adaptor is needed to program them.

padromvb.exe from the gccvb1.0 was the key. now all homebrewns seem to work (only tested the tictactoe so far which didn’t work before)

i can’t believe it was soo easy.

hope that is enough to motivate virtualzoa to make a game for us πŸ˜‰


As macallan confirmed padromvb.exe sorted it out nicely!
I can now run the Reality Boy demo on a real VB and more significantly the “example.c” also compiles successfully with gcc to give me a working VB ROM πŸ™‚

Many thanks to KR155E and those of you who took the time to think about this.

I am unable to sucessfully compile hello3.c as it has several errors
“undefined reference – OBJ_YSET” (for example)

Strangely OBJ_YSET is not defined in any of the the include headers..?
So how would I know if it is in the library?

It’s late for me and I have only just stolen 15 mins to test the great tip you gave me, hopefully I will be able to solve the compiling in a day or two with a fresh brain. (Of course if anyone wants to let me know what dozy error I have made in my compiler flags etc.. to save me the time then I’m all ears..)

[Excited to be able to run example.c, but aiming much higher]


P.S. Ta for the sound offer, it’ll take me a while to be ready, but I’ll know who to call. πŸ˜‰

Welcome to the community VirtualZoa! πŸ˜€
Things tend to be slow in the VB community, but if you have IRC you can visit the ‘official’ channel on EFNet #virtualboy.

OBJ_YSET used to be a function which would allow you to set the Y coordinate of an OBJ (sprite). Similarly there was an OBJ_XSET as well.

haven’t looked at the new gccVB, but I’m guessing they were either renamed or replaced, possibly by OBJ_SET(x, y).

…Also, what flash cart are you using? I want to make one, but all of them seem to use 2x 8-bit chips rather than 1 16-bit one.


I managed to compile hello3.c
Its pretty hard to make sense generally of what routines come in useful when as there doesn’t seem to be documentation to the gccvb libraries and routines. (Does anyone have any?)

Anyway I changed the functions (which turned out to be macros) to some that do exist, although then there were syntax failures. I was really suprised to see a while (false) loop in the macro. So I simplified them to get them to compile, but clearly I’m doing something wrong since gccvb has been around for a while so there’s no way it can be as contradictary as it appears…?? Theories please!! πŸ™‚

If anyone is interested here’s the code I changed..

//OBJ_YSET(i, Circle[points*2+1]); // original code
//OBJ_PSET(i, Circle[points
*2]); // original code

//OBJ_SET_Y(i,(Circle[points*2+1]) ); // found these macros instead..
//OBJ_SET_P(i, Circle[points
*2]); // (but they still fail to compile)
//in object.h macros map to:
//#define OBJ_SET_X(n,x) do { OAM[ (n) << 2] = (x) } while (0) //#define OBJ_SET_P(n,p) do { OAM[((n) << 2) + 1] = (OAM[((n) << 2) + 1] & 0xC000) | (p) } while (0) // simplified macros do compile: OAM[ (i) << 2] = (Circle[points
OAM[ ((i) << 2)+2] = ((Circle[points
*2])*10)+100; // added Y movement since parallax is hard to notice.
OAM[((i) << 2) + 1] = (OAM[((i) << 2) + 1] & 0xC000) | (Circle[points

Cheers Alex

P.S. Regarding the flash cart, I said “I made it” to simplify the previous post. I have a wizard friend who actually makes stuff. This was a prototype, but is currently a little awkward to use. He is working on another more convenient version. I guess the dev community (rather than collectors) is a little small at the moment, possibly as it is hard to gain VB programming context. I guess it’s up to him whether he feels it is worth producing more. My opinion would be if a couple more homebrews appear (i.e. we prove VB dev is achievable for the average joe like me) then there is a better case for flashcart production, otherwise they’ll just end up being used to infringe Nintendo’s copyrighted games.. and I doubt any hardware supplier would want to incur the wrath of the big N!

Sadly the state of hombrew development on the VB is in it’s infancy. Any code older thain about 3 years is junk, ignore it! That is to say there was no consistency between the librays and compilers used, so they wont compile and probably don’t make much sence.

Now that we have vbgcc and some sort of semi stable library things are better, but far from great. VBGCC is a poor implementation of C, with way to many restrictions to be practical. I have a new version of vbgcc (gccvb, all the same) on my website but you have to build it yourself and it totaly breaks (the broken) exiting librarys. So far I have not had time to come up with better librarys. Maby that is something you could work on since you are obviously no sloutch to programming.

Take a look at the very latest Affine mode demo on my page, it compiles with the new vbgcc on my website and in general should be a good example of how to code for the vb. (but a very simple example)




I found a few more hours to look into things. I actually concluded I couldn’t see the wood for the trees! (Shame on me) I found some assembly code and that made a lot of sense to me. (I’ve not done V810 (yet) but it was still clear enough.) So when I brought this knowledge back into vbgcc it all worked great. Perversely I’m finding it easier without the libraries but accessing memory directly (then once I have that working I’m then going back to look at DT’s libs.) So for the moment the standard C it suiting me fine. I have some simple images (VirtualZoa logo) displaying nicely at different depths using BGMs and an OBJ based joypad moveable monogram. Simple but a nice test.

I avoided (affine) Vectors since I’ve been doing vectors on another machine a lot recently, but I guess now I need to complete the VB knowledge set. I’ve just downloaded the affine demo and docs so I’ll take a look and report back. I understand 2D matrix transforms but have not studied affine before. I *think* its all about preserving parallelism (from distant memory) I guess I’ll find your soon enough.

One thing that occurs to me that unlike the “classic” consoles I’m used to the VB has tons of memory and CPU cycles to spare. My head spins when I see the huge BGM tables and many the bytes they consume. (I need to recalibrate!! πŸ™‚ but it’s fun and certainly a contrast. With this in mind I want to be clear on my early projects. It takes time to produce graphics for VB so I want to make sure my efforts are well directed.

Experiments thus far (maybe it’s my eyes) are that the perspective offset alone is a reasonably weak 3D effect. Scaling is an obvious one compliment to it which I’ll be exploring, but the dual aspect sprites may well be necessary. (again that a new, (potentially time consuming) but exciting world to explore.)

A final note. David Tucker- thanks for Reality Boy! Constant EPROM burning was getting tedious, now I can use RB to test things initially, speeding things up a treat. (and the red/blue and interlaced options are very useful indeed!) Ta for such a useful and flexible tool!

Cheers Alex

(later on)..

OK just read Affines. Seems clear enough. Thanks for writing the doc, David. Although it does raise a question. You mention a new compiler vbgcc/gcvbb; none of them seem to have version numbers so its hard to know whats what, but the one on your site and the one I already have seem to be the same (and are mainly macro based in accessing data.) In your Affine document you provide a nice clear code example which benefits from (what appears to be) very convenient arrays of structures. (WA[31].??? for example. ) I don’t see these structures defined in the include headers I have. Is this what you meant by assisting to rewrite the headers with you?

Cheers Alex

P.S. I take it red alarm uses it’s own direct drawing routines then? I had assumed this was what the (previously mysterious) affine mode was for but now I see that too is bitmap based. Is anything known about the “raw” draw method?

Yeah, direct screen drawing is fairly simple… I’ve written a few demos, I think they’re available on this site… Etch a Sketch, 3D Battlesnake, and I think a few small simple tests. I also wrote some line drawing functions, which should be in the libgccvb included with those. The drawing itself is very simple, the trick to using it well is in the control regs (screen refresh, writing to the back buffer, etc).


The structs are defined in my affine demos. Its realy simple:

struct x{
int a;
int b;

} *x_ptr = 0xppppp;

You could come up with it on your own if you wanted.

As far as GCC goes: Mine is based on the same code as on this site, but… Mine has a working stdlib so things like floats work properly, and you can make fn calls from other c files. Also I rewrote the loader so that you dont need to run any extra programs to convert an object to a working .vb rom file. I of cource recomend using my own compiler iteration but no one else does so take it for what its worth.



Write a reply

You must be logged in to reply to this topic.