I’m just using whatever came with the releases.

Easier my ass. The VSU’s many capabilities (interval, envelope, etc.) mean that probably everyone designed their own cryptic MIDI-like format. And, at least in Insmouse, the sound code is a mess of several routines that appear to have been written in assembly by hand and they exchange data in registers, so it’s very hard to follow because you don’t know which of the many registers of the V810 hold relevant data and which are just garbage.

I think the wiki should cover ROM hacking. There would be one article for each game, with links to released mods, eg. Benjamin Stevens’ mod for Insmouse. The mods themselves would be posted to the forums (maybe a special “mods” category) so the authors would be able to receive feedback.

I play mine the classic way. The VB looks way too fragile to me to be played any other way.

Benjamin Stevens wrote:

Lester Knight wrote:

i do recall that you mentioned 1 unused level was hiding in the rom? any chance you will include that level in your hack?

I believe you are recalling a similar statement from HorvatM for Mansion of Insmouse. He found the “DEMO” level of the game in the ROM, which is only used in the game for the opening sequence but isn’t actually playable, and you can edit the level and sort of play it using InsmEdit, but I think the level is still unbeatable and doesn’t connect to any of the other levels in the game.

The existence of the DEMO level was already known before I started hacking the game, though I don’t know who discovered it and how (by trying random 4-letter English words?).

There doesn’t seem to be any unused level in Faceball. The level layouts and their associated data are all close together in the ROM and there are 14 of them.

Finally, I’ve ported the game to the Soviet Union 2011 engine, giving it much needed features such as sound effects and difficulty and play mode settings.

This is the version that Protoman85 reviewed in his homebrew showcase video. However, there were some bugs in that version, so I did not release it at that time.

Attachments:

1. su10v1-2-1.zip

segagamer99 wrote:

If you’ll recall, this was back when the three rarest games were on the verge of having their ROMs released.

I assume the third game is Space Pinball?

No. The rarest three are Virtual Bowling, Space Invaders, and Gundam.

Ah, yes, The Cutting Room Floor. Great site. Here’s what I know:

Insmouse No Yakata:
There are unused graphics from Nintendo’s “Sample Soft for VUE Programming”: http://www.planetvb.com/modules/news/article.php?storyid=167
The automap charset has two characters (attached) that I’ve never seen and were apparently intended to show monsters on the map.
Also, the DEMO level might count. It’s seen in the intro but otherwise unplayable because although entering the password “DEMO” starts the level, you’re out of time before you can do anything. I’ve attached a map. The player starts in the upper left corner. The level has no monsters.

Virtual Lab:
There is an unused BGMap with a copyright message on it (attached). Also, Lisa (the girl to the right of the playfield) does not actually look like she does in the game (see picture).

Mario’s Tennis:
There are unused graphics intended for multiplayer: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=9411#forumpost9411

Attachments:

1. 

   insmousemapmonster.png
   

2. 

   vlcopyright.png
   

3. 

   lisa.png
   

4. 

   46.png
   

Wow, this is awesome! Looks like I’ll finally upgrade from gccVB 1.0.

Here’s a modified version of build.bat (I call it “mbuild.bat”) that can be used standalone from the command line, for those who already have an IDE set up. To use it, CD to C:\vbde\system and execute it with “MBUILD PATH\ NAME”.

—————————————-

@ECHO OFF

:: SET ENVIRONMENT VARIABLES (only for this batch file; do not affect the whole system)
SETLOCAL
SET PATH=%PATH%;C:\vbde\gccvb\make-3.81-bin\bin\;C:\vbde\gccvb\bin;C:\vbde\tools\rom\vbid-1.0-win;C:\vbde\libs\libgccvb
:: The libgccvb in gccVB 1.0 is incompatible with the one in VBDE. Remove the first part if you’re not upgrading from it.
SET C_INCLUDE_PATH=C:\gccvb\include;C:\vbde\libs\libgccvb;C:\vbde\libs\pvbfw;C:\vbde\libs\vbjaengine

:: CHANGE TO PROJECT DIRECTORY
PUSHD %1

:: PRE-CLEAN
IF EXIST %2.vb DEL %2.vb
IF EXIST %2_pad.vb DEL %2_pad.vb

