I loaded this onto my FlashBoy right away and began playing it. It is awesome! I think it is much better than the SU games. You gave a lot of attention to detail and the result is a high quality game. Ben’s graphics are very professional too. Bach’s music fits really nicely too, it’s much better than just sound effects.

I got to the end of Classic Fish with a score of 150. I love what you did with the credits. I still have to finish the other stages though.

I know you said you’re not going to change the game any more, but in case you change your mind and release updates, you should fix the background of Super Fish World (it jumps around a bit). A pause feature would be welcome too, unless it was omitted on purpose. And the score flickers when it is incremented, but that’s not so important.

That’s sad to hear. Will you at least release the source code?

Is that necessary? We already have Nintendo’s Virtual Boy Development Manual, which describes probably everything anyone would want. IMO, what we need is easy to understand documentation on the VSU and the VIP (for things such as scaling and rotation).

I don’t want to discourage you, but I don’t want you to waste your time rediscovering things.

Are you doing everything in assembly? That’s overkill (though you did mention wanting to learn how to reverse engineer…), we usually use C.

You don’t seem to have initialized the WAM. There is also a bunch of VIP registers you need to set to turn on the display. I don’t know what they do, since the library nicely hides the details away from me, but the libgccvb vbDisplayOn function does this before initializing the BRTx/GPLTx/JPLTx/BKCOL registers:

VIP_REGS[REST] = 0;
VIP_REGS[XPCTRL] = VIP_REGS[XPSTTS] | 2;
VIP_REGS[DPCTRL] = VIP_REGS[DPSTTS] | 0x0302;
VIP_REGS[FRMCYC] = 0;
VIP_REGS[INTCLR] = VIP_REGS[INTPND];
while (!(VIP_REGS[DPSTTS] & 0x3C));  //required?

Way ahead of you 😛

http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3649&post_id=8491#forumpost8491

But yours is much better.

Now, a more badass and even more VB-specific version would make use of the V810’s bitstring instructions. 😀

I’m not an expert on this, but it looks like you have used up all the WRAM (Work RAM), which is the RAM available for use by the game. It is 64K in size and accessible from 0x05000000 to 0x0500FFFF, then it is mirrored 255 times. Do you have any large static arrays in the code?

Here is version 1.1. Change log:

*** What’s new in this version ***

This version adds new features, such as level time editing and support for IPS patches. It also fixes bugs and improves the user interface.

Files created with version 1 will work normally with version 1.1. However, if a file saved in version 1.1 that includes starting position resources is edited and saved in version 1, starting directions in those resources may be lost.

The readme file has been updated to document new features. It also documents where in the Insmouse No Yakata ROM the data patched by InsmEdit is located.

The Example.imp file has also been updated to illustrate the new features.

*** Changes from version 1 ***

* IPS patch support.

* In addition to editing starting position, you can now edit the direction as well.

* You can now choose the music track played on each level.

* The layout editor can now shift layouts around the map.

* By pressing the middle mouse button or scroll wheel (whichever your mouse has), the position of the tile being pointed to in the layout editor will be remembered. You can then paste it into a starting position resource.

* The layout editor does not flicker anymore.

* Added the “Lamps” feature in the layout editor.

* Password indexes are now checked for validity. This applies to all resources that use them.

* The status of the “Grid” feature in the layout editor is preserved when editing different layouts. This also applies to the “Lamps” feature.

* The main window can now be resized.

* The readme file, if opened from within InsmEdit, will open to the right of the main window rather than over it.

* InsmEdit will now ask you whether you want to save changes to a modified patch when you choose “New” or “Open…” from the File menu.

* No more potential instability after opening a patch when a patch is already open.

* No more crash when choosing “Open…” from the File menu, then cancelling the resulting dialog box.

* No more crash when the resource limit is exceeded.

Attachments:

1. insmedit-1.zip

You could replace how the walls, floor, and ceiling look, but since they are mostly solid colors, there’s not much you could do.

