Thanks, much appreciated.

And yep, that seems very wise. For one, I’ve never done any Virtual Boy hacking before or really any assembly hacking on this scale. I’m basically learning as I go doing these patches. Plus I have barely any familiarity with the games themselves. I had fooled around in Mednafen back in the day, but really only played the games properly since the release of Floogle’s Red Viper for 3DS. Add to that that as far as I know, only you (with a HyperBoy) and speedyink (with a HyperFlash32) have tested any of these on real hardware and it’s a recipe for disaster. 😀

With apologies, I’m mostly thinking out loud in this post.

I’m learning two things from this. For one, many of the unused bytes in your save are FF, when the first thing I do upon boot is clear out SRAM by replacing it all with 00. My original method of clearing out SRAM was to write “four” (but two on Virtual Boy) bytes at a time using a st.w (store word) instruction, but it looks like that’s not actually clearing out the SRAM as intended on real hardware. I’m guessing that every byte needs to be written out individually, using a st.b (store byte) instruction. That said, this doesn’t explain your score not writing out successfully, since those are written with st.b.

Secondly, your save is definitely completely missing your high score, as if it was never written out at all, or else was replaced with the original score after the fact. The only intended way for scores to be erased is with the L + R + Left D-Pad Down + Right D-Pad Down combo on the title screen, which should erase the entire SRAM back to 00 before starting over (writing all of the default scores and config settings back into SRAM again) but as discussed may have been failing on real hardware due to use of st.w.

This is definitely a tough one. In writing out the scores, I’m making certain to store them at 2-byte intervals per the limitations of Virtual Boy SRAM. But the high score table is completely untouched in your save, it’s identical to the one that gets loaded in on first boot with all of the pre-loaded default scores/initials. The fact that these are unmodified but your game progress is still visible (I can see you beat one Area then chose the bottom path and picked up Speed, Power and Health upgrades along the way) seems to indicate that the new initials, score and area/level were never written out to SRAM at all. Obviously this works fine in emulation; I even tried to simulate your situation as closely as possible by matching your exact score so that I got the 9th slot, etc.

The way the game works, the different score bytes are actually written out at slightly different times: when you Game Over, the game writes your new score into the table and moves the other entries down the list, then writes the Area where you hit Game Over and moves the other areas down the list, then writes the specific Stage where you hit Game Over (and does not move the previous Stages down the list, this is an original game bug from 1995 that’s fixed in my patch), then it writes three blank spaces (literally the normal ASCII space character like the several hundred in this post) into the high score table. Then, once the game moves to the high score screen, it finally writes out your initials as you enter them over the space characters that were previously written out.

In your save, none of this has worked: the score, Area, Stage, blank initials and real initials have not been written out to the save at all. So not just one thing has gone wrong, but five things. Perhaps there’s some situation where the score is written out via a different code path than the one I’m modifying to write saves into SRAM, so the new scores write out to RAM but my changes to copy them to SRAM are never reached. But looking at the full disassembly, there’s only two places where the high score addresses get written out: when you get a new high score, and when the game is shifting the old scores down the table to accommodate your new score and I’m patching both of those to write to SRAM. Certainly, a matter that requires more investigation.

For now, I’m attaching new patch versions for all eight games I implemented saving for (i.e. no Golf, since I really just restored T&E Soft’s save support–none of the actual save reading/writing there is mine). Really the only thing that these do differently is to initialize (i.e. erase) saves in a way that I hope is more agreeable on real hardware. There shouldn’t be any noticeable differences in terms of bug fixes barring some edge cases, e.g. Vertical Force might have been bugged on real hardware due to the way I was setting the default best scores/times, but you have to beat the entire game to see the high scores, so it’s a pretty difficult one to test even via emulation.

Obviously I don’t expect you to test all eight of these patches; like I said, there should be no difference for most of them. If you wouldn’t mind though, I’d be interested to see a fresh save from any one of them, though. By fresh save, I mean deleting any older save either via whatever mechanism is available on flash carts, or the L + R + Left D-Pad Down + Right D-Pad Down combo included in most of the hacks–Jack Bros. doesn’t have it, so not that game. That would allow me to confirm that saves are at least being initialized correctly, but for now that won’t necessarily bring me any closer to figuring out what’s going wrong with high score saving in Space Squash.