:: COMPILE
make.exe -f C:\vbde\libs\makefile TARGET=%2 –quiet

:: SET ROM HEADER
SETLOCAL EnableDelayedExpansion
FOR /f “tokens=* delims= ” %%a in (%2.vbh) do (
SET /a N+=1
SET v!N!=%%a
)
vbid.exe %2.vb “!v4!” – !v6! !v8! !v10! > NUL

:: POST-CLEAN
DEL %2.o

:: CHANGE TO PREVIOUS DIRECTORY
POPD

I’d write such a program, but I think there should be a way to connect the VB to a computer. This way, you could save and load compositions, use a keyboard to edit music, or use the VB as an instrument by letting a computer control it.

That will be tough to fix. Right now I can’t think of anything that might be the cause.

thunderstruck wrote:

MineStorm wrote:

I have no idea if this is technically possible. It is not like you can simply flash two VirtualBoy games on one card.

Both ROM’s together should be under 2MBytes. So, couldn’t you put in an option screen that lets you decide which version to run (when you first boot the cart) ?

I thought about that as well. I’m not sure if this would break the absolute addressing though… I guess someone smarter then may would have to do this.

Joining two ROMs into one is indeed possible, though it’s not easy and the results aren’t always perfect.

Here’s a ROM that contains GameHero and Fishbone. When it starts, both displays will be blank. Press the L button for GameHero or R for Fishbone.

You might experience some glitches because most of the code patching was done by a program I wrote, and it’s pretty much impossible for a program to guess everything correctly. Also, the games will overwrite each other’s data on the SRAM and I didn’t attempt to correct that. I also haven’t tested the ROM on hardware.

For Faceball, you’d probably have an easier job because the ROMs would be similar and probably nothing too serious would happen if one game tried to read the data from the other game.

Attachments:

1. jointest.zip

My favorite game is Insmouse. I bet you could never tell! 🙂

Seriously though, Red Alarm is great. It’s the first game I played on the VB. The graphics blew me away and they still do every time I play it. Unfortunately it gets much less interesting once you beat it.

I agree that Galactic Pinball is the best pinball game ever made, though I admit I haven’t played many. It’s very well designed, the unique bonus games are very cool, and each table has its own interesting concept which sets it apart from the other tables.

I can’t say much about other games because my collection isn’t very large and I haven’t finished Wario Land yet.

Please credit me if you’re going to use my sound engine.

It’s called “InsmEdit”, not “InsEdit”. And success? There’s only been one patch released so far. Go make some more! 🙂

I might have a go at hacking Faceball when it’s released, but wouldn’t that piss off everyone who bought a cartridge? Then there’s also the issue of DanB’s Ballface. His effort shouldn’t be dismissed.

Congratulations! Insmouse is IMO a very underrated game and really fun to play (though I don’t own it myself because of the price). When you get tired of the standard levels, be sure to check out Benjamin Stevens’ mod for it, which is called “Mansion of Insmouse – Mario Madness Edition”. Or, make your own levels for it with my editor, InsmEdit. 🙂

The amperage on mine is 1.4 A (with a voltage of 9 V) and I’ve been using it with the VB for four years, so you’re safe.

Yes, I think the Wiki should become a collection of tutorials. I’ve been following the evolution of GP’s document since the beginning and he made it pretty clear that it is only a description of the VB’s hardware and not a programming guide.

thunderstruck:

Thanks. I plan to release all the information I’ve collected about this game some day. Besides what InsmEdit can edit, I also know where most of the charsets and BGMaps are, and I maintain a ROM map, a WRAM map, and a commented disassembly to record everything I discover, though almost everything except what I’ve written here is still a mystery to me.

I don’t think I’m experienced enough to guide others to ROM hacking. Insmouse is actually the first game I’ve hacked, though I’ve been exploring things with a hex editor before. Romhacking.net seems to be the place to go for pretty much everything related to ROM hacking, though I myself don’t use that site because VB games are pretty much like nothing else, and even the games themselves don’t have much in common.

As you can see in the first post of this topic, I couldn’t have begun without indirect help of DogP and KR155E, so I don’t know where you should begin.

