Red Square, a Yume Nikki Fan Game

Hmm, odd. I’ll have to look into what exactly might be causing the issue. It may take some time to debug, especially since I can’t test it, but I’ll see what I can do.

I went to the discord group and user jorgeche tested the rom on his flashboy, and it worked. There was a couple of issues, however. The first was an input bug related to a hardware edge-case (This has been fixed and the ROM updated on the website). The second is that the game’s frame rate suffers on a real VB. We discussed some likely causes and I’ll eventually look into the problem, but it won’t be until some time after the 7th of July.

This means that, though it does run on hardware, for the time being it’s probably best experienced through an emulator. When I get time to sus out the hardware speed issues I’ll post an update.

speedyink wrote:
Otherwise, this game looks great on hardware. Is this your first 3D game? You’ve done a great job making lots of use of it!
Definitely can’t wait to try this again once it gets sped up 🙂

Thanks! This is my first time making a game with any kind of 3D depth, I think it turned out okay too! The real praise goes to Nyrator if you enjoy the graphics, since he did almost everything you see.

I’ll be sure to post an update when I’ve fixed the framerate issue!

Red Square has been updated and now works on real hardware. This has been tested by Jorgeche. For those of you who want to play it on your real Virtual Boy, now you can do that. The updated ROM is available from the official page. If you want to know what went into it, continue reading.

A lot of work went into debugging this issue from a lot of people, the following things about the game have changed on a technical level:

- Instruction Cache was enabled
- Wait Controller was configured
- VBlank period is now done via VIP interrupt
- VBlank interrupt is waited for using HALT
- Keypad polling was changed to initiate a hardware request at the start of a frame and poll the keys at the end of a frame
- FRMCYC was set to 0 on boot (as is done by commercial games) 

All of these changes didn’t fix the problem, but will provide a much greater battery life when playing the game. Specifically, changing the keypad polling method, and using HALT and the VIP interrupt. The real fix came from a very specific flag in the DPCTRL register.

The DPCTRL register has a flag called DPRST, which automatically resets the display (changing bits in INTPND and INTENB). I set this flag on hardware reset and never unset it. It turns out, this flag never gets unset. What happens when it remains set (it seems) is that every other frame is skipped because DPCTRL resets TIMEERR, FRAMESTART, GAMESTART, RFBEND, LFBEND and SCANERR in INTPND and INTENB. This was discovered when I was debugging retail games and found that their value for DPCTRL ($0302) did not match my value ($0303). My advice? Don’t set DPRST, manually write to INTCLR and INTENB instead of relying on DPRST, and if you do, unset it very shortly after.

A lot of community support went into narrowing down the problem and offering solutions for this bug. The people on the PlanetVB Discord server have been extremely helpful, and I’d like to thank Jorgeche in particular for his time, knowledge, and help in testing and offering solutions to the problem.