Speaking of Space Squash, I’ve also attached a cheat patch here just in case it’s useful to you in testing. It’s what I’ve been using during development and makes all matches start with a 2-0 lead and all enemies (including bosses) start with only 1 HP, so with a bit of luck, you can make your way through the stages a bit quicker.

Attachments:

1. jack-bros_vb_save-support_v1.5.ips
2. mario-clash_vb_save-support_v1.3.ips
3. red-alarm_vb_save-support_v1.4.ips
4. space-squash_vb_save-support_v1.1.ips
5. vertical-force_japan_vb_save-support_v1.1.ips
6. vertical-force_usa_vb_save-support_v1.1.ips
7. v-tetris_vb_save-support_v1.1.ips
8. waterworld_vb_save-support_v1.1.ips
9. space-squash_vb_cheats.ips

Oh I see, very interesting. I don’t really know how flash carts work, is it possible for you to share your save file? It would be useful to be able to see if the scores are there in the save but just not showing up in the game, or if they’re wrong in the save as well.

EDIT: I also just noticed a bug in saving the Area/Stage where a score was achieved which I’ve fixed on GitHub, but this shouldn’t be relevant to whatever made your score vanish entirely.

Thanks yet again for all your testing. Really odd the issue with mine and HorvatM’s patches in conjunction. I’ll have to look into it some more. For now, I’ve published the next set of updates for Red Alarm, Space Squash (same as the version in this thread) and V-Tetris.

Ironically, the Red Alarm patch is aimed at handling the “high score protection” feature I was talking about earlier when used in conjunction with HorvatM’s patch, but it doesn’t (or at least shouldn’t!) do anything to fix their actual incompatibility. In older versions of my patch, I was checking if the user had pressed Select 60 times, the same way the base game detects that debug mode is active. Now, I’m specifically reading the byte that says how many times you need to press Select, so even if that value is hacked to 15 or 90, it should still work. But again, this doesn’t resolve whatever is going wrong in terms of them actually working together.

Re: Space Squash, which high scores are you looking at specifically? I deliberately don’t save your current score when saving and continuing because that would be easy to abuse to get a much higher score than you actually earned. Instead, scores only get saved when you game over (or finish the game) and enter your initials. The high score table shows up if you sit on the title screen for a few seconds looking something like this:

When you Continue a game from the main menu, your score will always be zero. I’m open to changing that in an update, though. The problem is that allowing you to keep your score when Continuing would basically make all scores meaningless. Did you achieve that by never losing, or by losing a bunch of times and continuing over and over until you did well? Maybe there’s a decent compromise solution here, like your score gets dropped to zero if you run out of Retries, but otherwise it carries across the save? People could still exploit it by just shutting off the game before running out of Retries, but it’s a single-player game so it doesn’t really matter if people want to cheat their high scores.

Good to know, thanks. Do you know if it’s definitely the combination of both patches together that breaks it? I can’t find any way that HorvatM’s and my patches interact, but perhaps I broke it in my patch even without HorvatM’s?

I just cleared Space Squash yesterday and yes, a save feature would be great, but I assume this will only be highscore saving, and not progress?

Both, actually. I have a test build currently that I think is probably ready to go on GitHub, it might be up there already by the time you read this, but if not, here’s the latest: Space Squash saving test

Each time you beat an Area, it saves your game, so if you run out of retries or shut off the console at that point, you can pick up again from the start of the area. This does make the game quite a bit easier since Retries only need to get you to the next Area instead of all the way through the game, but it was the compromise I arrived at between convenience and making the game too easy by e.g. saving every time you beat a single level, which would make the game trivial.

One side-note: if you combine your Red Alarm Save Patch with the Single Press Debug Menu patch the debug menu does not work.

That’s interesting. I did look at HorvatM’s patch and we never touched the same areas of ROM, so I just assumed it would be fine. Testing out both patches running together in Mednafen, I can still pull up the debug menu without issue with L + R + Select + A during gameplay. The one issue that will definitely occur is that my hack disables high score saving while debug mode is active (so you can play around in debug mode without wrecking your “real” high score) but my check relies on the original unmodified behavior, so it won’t work with HorvatM’s patch (i.e. debug high scores will save over your real score). But that’s pretty secondary if the debug menu isn’t working at all on real hardware. I can’t really imagine what would cause that since I didn’t change the debug menu in any way in my hack. I have been meaning to go back to Red Alarm to make the score-protection feature handle HorvatM’s change, but it might need more work if there’s a bigger issue at play here.

