[HorvatM]

Since no one else wants to have a shot…

I’m not a hardware expert, but I know that no known VB game uses any kind of bank switching. There’s no need for it as ROMs can be up to 16 MB in size before bank switching would be needed (or 32 MB by using the address space meant for additional hardware, though it wouldn’t be contiguous), and if any game did use it, it wouldn’t work on a FlashBoy.

I’m curious what “registering as a 512K file” means, as there is no way for the hardware or software to know how large the ROM is, so if you tried to dump a 512K ROM as a 1 MB ROM, you would just get two identical copies of it (someone correct me if I’m wrong).

• This reply was modified 7 years, 5 months ago by HorvatM.

I don’t know what the last version is either, but Archive.org seems to have them:

https://web.archive.org/web/20141121055013/https://developer.oculus.com/downloads/

The DK2 came out in July 2014, so at least the versions from November should still work.

Shouldn’t the SDK be enough for straight C++ development? There’s also a book and its example code. That’s just what I found with a quick search; there’s probably more stuff out there.

I’ve been briefly exposed to Unity and I think it sucks and is full of bugs. You will probably find it too complicated if you’re used to low-level development.

As for games, there’s a bad Insmouse clone with cheap jumpscares; an old demo of it runs on the DK1. The famous roller coaster demo (or at least an old version of it) and other demos also run on it, but that’s all I remember.

If you can find a library that targets more than one VR headset and/or operating system, then I’d be interested in that too, though the VB is currently all I own. 😉

When presenting the VB to people seeing it for the first time, I have sometimes had to explicitly say it’s a stand-alone system, not a peripheral. With Oculus Rift etc. being so popular nowadays, I guess that’s what people think the VB is without doing any research.

I have, twice. The first time was in an emulator, without cheats or saved states. At that point, I had been playing it for about two years, so it really depends on luck. The second time was on real hardware with a FlashBoy.

I compiled the emulator with Clang on Haiku (haven’t tried anything else yet) and it works just fine, which is a nice improvement from the previous version that compiled and then didn’t respond to input. With “-Weverything”, it gave a lot of warnings, and while I’m sure you would disagree with many, I think you should try it out for yourself.

The code looks OK. The symptoms you’re describing sound like the column table is not initialized. VBDE’s startup code should initialize it automatically (unless it doesn’t do that anymore), but you can manually call vbSetColTable() and see whether that fixes the problem.

I got Reality Boy to compile with Open Watcom. The zip file includes the executable and source code. It should be functionally equivalent to the DJGPP version.

If you want to compile it yourself, get the official source code and apply my changes. You can get compilation instructions for Allegro on my site.

If you only want to use it, you only need the EXE files.

Tip: use -sclscr 1 to disable screen scaling. This will improve speed.

Attachments:

1. rbwdos.zip

Haven’t we had this conversation already?

As for the existing emulators: I think they’re decent, but as Thunderstruck pointed out, they each have their annoyances and better debugging/reverse engineering features could be added.

A big problem for me is portability. Mednafen, as far as I know, requires GCC, a POSIX/GNU environment, and a whole host of dependencies to compile, and it’s been 2 years since Ryphecha told me the DOS port would be done “soon”. (And before someone asks why I care about DOS, let me remind you that we’re developing software for a not very popular 20-year old game console, so why not?) The last time I tried to compile it on Haiku, it failed because of some dependency error (libcdio? I don’t remember) and I gave up after that because I consider configure scripts and seas of makefiles a sign of brittle and badly engineered software. And the last time I looked at the source code, it was sparsely commented, so there goes any chance of me improving it (and let’s not discuss licensing).

Reality Boy and Red Dragon should in theory compile with any compiler that can also compile Allegro, which is all they depend on. I have compiled them for DOS, but so far only with GCC/DJGPP. I got as far as compiling Reality Boy on Haiku, but it didn’t accept input; not sure whether the problem was in Reality Boy, Allegro, or Haiku, but it just shows that depending on a specific library (even if only one) can make or break portability.

If I understand Guy Perfect correctly, he wants to make a callback-based emulator that could use any user interface and run anywhere. Imagine having an IDE/compiler that uses this emulator and lets you not only debug code, but change it and have the changes applied in almost real time. Sounds cool (if utopic), no?