There are some common procedures though. For example, if you want to hack data, it makes sense to think how you would have done it if you were programming the game. For example, positions of things are usually stored as a pair of X/Y coordinates, and indeed this is how they are stored in Insmouse – though the player positions are bytes and the monster positions are halfwords. If you want to hack code, it helps to make a WRAM map by comparing WRAM dumps, then make a disassembly and search where the code references the variables in WRAM. Then, you put a breakpoint on that location, play the game, and if you’re lucky, the game will stop at the breakpoint. For graphics (only charmaps, though I plan on writing a program to extract BGMaps from ROMs), I recommend the program “VeeBee Utilities” which can be found on this site. Even if you’re not interested in graphics (I’m not really), they take up a lot of space in the ROM, so you should at least know where they are so you don’t mistake them for other data (though they’re usually easy to recognize).

You should also have at hand the official V810 manual (for when you’re not sure you’re interpreting the disassembly correctly) and the PVB developer wiki (for the memory map and data structures).

If you need help, just contact me and I’ll help you as best as I can.

Ben:
OK, though I don’t know when the next version will be released.

Maybe now is the time we make one big patch as a community like KR155E suggested on page 1? Just think about it, some would do the levels, others would do the graphics, and if others are interested in reverse engineering, maybe we could even change some of the code. I’d like to realize that idea of mine about different levels having different textures. The monsters could be changed too, of course, but there are much more of them and not much can be changed.

I have discovered how to edit the monsters.

First, I had the brilliant idea of finding out where in the RAM the player’s health is stored. I decided to search for the health because there are only three places in the game where it is modified: at the start of a new game, when you pick up a heart, and when a monster attacks you. I went to a monster with 2 hearts, dumped the WRAM to a file, let it attack me, dumped the new state of the WRAM to another file, then searched for a location where a byte changed from having the value 2 to the value 1. There was only one such place, and testing confirmed that it was indeed the health. Fun fact: if you modify that variable, you can have more than 5 hearts. Up to 7 icons will show, with two being behind the ammo icons.

I then searched the disassembly and discovered the place where the health is decremented. It turned out to be a function that controls monster attacks. I put a write breakpoint onto it in Mednafen and discovered the place in WRAM where the monsters are. Each monster takes up 56 bytes and there is room for 6 monsters. To confirm this, I put a write breakpoint onto the first byte of that space and reset the game. The first function to write to it was the function that loads the monsters from ROM to WRAM. I looked at the disassembly of that function and found three places in ROM which are related to the monsters.

The first is an array that specifies which kind of monsters appear in each level. For example, the monsters in ROPE are of a different kind than the monsters in HYDE. There are four kinds, and only one may appear in each level, possibly because of memory limitations. Interestingly, the kinds are numbered not in the order in which they appear, but apparently in the order in which they were created.

The second is an array of pointers. There is one pointer for each level, and it points to the monster list for that level. Each monster has a starting position, a size and color (large and dark, large and bright, small and dark, or small and bright), an unknown byte that’s probably the starting direction, and two unused bytes (probably padding).

Apparently, they were trying to save space in the ROM by using pointers instead of a fixed-length monster list, but that is both pointless and ironic, because there is a lot of unused space in the ROM, and 16-bit values are used pretty much everywhere where they could have used 8-bit values. The layouts also only store one tile per byte, where they could have stored at least two, or even four if there wasn’t a special tile type for the exit. And the monster coordinates use four bytes, even though two would have been enough and then the two padding bytes wouldn’t have been needed. Each monster list is also terminated by a special entry, which itself takes up 8 bytes. However, two programmers are credited for this game, so maybe that explains the inconsistencies. Still, I should probably be thankful for the game’s simplicity, because that also makes it easy to hack.

The presence of pointers makes it a bit tricky to add new monsters to the levels without breaking other levels. So, Ben, if you want to add monsters to your levels, you can send me a list of monsters for each level, and I can make an IPS patch for you, until I figure out a simple way to add monster editing to InsmEdit.

EDIT:
Guy Perfect has just suggested that I could just change the monster list pointers to unused space in the ROM. That should work.