Benjamin Stevens wrote:
Of course, if a programmer can find the sprites of the monsters in the game and design a patch to replace them with sprites of choice, there would be any number of possibilities for different enemy types. I’m not a programmer, so I can’t say for sure, but I think changing the sprites isn’t too difficult, while changing how the enemies behave would be much more difficult. Can a programmer on here verify that to be correct?

The monster charset begins at 663801 (decimal, starting with 1). I don’t know where the appropriate BGMaps are, but there are eight contiguous BGMaps beginning at 758009, which are loaded near the start of the game, so maybe one of them affects the monsters. However, remember that the monsters are made of parts – they can move their claws and they explode to bits when they die – so replacing their graphics will be harder than replacing normal sprites.

In my opinion, a more interesting hack would be to give each level or group of levels its own texture set (there is a lot of unused space in the ROM). The charset for the standard texture set begins at 696569, so we can use it as a template, and I already know where the level loading routine is, so it could be hacked to load a new texture set for each level.

Benjamin Stevens wrote:
If you like the idea of the first screen being able to be used for a simple title screen for any person’s new edition of the game, perhaps the next version of InsmEdit could allow a person to input their own title and name into the first screen of the game.

Maybe. But I know where many of the charsets and charmaps are, so it shouldn’t be any more difficult to edit the actual title screen. I think it would be very cool to have a full graphics editor in InsmEdit, but version 1.1 will only add IPS support, player direction editing, and level time editing, because it will take too long to release otherwise and I think your patch would benefit from those features.

I’ve played a few levels only to find that ASUN (layout 13) has no exit! But other than that, it’s pretty good. My only complaint is that because of the nature of the layouts, you have to turn very often and that causes you to lose time – this is why the Insmouse layouts mostly have straight corridors, even in levels such as JAZZ. I’ll include a level time editing feature in InsmEdit 1.1 to reduce this problem a little.

Do you think it would be useful to be able to put IPS patches into IMP patches?

thunderstruck wrote:
I always wonder if someone reads this.

I do. But I don’t comment… because there is nothing to comment on. The development of this game seems to be very smooth. Or maybe you just don’t tell us about those bugs that break the whole game and take hours to discover but are actually caused by one typo in the code.

Benjamin Stevens wrote:
Heh… yeah, that technique does sound about as time consuming as what I was going to do. One thing that I would also need for this is the exact location of each original level map within the 24 by 24 square of tiles. When I made my PDF Level Map document for the game, I was careful to ensure that the size of each level was exactly correct based on playing and pausing the game and carefully observing each map screen. However, I don’t know how close to each edge each map appears within the 24 by 24 square of tiles. Is there a way to bring these up on screen somehow? Also, I was wondering if someone already posted pics of that on this site somewhere. I thought I saw them before but I can’t remember exactly.

You could have just asked me to write a program to generate the layout pictures.

Anyway, I did just that and attached are the layouts in PNG format.

Attachments:

1. insmmaps.zip

I only know few things about monster positions, which I originally got from starting the game and running directly to a monster, writing down the position, then dying and repeating the process for each monster in a level.

However, since then I know of a better and more reliable way: use Mednafen’s debugger to teleport yourself to a position where you think there is a monster close (note: if you teleport yourself into the monster, you may be unable to move and will eventually get killed – but I have also seen cases where the monster simply moved away, so I’m not really sure).

First, freeze the game with Alt+A, enter (or exit) the debugger with Alt+D, once you are in the debugger, press Alt+3 to switch to the memory editor. Press G and enter the address 05003CFA. There are four bytes: the first two are your position (X, Y, same as when you edit starting positions), the next two are a copy of it (edit this too just to be sure, I don’t know why there’s a copy), and the byte after that is your direction (1 is up, 2 is down, 3 is right, 4 is left). Edit by pressing Ins and then typing the new values. Exit the debugger, then press Alt+R to resume the game. Turn around and maybe there will be a monster nearby.

I’ve tried searching for these coordinates in the ROM, but haven’t yet found any data related to the monsters. Hopefully that will be a lot easier when I have a more complete ROM map.