As for the PC-FX: sure, let’s do a PC-FX emulator while we’re at it. Mednafen is a usable emulator (but see above), Xe is dead, and Magic Engine FX seems to be targeted only at players; I hoped that my work on homebrew PC-FX development would encourage emulator developers, but I might help if that’s what it takes.

blitter wrote:
Do tell! Shifting my ROM up to that area costs me nothing, so if there are extra benefits I’d love to know what they are.

I can think of three:

1. Your interrupt vectors can consist of a single JR instruction.

2. You can load certain ROM addresses into registers with a single MOVEA instruction. Of course, this requires using a compiler/assembler that does not always mindlessly generate MOVHI/MOVEA pairs. MV810ASM doesn’t. 😉

3. If you arrange your data really carefully, you can load some of it (e.g. lookup tables) with a negative displacement from register 0.

I had never used C before I started programming for the VB. It is definitely possible to learn both at the same time, but it takes a while.

It is indeed possible to write a whole game in C. I would still recommend learning assembly once you’re comfortable with C to get a better understanding of the whole system, but it is not strictly necessary. As long as you draw your graphics with the VIP (most games do), the V810 is fast enough for just about anything.

Don’t get discouraged, but also don’t set your hopes too high. It is unlikely that you will be able to port a game from a modern platform to the VB (or maintain two versions in parallel), but the reverse can be done with some discipline.

ElmerPCFX wrote:
I’d like to move the Frame Pointer to R2 (right next to the Stack Pointer in R3), and I’d like to use R5 to replace the V850’s EP register … and basically gain another 32KB of fast-access variable space, particularly for use as thread-local variables.

I don’t see a need for a frame pointer, and neither did NEC apparently.

And you can already access a 64K range with a single register by using negative displacements. Commercial VB games set register 4 to 0x05008000 and use it to access global variables anywhere in the WRAM (which is 64K long).

blitter: Can I ask what your thinking was behind you 2011-11-23 patch to change the HARD_FRAME_POINTER_REGNUM from 29 to 25?

Do you have an example of whatever the problem was that this was designed to fix?

Bitstring instructions, probably.

Mine doesn’t mute either. I always thought it was just another quirk like the inevitably glitchy displays and the fragile stand, caused by bad design and/or manufacturing.

Benjamin Stevens wrote:

KR155E wrote:

Did anyone notice how page 39 refers to Mario Clash as Mario Smash (bottom left)? Theories anyone?

Dang… I hadn’t noticed that before. “Smash” is certainly a vastly different word from “Clash” to be just a typo. Hmmm… Perhaps there is, indeed, the possibility that “Mario Smash” was going to be the title at one point, but when they went through the catalogue and updated everything to Clash, they forgot to update the one on page 39.

I don’t know where the footage is from, but see 6:41 of this video:

http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=6412&forum=1&post_id=34519#forumpost34519

It just begs to be scanned somehow. The scans we currently have have the Duracell sticker and a few wrinkles.

DogP wrote:
But getting the USB link just right is really the main reason for the whole delay.

Would it be easier/cheaper to make a RS-232 version (if the VB can even do one of the standard speeds) and have everyone buy their own adapter if needed? They’re quite cheap.

125 mm × 125 mm × 23 mm.

He’s obviously saying that to make the Rift appear better. Wasn’t VB criticized for being too expensive? The Rift costs even more and it requires a powerful computer to run. Sure, it is an impressive achievement but far from perfect.

We have a good thread about it:

http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=30071#forumpost30071

The proper way to produce silence is to use PAU; the DoSounds function temporarily sets the volume to 0 when it encounters that value. But yes, several other constants (such as C_0) in notes.h have the same value (0) since apparently the VSU can’t produce anything below DS2 or above C_9. That file was created by DanB; I haven’t done any tests myself, so I don’t know whether it’s totally correct.

Insmouse no Yakata fan page and reverse engineering information
http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=33477#forumpost33477

Virtual Lab reverse engineering information
http://matejhorvat.si/en/vboy/vlab/