Original Post

I have a new idea I want to attempt for the Virtual Boy. Basically what you do is explore around trying to find a pineapple. The pineapple is like the Legend of Zelda’s Triforce of this new game idea I have in mind. Only it’s supposed to be a humorous silly game with silly enemies and other stuff. I hope to begin work on it on January 1, 2016. I’m calling it “Pineapple 64,” a callback to when most Nintendo games had the “64” suffix on it, and yes, even though it’s on the incorrect platform to HAVE the “64” suffix on it. That’s how silly the game is. You guide Quincy Quandorf on a guide to find the pineapple. That’s the point. But it will (hopefully) prove hard to do. Not that I’m a fan of hard games or anything. And in this game, I’d probably need to implement saving, so it would need SRAM or whatever, and this would be the first game I would ever program that would need it. Nothing really all that hard to save, though, just what level you begin at, your current health meter and the items you have. To save a game, you’d need to find the bathroom in a certain level and use its toilet. Flush the toilet, save your progress. And I’d only have one save file since, let’s face it, how many people who have a Virtual Boy have more than one person who uses it?

31 Replies

I really like that idea. The sillyness will definitely make it stand out.

That sounds absolutely ridiculous, I like it.

LOL, Pineapple 64 is 32 bit. I like the idea, but it sounds like a n64 game, not a VB game.

So here is your Christmas present: A first look at Pineapple 64. It’s really rough, but bear with me. The collision code that GoSub had I tried to utilize in this game, but I discovered that it only did the first character and not all of them. As a result, I need to know if my code can be altered to bump into ALL characters, not just the first one. (And Quincy can walk around almost everywhere right now on the first screen, including off it.) The zip file attached contains the .vbh, .vb and .c files. PLEASE let me know if the collision code can be tweaked. Right now there’s 17 characters, but I can change it to 16 if need be, I know how computers like powers of 2.

Wow, that was quick! I mean obviously just the beginnings here, but you already have a little intro and everything. Good job!

Thanks. I worked a little bit more on the beginning screen last night for about 4 hours, trying to figure out stuff. I figured out how to do collision detection on all characters. It probably could be tidied up a lot, but I didn’t know how. It’s still one screen, though. I put the build on my website, you can check it out here:

I made a song for the first level. I also tried to normalize the movement of pressing down or up when you are at the edge of something, but it still makes you move left or right by pressing down or up. I tried just about everything and nothing helps, so I think I’ll leave it just as it is unless someone else can help me. Other than the song, though, nothing else has changed. I made a website for the game, you can find it here: http://www.atari2600land.com/pineapple64/

I am wondering how I would test the game progress saving aspect of this game. Does a FlashBoy have a battery that I can use with this, or what would I need to do? All I’d need to save is some variable values, so not very much info.

This code should work on both the FlashBoy Plus as well as emulators: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=18663#forumpost18663

Reality Boy creates a *.ram file next to your ROM which you can inspect in a HEX editor to see if stuff was properly saved.

If it is correct in the ram file it will also be on the FB.

Note that the above code is hackish and only allows using half of the available Save RAM, but it will be more than enough for your needs.

So would the variables I would want to save I would want to make them a u8 or u16?

Hey, you don’t need to worry about the size of your data, as long as you read and write to SRAM following its constraints. That is, you will need a BYTE* pointer to the data to save/read, a displacement in SRAM that reflects the displacement of your data (you will want to use a struct to hold any data to save in order to use this approach) and the size of the data to save.

You can take a look at the following classes and search for the use and definition of the save/read methods:



Refactoring the code to suit your needs should be easy enough.


Thanks for all the info about saving. I will try my hand at it once I get there. I’m still not at a point yet, but I did work on getting a couple more screens in. All you can do is move up one screen and down one screen. And even just that took about an hour to perfect. I didn’t realize it had been so long since I last worked on this project. I’ve been busy with Game Gear stuff and trying my hand at Jaguar programming. The website has been updated and the current ROM is on it.

There’s a stupid bright spot in the corner of the screen sometimes. It flickers once and then goes away, but only on a few screens and I don’t know what it is. I guess I’ll just have to leave it in the game. It doesn’t show up on Mednafen, just on real hardware. I worked a little on the game. I added a thing to do: First you have to find the big banana and then the small banana. Finding the small banana first won’t work. I won’t tell you why, but if you play the game, it becomes obvious.

man I wish we could have signatures.

I commented on the code, (heavily in the part I’m having trouble with) in case anyone wants to help with the corner problem. Find it in the link above.

Can someone please help me? I still have the stupid problem of the upper left corner of the screen flickering. I don’t know what it is. I have tried various things, and it only shows up if played on a real Virtual Boy.

Hi Chris:

By quickly checking your code, it seems that you are not waiting for the VPU’s drawing process to end before writing to DRAM. The lines like the following, in the walkingaround function, could be the offenders:

// put quincy on the screen.
vbSetWorld(29, WRLD_ON, quincyx, -2, quincyy, quincycutx, 0, 0, 14, 32);

You need to either brute force the wait, and write to DRAM only after it:


Or use interrupts, on these posts you can find more info about them:



The interrupt approach is preferred, and gives great results on hardware, but it is tricky to understand it at first sight, and you have to make sure that no race conditions arise because of the asynchronous nature of the interrupts. This is what I do:

// VPU’s interrupt handler
void vpuInterruptHandler()
// here you write to DRAM, in your case:
vbSetWorld(29, WRLD_ON, quincyx, -2, quincyy, quincycutx, 0, 0, 14, 32);

while (true)
// update each subsystem
// wait to sync with the game start to render
// this wait actually controls the frame rate

// at this point disable the VPU’s XPEND interrupt

// calculate the data to write to DRAM while the VPU
// is busy drawing

// after you have finished calculating the data to write to DRAM
// enable the VPU’s XPEND interrupt

// do any other process that is not DRAM related

I’m omitting some details, you can check the full code at the following links, just look for the Game_update and VPUManager_interruptHandler methods:




Hi jorgeche,
I did not understand the second option which was recommended. It all looked like gobbledygook to me, so I went with the first option, which was to force a wait. As it turned out, that option worked for me greatly. Thank you for helping me out, and now that that problem is done, I can work on the game some more.

VirtualChris schrieb:
Hi jorgeche,
I did not understand the second option which was recommended. It all looked like gobbledygook to me, so I went with the first option, which was to force a wait. As it turned out, that option worked for me greatly. Thank you for helping me out, and now that that problem is done, I can work on the game some more.

Glad to be of help ;).

Here’s some screenshots. As you see, I tried to make things a lot better-looking and more uniform. I even added some music to level 1’s tune.

Made the trees look better. Now they don’t look like q-tips.



Write a reply

You must be logged in to reply to this topic.