ROPE:
4, 17 (04 11 hex) – bright armless monster, facing up
10, 16 (0A 10 hex) or 10, 17 (0A 11 hex) – bright weak humanoid

ROAD:
20, 12 (14 0C hex) – bright armless monster, facing right (I think)
around 12, 12 (0C 0C hex) – dark armless monster
around 4, 19 (04 13 hex) – bright armless monster

LOVE:
around 22, 21 (16 15 hex) – bright armless monster
others unknown

Obviously, this is a time consuming process, so please post your discoveries for the benefit of others (it may also help me find the data in the ROM).

The References\Workshop section of the site has some guides.

I’ve never understood the need for a head-mounted VB. What’s the point if the VB is too fragile to be moved while being used? Not to mention it’s not true virtual reality either.

I think that if you can’t stand the original stand (pun not intended), the Lamp-O-Tron is the safest and most comfortable choice both for you and your VB.

Note: I have only ever used the VB with the original stand.

I’m surprised they even bothered to reply and didn’t just say “no”. It would be great if VB games were rereleased for the 3DS, even though I don’t have one, because it would generate more interest for the VB, and VB games never got the large audience they deserved.

Regarding point 3, I think the main reason why people buy Nintendo consoles is to play their games, so it makes sense that they don’t release games for their competitors’ hardware.

thunderstruck wrote:

Sounds like you are close to figuring out how the complete game works.

No, not really. I still know nothing about the monsters, the cutscenes (other than where some of their graphics are), or where the sound data is.

Would be great to be able to do a ROM hack that changes the complete game including graphics and sound and just using the game as an engine.

Do you think this is a better idea than creating an engine from scratch? Probably the hardest thing to get right is the renderer (Insmouse probably composes the view from BGMaps, since you can only see 3 tiles ahead of you) and the details like cutscenes.

Benjamin Stevens wrote:
That would be so great if you one day figured out how to edit the monster positions.

Indeed. In fact, all this time I’ve been trying to find them but ended up finding everything else instead.

Today, I found out how to edit the amount of time you get for each level, how much time you need to have left to get to the next upper level, and which music track plays on the level (there are 12 tracks in the game, I think). I also know where most of the character sets and some of the character maps are (fun fact: the ROM contains the graphics from “Sample Soft for VUE Programming”), but graphics don’t interest me because they don’t really add anything new to the game.

I’ve also made a disassembly of the code with David Tucker’s disassembler and figured out what some short routines do (this is my first encounter with assembly language on the VB), but I don’t know whether that’s even worth trying. There is a lot of code but if we figure out which parts do what, we can change how the game behaves (and also add features, because there is a lot of unused space).

Sometimes, I think about whether all of this is meaningful. The game is simple enough that a team of experienced homebrewers could recreate it. On the other hand, we can think of reverse engineering as a kind of archeology.

Since the game allows levels to have names that are 4 letters long, I’ve come up with the following names for the first four level maps that I already posted:

1. BRDO
2. TOAD
3. MRIO
4. LIGI

And here are the names for the next five level maps that I’ve created:

5. GMBA
6. KUPA
7. BZYB
8. BILL
9. ABOO

Shouldn’t you keep the passwords a secret? And I think it’s more in the spirit of Insmouse if the passwords are actual words, even if it takes a bit of thinking to associate them with levels. For example, you could use JUMP and PIPE: Mario was originally called Jumpman and Mario and Luigi are both plumbers.

I’ve noticed that some of your maps are 24 tiles big in one or both dimensions. This is a bad idea, because you will confuse the player when they get to the edge of the map. Try playing the TRAP level from Example.imp to see what I mean.

This inspired me to do some more research on Insmouse.

After reverse engineering for the last six hours, the only thing I’ve figured out is where the “next level” table is (it specifies which two levels come after each level) and I’ve discovered a weird table that can be modified to shift the layouts around on the map (well, that’s what it seems to do).

I’ve also improved my ROM map which I started making in May. Hopefully I will some day discover how to edit the monster positions.