EDIT: Just for a bit more info, in in terms of the debug menu not working, does the explosion sound effect play on the title screen to indicate that you’ve enabled the debug mode, or is there no response whatsoever when you press Select?

Excellent, very glad to hear that. Much kudos to you for helping to get that resolved.

GitHub has been updated with the Jack Bros. v1.3 patch (identical to hardware-test-3, no need to patch again!) as well as new patches for Vertical Force (both regions) and Waterworld. If we include the six games that already had saving support from the factory, this brings us to more than half of the officially released Virtual Boy games:

3-D Tetris, Galactic Pinball, SD Gundam, Teleroboxer, Virtual Boy Wario Land and Virtual Fishing with official saves, plus Golf, Jack Bros., Mario Clash, Red Alarm, Vertical Force and Waterworld via hacking. 12/22 games!

Which reminds me …

PS: are there any other games where save features could be included?

I forgot to answer this the other day. While I’m absolutely not guaranteeing anything since I haven’t so much as looked at their code yet, the games I’m personally most interested in looking at from the remaining titles are Space Squash and V-Tetris.

Space Squash looks like it will probably be somewhat difficult. From what I’ve seen, there’s not any kind of built in menu where you can manage progression like Mario Clash already had, so I’m not sure how continuing a saved game would even work, assuming I can figure out saving progress in the first place. I’m definitely less confident I’ll be able to do anything for that one. On the other hand, V-Tetris shouldn’t be too complicated, since it already has high scores and a place on the screen to display them. In that case, it just needs the ability to store and retrieve those scores from SRAM.

I did briefly look at Space Invaders, but that game’s code was such a mess I decided to move on to other games. I might come back to it eventually, but I only really looked into it at first because it seemed simple. Looks can be deceiving! It’s difficult to follow the program flow. Instead of calling functions “normally”, the next address in code gets stored on the stack (a part of memory that’s always shifting and changing) then pulled in by another function whose job it is to jump to it. Tracing things backward to find how a function came to be the one that’s running is really confusing.

Beyond that, the other games with password save support (Insmouth no Yakata, Panic Bomber and Virtual Bowling) all seem like they would be possible to adjust to at least save your current password, like the Jack Bros. patch used to before the save menu was added. I don’t now how bothersome the passwords are in any of those games though, so I’m not sure whether I’ll get to them currently.

Somebody asked me about Teleroboxer, but that game has battery saves already, so I’m not sure what I could add there.

This leaves a few games I don’t really have much interest in looking at: Mario’s Tennis, Nester’s Funky Bowling, Virtual Lab and Virtual League Baseball. That last one technically is another password-save game, but I personally find it one of the least enjoyable games on the platform, so it’s tough to get motivated to look at it. The rest, I don’t think would really benefit that much from saving, since they don’t really have much to save or progress through. I’m not ruling any of them out, they’re just at the bottom of my list currently.

Bummer, but thanks for testing.

I’ve attached another version if you wouldn’t mind; I’m taking a different approach this time. I’m still reading input right at the start before the warnings have shown, but I’m running my check after what I think is the game initializing the input registers, so this should be like reading input at any other time during the game. It works fine in emulation!

Thanks again for your patience in helping resolve these bugs.

Attachments:

1. jack-bros_vb_save-support_v1.3_hardware-test-3.ips

Intriguing, thank you. I don’t really properly understand how the Game Pad works, but the Tech Scroll says all kinds of stuff about latch signals and things that need to be set to receive input values. I don’t know anything about that stuff and just reading the input registers works at any time in emulators, but it seems like there’s supposed to be some setup that comes first on hardware.

I’ve just made a couple of changes which try to copy what Jack Bros. does natively to initialize the Game Pad, so if you wouldn’t mind I’d love to hear if either of them makes a difference. TEST-2 goes a bit further and is probably more likely to work on real hardware if either of them do.

Oh, and the Select button check happens before anything is even on-screen at all, so as soon as you can see the warning screen you can release Select and it will have either worked or not worked, regardless.

Attachments:

