Greetings!

The emulator I started writing about 5 years ago, Vue32, is still not complete (sorry about that! I’m a busy person!) but it has seen a little bit of work recently. PVB currently has a placeholder for it: http://www.vr32.de/modules/tech/index.php?sec=emus&eid=vue32

I’ve decided to change the name to SoftVue and rework some problem areas in the code. I’ll create a Murcurial source code repository for it, so at least there will be that!

The good news is that it was a piece of cake to update the old code for Windows to run on OS X. That’s just the beauty of writing portable code!

The bad news is that it still doesn’t emulate any part of the VIP. Just basic NVC emulation.

My plan is opening one of my Virtual Boys (as soon as I can get a really long inverse torx driver or hack up a flat head screw driver) and attach a logic analyzer to the VIP. I’ll be able to get a fair idea of what’s going on inside it just be watching what kind of I/O operations it does (especially WHEN they occur). I can get pretty close to cycle-accurate emulation armed with this info.

So has anyone done that, yet? Any graphs out there showing VIP I/O timing? How about VIP pin-out? Or ultra-high-resolution photos of the server board? I still can’t get my VB apart because of those two ultra-deep screws, but I imagine it would be pretty easy to trace [most of] the pins visually.

So, why cycle-accurate Virtual Boy emulation? There’s less than 30 games that one would ever need to emulate, right? Wrong! VB homebrew is still in its infancy, but it will get better. And it will get better faster if it has good information.

The VIP is still relatively unknown. Reality Boy emulates it almost randomly. I hacked on Red Dragon’s code that updates the XP and DP registers, trying to make it logically update them similar to the VIP hardware, but this was clearly useless. I was basing my information on a small test program I wrote that sits in a hot loop, waiting for the registers to change. So accuracy is non-existent, I just wanted to approximate the changes seen on *that one program*. It would be nice to understand more clearly what the chip is actually doing.

What I want to focus on is the pixel processor (XP) portion of the VIP. The display processor (DP) is typically stable so it will display two 384×224 pixel screens at 50 Hz. But the DP can also be used in ways that achieve “special display effects” like a wavy screen. Not very high on my priority list…

XP, on the other hand, is what does the actual drawing: It takes the worlds, backgrounds, objects, and chars, and conglomerates them into actual pixels that are pushed to the frame buffer, 8-pixels-at-a-time. The DP then displays the frame buffer directly.

The question is, how long does it take, after a display frame (FCLK) is asserted by the server controller, for the XP to begin pulling world attributes? How long does it take to parse the world attributes? How long does it take until it pulls the associated backgrounds? How long does it take to parse the background attributes? … etc. Until we have a complete picture of the XP going from the beginning of a frame to the completion of drawing a very simple world setup to the frame buffer.

And then, make a more complicated world setup, and verify any changes in the timing. During this time, the VIP will be asserting its precious XPSTTS flags.

Then do the same thing on the DP, under various XP loads.

Nice to see you around again. You’ve definitely got an interesting round of tests ahead of you, if you decide to go through with this. IMO though, I’d study the official dev manual and functionally emulate it all, with a placeholder for some cycle counts to be computed from real world measurements.

There’s a lot of detail in the document, which would probably be more useful than trying to track down every detail from measurements. Off hand, the things I’m pretty sure that aren’t in the document are how many clock cycles it takes to process worlds, and memory refresh timing. It does tell you the number of (NVC) waits for memory accesses, and looking at the flow chart on 5-20-1, it seems like those cases (parameterized by sizes) are what you’d want to characterize.

I’d guess that most things that could be done in one clock cycle are done in one clock cycle (like parsing parameters), and that the real delay on those are the memory read cycles.

And by server board, I assume you mean servo board? I took some high res pics of the front and back, though they’re ~4MB each, so I can’t post them here… if you PM me your email addy, I’ll send them over. I could also send some of the motherboard, though it’s not completely in tact (I’ve pulled a few chips and stuff off over the years 😉 ).

Anyway, let me know if there’s anything you need… I may be able to help.

DogP

Hey, Para! Great to have you back in the VB scene :thumpup:

Welcome back, Para!

I like RB for what it is, but I’m glad to see you’re back to working on a new emulator based on modern technology. (Allegro is nice, but it is getting a bit long in the tooth…) Hopefully, with SoftVue using SDL, it’ll even be playable on my crusty old PC 😀

Thanks, guys.

Pat: I’ve looked over the document about 100 times over the years, and peering into it again has refreshed my memory quite a bit. It still doesn’t contain the kind of information I’m looking for. Funny how written documents are static, like that… The closest it comes to explaining any timing information for the XP is on page 5-19-2:

When SBOUT is set to 1, it maintains that status for about 56 µsec.

That’s good to know, but it doesn’t say how long you should expect it to maintain a status of 0. 😉

Page 5-20-1 also has some useful info (heck, the whole document is useful!) but it’s not quite enough to fully understand the XP’s inner workings.

And yes, I meant the servo board; honest mistake, silly typo.

With my DosBox-parallel port hack project finished (I used it to kill the hardware after successfully interfacing with it! Yay!) I can focus on VB more. At least, until my prototyping boards come in, then I’ll be working on N64. (See! I told you I was busy…)

Page 5-20-1 also has some useful info (heck, the whole document is useful!) but it’s not quite enough to fully understand the XP’s inner workings.

Have you looked at the main Virtual Boy patent? http://www.vr32.de/modules/patents/?06
I don’t think there’s any timing info, but it does contain a more detailed description of how the hardware works.

With my DosBox-parallel port hack project finished (I used it to kill the hardware after successfully interfacing with it! Yay!) I can focus on VB more.

I sympathise; last year I accidentally killed my PlayStation Action Replay by plugging it directly into my PC’s parallel port, instead of the ISA interface card.

Patents can be very useful … I’ll have a look. Hooray for breaking international patent law reverse engineering!

The hardware (PSX XPlorer FX) isn’t dead, but the flash ROM on it is corrupt, now! I put Caetla 0.37 on it which worked great. But then it wouldn’t let me restore the original XPlorer ROM. I guess there’s always X-Flash, which “can be used for repairing broken Xplorer cartridges.” Perfect.

If you plan on making a VSF (Virtual Boy Sound Format), I got dibs on it. Good luck on your emulator.

DogP has already come pretty close in that regard.

Oh fuckery! Then I need to contact him.