Awesome! I’ve just played through it for the first time (after not playing any VB games in months) and got ending B. It’s much harder than the original. I died at least once per level. Also, nice use of doors. 😉

cr1901 wrote:
If one wants to play VB games on their flash cart, they need to pad the ROM to some multiple of 2MB IIRC.

The ROM must be padded to the size of the flash memory. No more, no less.

I understand that it’s some sort of address decoding issue from VB CPU’s point of view, but what are the “rules” to ensure that the reset vector and the remaining code ends up in the correct place?

The ROM must decode addresses so that the reset vector (as well as the others if you use interrupts) is at FFFFFFF0. It doesn’t matter from that point on because your code can then jump to any address. The simplest case is if you have a 2^n-byte ROM; it can just decode the lower n bits.

What address does the CPU see and how does it translate to what address is presented on the bus of the ROM? Does the ROM just ignore higher bits of the bus?

Exactly. The CPU always starts execution at FFFFFFF0. The VB only decodes the lower 27 bits, giving 07FFFFF0. This is why the 07xxxxxx range is reserved for cartridge ROM. It’s up to the cartridge to decode the remaining 24 bits. A 2 MB ROM would normally only decode the lower 21 bits, so FFFFFFF0 is at offset 1FFFF0 in such a ROM.

Theoretically, it could also, for example, decode the lower 20 bits and bit 23, but then the two halves would only be contiguous from 077FFFFF to 078FFFFF.

Having the upper bits set is somewhat confusing, in my opinion, so I prefer a ROM to “start” at 07000000, even though it can (in the case of 2 MB) start at FFE00000. Faceball, for example, uses such addresses, but most (if not all) homebrews start at 07000000.

The ROM does not even have to be a power of 2 in size, though at least Mednafen requires it to be. A 3 MB ROM would, for example, be composed of one 2 MB chip and one 1 MB chip, use bit 21 to select between the two chips and the lower 21 bits to select an offset within the chip, with 0 being the 2 MB chip so that all 3 MB would be contiguous in the range from 07000000 to 072FFFFF.

I hope this answers your questions and that I didn’t make a mistake somewhere.

DogP has said that both dumping and programming is possible:

http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=26052#forumpost26052

As far as I know, only Mednafen currently has write breakpoints. Press Alt+D to enter the debugger, then Shift+W to set write breakpoints (separated by spaces).

-Can BGMaps be extracted from ROMS? How can I detect the BGMap structure in a file?

It depends on the game. If they’re uncompressed, you can spot them in a hex editor as they are made up of 16-bit values that are usually similar in range. In that case, extracting them would be easy, but the hard part would be finding the charsets.

-BGMaps contain RAM info, not ROM info. So is anyone familiar with how Wario Land loads its tiles, and if so can this info be extracted as well?

If the charsets are uncompressed, you can spot them with the VB Ripper Utility or the VeeBee Utilities.

If either of these are compressed, the best/easiest way to find them is to use an emulator and place a write breakpoint on addresses where charmaps and BGMaps are usually loaded. For charmaps, most games seem to use 78000, ignoring the uncontiguous areas at lower addresses (but note that any number of characters may be loaded at any address in character memory). BGMaps start at 20000, 22000, etc.; they are usually loaded so they take up the upper left corner of the BGMap segment if they don’t use it completely. Look at the memory map. Once you’ve found the code that loads/decompresses the data, disassemble it so you understand the format. Repeat until exhausted. 😉

Some emulators (at least Red Dragon) can also show you the contents of BGMap memory during execution, though taking screenshots of that and then editing them would also get tedious quickly.

This might help: https://www.vg-resource.com/showthread.php?tid=21526

[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 8 years, 10 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.