1. jack-bros_vb_save-support_v1.3_hardware-test-1.ips
2. jack-bros_vb_save-support_v1.3_hardware-test-2.ips

Oh, that’s odd. It should be that if you hold Select while powering on the Virtual Boy, it prints “DEBUG” in the bottom right (screenshot attached) and you can use all the debug features documented in the Guides section here on virtual-boy.com. The easiest thing to check is that during gameplay, L + R together skips the current floor.

It works on emulators, but maybe the Virtual Boy doesn’t start registering input until after I do my startup check?

Attachments:

1. 

   jackbros-test-0002.png
   

Whoops, sorry about that! I broke it in the process of adjusting to 8-bit/high-byte SRAM writes, I didn’t update to the new addressing correctly. I’ve updated the Mario Clash patch to version 1.2 which should fix that bug.

That’s fantastic, very happy to hear Red Alarm and Mario Clash are working! Jack Bros. has changed quite a bit since the last version, the Start option now lets you start a new game or continue a saved game. Passwords are still available, but you can play the whole thing with saving from the Start menu (assuming it’s working!) now.

EDIT: I’ve just put up the final updated builds for all three games (Jack Bros., Mario Clash and Red Alarm) on my GitHub, so I’d recommend against anybody downloading the test patches from the above posts.

Thanks so much for your help, once again. That’s some progress. Shows we’re on the right track, although I’m not sure currently what the next problem is with Red Alarm.

For Mario Clash, that makes sense. The original game stores the brightness in 05005A63 (odd number!) so when my save patch switched that to 06005A63, I was unknowingly dropping it into one of those SRAM holes and the game is never able to read that value back. While I try to figure out what’s wrong with Red Alarm, attached is a test build of Mario Clash with only high bytes.

EDIT: I’ve also attached a test build of Jack Bros. Obviously only test if you feel like it, since I know it’s not a game you’re too bothered about!

EDIT2: And another Red Alarm test build. I was accidentally still using an odd byte for one of the eye offsets–I’ve been assuming it’s the left eye because it comes first, but I do all development in 2D, so I don’t actually know that. Fingers crossed. This might have caused a crash if you ever went into the Options and manually adjusted the depth and got an invalid value saved into SRAM, which was read in on the next load. Really hope this is it.

I talked to KR155E on the Discord about this, and apparently on retail releases/flash carts, only the high bytes in SRAM are accessible (as in, you have to read/write only the even bytes, the odd bytes are not valid).

Taking this into account, the likely reason for Red Alarm crashing was that it was trying to read in the depth values before displaying the intro, and it was only getting half of the bytes off the SRAM. With this info in hand, I’ve made a version of the Red Alarm patch which only reads/writes from the high bytes which I’ve attached to this post. Fingers crossed, this means it will work on hardware and I can start switching the rest over to only reading/writing single bytes at a time.

(Also why is the Virtual Boy like this, this is incredibly inconvenient.)

Thanks so much, I really appreciate your help.

Currently my running theory is that perhaps there’s less SRAM available than I’ve been assuming. I think the understanding is that there’s 64 KB available, although the Sacred Tech Scroll doesn’t really specify, it technically lists a range of 06000000-06FFFFFF which is like 2 GB, but I’ve been running with the theory that it behaves the same as work RAM, where the range is technically 05000000-05FFFFFF but the effective range is 05000000-0500FFFF (64 KB) and the rest is mirrors. Emulator saves are all 64 KB, so this seemed like a reasonable assumption, but emulators be emulatin’.

If the SRAM range is actually smaller than that, then something weird could be happening when I do my SRAM initialization, because I’m writing out the full 64 KB with zeroes before I start using it. If some of that range is inaccessible or mirrors for something else and those writes are bouncing to somewhere they’re not supposed to, I could be wiping out something the games actually need to run correctly, hence the issues.

Re: Mario Clash: Thanks! Yeah, it seemed to me like if the game had been released with saving, they never would have given you 40 levels to select from right at the start. That seems like a feature that exists purely because the game doesn’t save. In a world where the game did have saving back on release, I think it would absolutely be like the way I patched it, where you can only play levels you’ve previously reached. If I can get that save fixed up I really feel like that will be the definitive way to play Mario Clash (once you’ve also applied DogP’s button-swap patch).

In the meantime, if you get a chance, would you mind testing a couple of button combos in Mario Clash to see if they make any difference?

First up, from basically anywhere in the game (title screen, intro, gameplay), press L + R + Select + Start + A + B. I know that’s a lot of buttons to press at once, sorry. This is the soft reset feature built into the game, so I’m just curious if a reboot would fix the graphical issues.

Secondly, I’d like you to try the SRAM reset button combo. From the title screen (and only the title screen, it won’t work anywhere else), press L + R + Left D-Pad Down + Right D-Pad Down. That should erase the SRAM and restart the game, similar to the soft reset. I’d be very interested to know if that fixes anything.

Thanks, that’s fantastic feedback. I’ll try to figure out what’s going wrong.

In Red Alarm, the only custom code that runs before the title screen appears is the SRAM initialization, so something must be going wrong in there. I don’t see anything obvious currently, so I might have to make some test builds for both/all games to see if I can narrow down the problem.

Thanks!

I have also seen your other patches for Red Alarm and Mario Clash.

Just to catch people up who aren’t on the Discord, after I restored the dummied saving feature in Golf, Super Bros. asked if it would be possible to get games to save even if they weren’t originally designed for saving, like Golf. I answered, perhaps a little optimistically, yes: you’d just have to redirect writes to memory to SRAM instead. In practice it’s been a bit more complicated than that, but you can see the results on my vb-patches GitHub repo, which currently has save patches for Golf, Jack Bros. (also doubles as a debug mode patch), Mario Clash and Red Alarm.

So in theorey this means you can create reporcards with sram saving features for those three games?

I can say with a high degree of confidence: maybe. If they work on flash carts, then they should also work on reproduction carts. That said, I really don’t even know that they work on flash carts currently. I don’t own a Virtual Boy myself, so all of this has only been tested via emulation in Mednafen and Red Viper. There shouldn’t really be anything dramatically different about running them on real hardware, but you never know.

There’s also at least some potential that I broke something in the process of creating these patches. I haven’t tested the games all the way through to make sure there’s no negative effects. For example, the initial release of the Golf save patch had a bug which caused it to overwrite a graphic on the in-game Depth settings screen. That was relatively harmless and it’s been fixed and updated since, but making a repro of any of these hacks would require a high level of faith in these relatively untested hacks.

In short, it should be possible to make repros of any one of these games with added SRAM support, but I’d personally warn against it until the hacks have been field-tested a bit more.

Golf
Technically this isn’t debug stuff, but I’ve been messing with Golf for the last couple of days. There’s two findings of particular interest.

Firstly, the Japanese ROM is capable of saving if you run it via emulation or on a flash cart with save support, because the game has a whole save system set up which relies on a check for functioning saveRAM on the cart. This removes the preset save slot 1 (T&ESOFT, called Duff in the US version) and password screens entirely. For cost-cutting reasons, when T&E Virtual Golf (the Japanese version) was released it did not have saveRAM on the board, so on official cartridges that check does its job and causes the game to fall back to the familiar password-save mechanism.

For the USA release, they went further: in addition to the physical saveRAM being MIA, the saveRAM check is hardcoded to fail, and once again the game drops back to the password system. However, it was only that check which was disabled in the US version; all of the other saving code has been sitting on the ROM unused for the last 29 years or so. Fortunately, it was possible to restore the saveRAM check by comparing against the Japanese version, and there’s now a patch available here on virtual-boy.com or at the Golf page on The Cutting Room Floor to restore saving in the USA version when played via emulators or flash carts with saveRAM support.

Secondly, there’s a newly discovered cheat in the game which disables the wind. Simply (or not that simply, it’s a little bit awkward) hold the following buttons while starting up the console:

• Select
• Left D-Pad Left
• Right D-Pad Right

If you’re playing on the stock game (e.g. official cartridges or an unpatched USA ROM), this will also change the default save slot name from Duff (US)/T&ESOFT (JP) to VICTORIA.WON. I don’t know who Victoria is or what they won, anybody have ideas? Is this some sort of golf joke that I’m too uncultured to understand? Anyway, if you’re playing on a version of (T&E Virtual) Golf which supports saving, you won’t see the VICTORIA.WON part, because as mentioned, default player names don’t exist when saving is enabled. However, the wind will still be disabled.

Fantastic; thanks Benjamin. I figured if anyone knew it would be you, very much appreciated.