Yeah, to me it seems most likely that Human would have published the game themselves, at least in Japan. They had both development and publishing arms. At roughly the same time as Henry would have been released (1994-1995) they also developed and published other titles like The Firemen, Clock Tower and several Fire Pro Wrestling games on SFC/SNES. That said, they did sometimes work with external publishers, especially for releases outside Japan. Super Soccer (1991) was published by Human in Japan, but Nintendo in North America/Europe. F1 Pole Position 2 (1994) was published by Human in Japan and Ubisoft in Europe. So maybe if the game got far enough for a North American release to be planned, they would have found an outside partner. But it seems most likely that any materials that still exist today would be in Japan.

No problem, there’s no hurry. FYI, I discovered and fixed another bug specific to the new patch, the “board” one. I missed another difference between the old and new ROMs, so I had to accommodate that change in the patch. It was similar to the issue you had previously with score saving but for the Score Attack!! mode. Attaching a new patch for the “board” version specifically, the “build” one should be fine.

Attachments:

1. bound-high_board_vb_save-support_v0.9-test-3.ips

I was just “reading” (I don’t know Japanese) a 5chan thread about unreleased Virtual Boy games and somebody mentioned that this 2014 interview with game designer Goichi Suda (in Japanese), where they got him to play a Virtual Boy, talks a little bit about Flying Henry.

Suda worked at Human Entertainment in the mid-to-late ’90s. He wasn’t involved in Flying Henry himself but another team at the studio was working on the game. Here’s some quotes courtesy of Google Translate:

First of all, could you tell us about your memories of Virtual Boy?

Suda: A long time ago, there was talk of developing Virtual Boy software during the Human era. When the development kit came to the company, I actually touched it. It gets very exciting within the company, and everyone plays through it and is satisfied with it.

After that, there was a development team, but unfortunately it never went on sale. I think it was a game where a dog with big ears, like Dumbo, flies through the air. It was a game planned by Koike-chan from Dragon’s Earth, and I can’t remember the title. Ah, I just searched for “human + virtual boy” and it came up. The title is Flying Henry” (lol).

It’s a cute game. Mr. Suda, are you not involved in the development at all?

Suda: In terms of development, at the time Human had a planning department. There were a lot of planners there, and one of them was Koike-chan. Then, an in-house programmer was assigned to his project. Maybe even a prototype was made. We also held demos within the company. However, I think they stopped development midway because the market situation was not good.

Yep, it’s the one here on the site. You can find it attached to the thread I linked above as boundhigh-cleanfullgame2018.zip or on the PVB game page for Bound High as “Bound High! (JU) (Official)”.

Ooh, fantastic eye! I’ve been messing with it for days and never noticed the Pocket scores not working. I was actually saving them to SRAM correctly but reading them back into RAM wrong, so the score is there in your save file, but doesn’t show up in the score list. That was super useful to know, great work as always! Seeing the score working in SRAM allowed me to identify the problem immediately and get it fixed pretty quick.

This whole situation with Bound High!’s multiple builds/dumps is pretty interesting to me. I looked into it after my last post and Bound High (Japan) (En) (Proto).vb is actually the build from the leaked source code, not a dump off a prototype board as I was assuming before. I think the actual prototype board dump was the ROM you were using before, which my patch was incompatible with?

As mentioned in that thread, the builds are slightly different throughout–just enough to frustrate easy comparison–but I was surprised to discover that there are at least some minor noticeable differences, with the vowels replaced with cute little animal graphics on the password screen. If I had to guess, I’d say the animal version off the prototype board is probably more recent, because I can’t imagine why you’d do that then switch to letters later.

Anyway, all this to say that I decided to port my patch over to the prototype board dump as well, so it now builds for both the Kintaro compile (Bound High (Japan) (En) (Proto).vb) and the Cpt. F. prototype (BoundHigh-cleanFullGame2018.vb). Personally, I think I’ll be using the Cpt. F. version going forward, because I like the animals on the password screen and if my speculation that it’s newer than the Kintaro build is accurate, there could potentially be other improvements. But now that I can build for both, people can go with whichever one they prefer.

I’ve attached two test builds, one for the “build” (Kintaro) and one for the “board” (Cpt. F.). Both should behave identically in terms of saving, but obviously the Kintaro version has had a couple of days’ testing while the Cpt. F. version is brand new (finished about 15 minutes ago), so I’m sorry if I broke anything in the porting process! Obviously I’ll give it some further testing on my end as well since it’s the one I plan to play going forward.

Attachments:

1. 

   vowels.png
   

2. 

   fauna.png
   

1. bound-high_build_vb_save-support_v0.9-test-2.ips
2. bound-high_board_vb_save-support_v0.9-test-2.ips

Yeah, it’s possible the issue is just one of ROM compatibility, depending on whether the ROM you have is the same one I worked on. If that’s the case, the existing patch would hopefully work on the Bound High (Japan) (En) (Proto).vb ROM. If that works, we’re fine and people who wish to use the patch will just need to have that ROM version specifically.

If we’re lucky, it’ll be the above issue (different ROMs), but if not I’ll have to look into what’s causing the problem. In that case, I must have broken something in the patch, so I’m attaching three builds which remove successively more of the patch to this post. These will be completely broken in terms of the game being able to save because I’m just taking parts out of it, but the goal is just to get the game to boot up for now.

Attachments:

1. bound-high_vb_save-support_v0.9-boot-test-1.ips
2. bound-high_vb_save-support_v0.9-boot-test-2.ips
3. bound-high_vb_save-support_v0.9-boot-test-3.ips

Huh, that’s no good. I mentioned the issue on the Discord and KR155E noted that there are a lot of Bound High ROMs floating around: there’s one dumped from a real proto cartridge–I think this is the one I’m building for, the filename I have is Bound High (Japan) (En) (Proto).vb

There’s several others compiled from the leaked source code, including the debug ROM by thunderstruck and a few other attempts at compiling the final game. I actually had no idea there were so many. Hopefully the issue is something as simple as this, but if not I’ll try to put together a few test builds tomorrow which just disable different parts of the hack. If you can test those, we may be able to at least narrow down where the problem is.

Nice, fingers crossed for the haptics patch. I’ll hold off making a new release on GitHub until it’s confirmed working on real hardware, but as you say I’m pretty sure it’ll be fine since the patches are no longer clashing with one another.

In the meantime, attached is an initial test build of Bound High. I’m not sure if this is done yet necessarily, but hopefully everything is functional.

List of changes:

• Most recent Adventure of Chalvo mode password is saved to SRAM; password is pre-entered on the Continue screen
  • Passwords are saved either when earned via gameplay or typed manually, these will replace each other
• Scores and progress are recorded to SRAM in Score Attack!! and Pocket and Cushion
  • Score Attack!!/Pocket and Cushion passwords removed entirely; the password entry screen is gone and the Stage Select screen no longer shows your current password
• SRAM can be erased with L + R + Left D-Pad Down + Right D-Pad Down on the title screen

As you can tell, I took different approaches for the Adventure mode and the score-chaser modes. I haven’t really decided that this is definitely the approach I want to take for the Adventure mode. It would be possible to remove passwords there too and I started doing that (tested disabling the intervals between stages where the game tells you your new password), but it would need more effort to really be satisfying. The difficulty selection would need to be expanded to support Expert (since that’s otherwise only available via password) and the password interval screens would be better if modified into some sort of “Game Saved!” screen instead of skipping them completely. For now, I think everything should work, but the question is open as far as whether Adventure mode should be handled differently.

Attachments:

1. bound-high_vb_save-support_v0.9-test.ips

Forum seems to be having issues again. I posted this previously, trying one more time:

Huh, thanks for discovering that! I haven’t tested with the haptics patch at all, will look into what’s going on there before I get properly started looking at Bound High.

As discussed elsewhere, before I started actually doing anything to Bound High, I wanted to understand how the three different password systems all work. That led to this password generator spreadsheet, which can create passwords for all three game modes which use them (Adventure of Chalvo, Score Attack!! and Pocket and Cushion). I noticed a couple of mildly interesting things in the process of creating this password generator.

For one, in the Adventure of Chalvo mode, you can play through Expert mode with the Standard enemies or vice versa, as the difficulty level and enemy types are tracked separately in the password system. Even though the game will never give you the “mismatched” passwords, you can generate perfectly valid passwords that have the wrong enemy types for that difficulty.

For two, one of the Score Attack passwords that’s been all over the web for years (including here on vb.com) is technically incorrect. Bound High requires you to complete stages 1-16 to unlock stages 17-20. A common code found online, XPJCZ, has the game in an impossible state where stages 1-15 plus 17 and 19, which are not unlocked yet, have all been completed.

The passwords in Score Attack!! mode follow a pretty consistent pattern, so I strongly suspect what happened here is that somebody took the existing “All Stages Clear” password and then replaced characters one at a time until they got a password that seemed to work correctly, but which the game would never give you because the specific scenario is not possible.

Thirdly, I discovered that the game can actually give you an invalid password if you play the stages in an order that it doesn’t expect. If you play Score Attack!! mode and beat Stage 16 before you beat one/both of Stage 2 and Stage 8, the password it gives you is not possible to enter because it’s using a character from beyond the end of the password entry keyboard. It’s sort of like the game is giving you a password with a % sign in it, even though there’s no % sign on the keyboard. However, in the game, the invalid character gets replaced with a 0 (zero). Technically, you can enter this password (using the zero on the keyboard), but it doesn’t accurately track your progress because the zero you typed is not the same as the impossible one the game gave you.

Here’s a few passwords from the generator which I think are most likely to be useful or interesting to people:

Score Attack!!

• 8PJ3Q
  Stages 1-16 Clear (for real this time), allows access to stages 17-20
• 8P83Q
  Stages 2-16 Clear, complete Stage 1 to see the “All 16 Stages Clear” cutscene
• XD8HZ
  Stages 2-20 Clear, complete Stage 1 to see the “All 16 Stages Clear” cutscene followed by the “All 20 Stages Clear” cutscene; this one is impossible in normal gameplay but works fine

Pocket and Cushion

• 0QFJF
  Stages 2-16 Clear, complete Stage 1 to see the “All 16 Stages Clear” cutscene
• PJSJ0
  Stages 2-20 Clear, complete Stage 1 to see the “All 16 Stages Clear” cutscene followed by the “All 20 Stages Clear” cutscene; impossible normally

EDIT: Red Alarm looks like a simple fix. One of the problems when making a ROM hack which adds functionality instead of just changing it is finding somewhere unused inside the ROM to put all the new code. These empty spaces are sometimes referred to as “code caves”, since they’re essentially empty holes you can fill up with code. It turns out enthusi’s haptics patch and my save patch both used the same code cave, so whichever patch you applied last would overwrite the previous patch’s changes with disastrous results. I’m attaching a new build of my patch which moves the save functionality a bit “deeper into the cave” so it’s no longer overlapping with enthusi’s changes and both patches should be able to cohabit.

Attachments:

1. red-alarm_vb_save-support_v1.5_haptics-test.ips

Excellent, everything looks good in both saves, same results as in emulation. 👍 I’ll go ahead and put the new patch up on GitHub tomorrow–no changes from the version you have now, so you won’t need to re-patch.

I also have a tiny patch for Hyper Fighting. It doesn’t need any testing, it’s just a quick bug fix I whipped up and posted on the Discord. Eventually it’ll go up on GitHub as well I suppose, but I don’t know when, so I’ll put it here so it’s not just buried in a Discord attachment.

Hyper Fighting has a tiny bug with the Brightness setting in the Options screen. If you set the brightness to maximum (32), the next time you start up the game it will be reset back down to 16. On startup, the game checks if the brightness is >31 and resets it. This is most likely just a typo in the game’s code: the anonymous dev probably meant to have it reset if the brightness somehow got set to >32 (more than the maximum), but instead they made it reset if the brightness is equal to the maximum. This 1-byte patch fixes that bug.

Attachments:

1. hyper-fighting_vb_fix-brightness-cap.ips

Nester’s Funky Bowling is probably the most likely one I’ll look at from the remaining games. I haven’t looked at the code at all yet (hopefully, it’s not another Space Invaders) but just from how the high score table works it could be one of the easier ones to work on–like V-Tetris, that one was pretty friendly to work on, too. And I could use something simple after Space Squash, that was certainly one of the more challenging games.

Definitely a pretty simple one for a change.

I have it saving the player 1 and 2 names, character selection (Nester/Hester), preferred ball weights and the League Leaders (high scores). Same SRAM erase setup as usual, L + R + Left D-Pad Down + Right D-Pad Down on the title screen.

I think this is complete as long as no issues come up.

Attachments:

1. nesters-funky-bowling_vb_save-support_v1.0-test.ips

Oh wow, surprising result for Space Squash, I really thought 500 microseconds would cut it but it’s not even close. Especially surprising after the SRAM tester homebrew, since that gave the impression 200 microseconds was already pretty close. There must be other factors at play, maybe even physical ones (ambient temperature?). Comparing the previous 200 microsecond delay to the new 500, we only got about a 25% improvement. We need another ~800-900 microseconds (~1250 total) to make sure the save gets initialized correctly. I guess 1500 was pretty close after all. Ultimately, I think I will just stick to 1500, since it’s already known to be working and still only a fraction of a single frame.

The reason we’re having such a bad time with Space Squash specifically is that it starts reading in the config settings extremely early on boot. We’re talking less than one microsecond. The original game is reading all of these values from ROM, and ROM is accessible instantly. Our hack falls over when it starts trying to read these values from SRAM as if it were as fast as ROM, but hey, that’s what the delay is for.

Super glad we got Mario Clash worked out. I do have one more thing I’d be interested to look at for that game. DogP’s controller fix hack is fantastic, but the one thing that’s not so great is that it breaks the attract mode that plays if you leave the game sitting on the title screen for a while. The CPU player is pressing all the wrong buttons, so it never even manages to jump off the chain at the start. I think this should be fixable and would go a long way to make Mario Clash with saving/button swap feel like a real commercial game instead of a ROM hack.

EDIT: would you mind looking into a possible save patch for Bound High?
EDIT2: and perhaps for Nester´s Funky Bowling if you have time and are motivated 😉 ?

Yeah, when I started out I was specifically looking at the commercially-released games, but Bound High is obviously … pretty close! Honestly I haven’t really played much of the game yet myself, so I’m not sure how progression/saving would work. The game page says it has Password saving already though, so that’s always a good place to start if I look at getting it saving internally. It’s on the list!

Nester’s Funky Bowling is probably the most likely one I’ll look at from the remaining games. I haven’t looked at the code at all yet (hopefully, it’s not another Space Invaders) but just from how the high score table works it could be one of the easier ones to work on–like V-Tetris, that one was pretty friendly to work on, too. And I could use something simple after Space Squash, that was certainly one of the more challenging games.

OK, I’ve got some of the patches onto the new 500us-delay setup. The most important ones for now are Red Alarm and Space Squash, since we were having problems with those previously. Especially for Space Squash, it would be a huge help if you could upload a fresh save just so I can make sure it’s still clearing out SRAM correctly after reducing the delay from 1500us to 500us.

I tried to delete my save in Mario Clash (with the 1.3. patch file applied) but the combo L+R+ L-dpad down+R-dpad down doesn´t do anything in the game.

I’ve also just tried to fix this by using a different method to soft reset Mario Clash when you press the SRAM clear combo on the title screen, so I’m attaching that as well. The button combo is still the same and it’s still on the title screen (with the PUSH START BUTTON text, etc.). Mario Clash now also has the 500us delay like the others, but that’s purely for cautionary reasons since the game never had any trouble saving anyway, other than from bugs in the high score saving that were fixed a while back.

BTW, I have ordered a Golf reprocard with SRAM feature enabled since this patch should have worked from the beginning.

Nice! Should make a really unique addition to your collection!

Attachments:

1. red-alarm_vb_save-support_v1.4_500us-test.ips
2. space-squash_vb_save-support_v1.2_500us-test.ips
3. mario-clash_vb_save-support_v1.3-button-swap_500us-test.ips

Great work, thanks very much! It did indeed work perfectly. Better than I expected, even. I can see that there is some slight variation in how long it takes for SRAM to be accessible. After a 100-microsecond wait, only 2/5 saves wrote out correctly. After 200 microseconds, they actually all wrote out correctly. We already confirmed 200 wasn’t quite reliable though, since in multiple tests that was not a long enough wait for Space Squash to save correctly. That probably means 200 is right on the borderline. This could mean 300μs would be safe across the board, since we’ve seen no evidence so far of SRAM failing after 300μs. Throw in a bit of buffer for “in case of emergency” and maybe we can settle on about a 500μs wait just to be safe. It’s late here but tomorrow I’ll start on implementing the delay into the existing patches. It’s easy enough to adjust the delay later if it turns out we need more/less. Thanks again and excellent work!

Fantastic, now we’re getting somewhere!

The only thing really remaining to discover is exactly how long a delay is needed. I chose 1500 as a random “long” delay (if you consider 0.0015 seconds a long time). The real delay is presumably somewhere in-between 200 and 1500 microseconds.

I’m attaching a little homebrew app which simply writes out 255 bytes in a row, waiting 100 microseconds between each byte, so its total runtime is roughly 0.03 seconds–essentially instant. It doesn’t display anything or make any sounds, just writes out those first 255 bytes in a fraction of a second. If you could run this app, dump your save, then do it again a couple more times just to catch any minor variations (so 3 different saves), we should be able to get a solid idea of how long the Virtual Boy needs to wait before it starts writing to SRAM after powering up. We’ll probably be the first people outside of official developers to know this information, since it’s not documented anywhere. 😀

Attachments:

1. sram-tester.zip

What’s most interesting in the new save is that it’s still not entirely cleared out as I thought it would be with the fixed initialization. The first 0x243 bytes have not been cleared out as they should be, but everything after that has. The switch from word- to byte-based clearing has helped–about half as much of the save is still uninitialized compared to the original save you shared. The byte-based method is slower, which I suspect might be related here. If we assume that SRAM only starts responding correctly after some specific unknown period of time, that would explain the different result: the first 0x243 (about 600) st.bs are failing, then the SRAM finally wakes up and the other … 0x7DBD (about 32,000) writes work correctly. If that’s the case, the solution might just be to keep increasing the delay before we start accessing SRAM until it works. The “delay” patch from yesterday was 200 microseconds, but if time is the deciding factor, then that wasn’t a long enough wait before we started accessing SRAM.

These are all pretty small periods of time we’re talking about; 200 microseconds is 0.0002 of one second, so we can probably afford to push it pretty high before it becomes noticeable. Doing the math, with my current approach it should take about 174 microseconds to write out those 0x243 bytes. Before that is the SRAM check, so we need to factor that into the delay as well. The very first read from SRAM is checking the validity of the very first byte which is another ~36 cycles before we start writing. Adding that too, we’re still only at about 176 microseconds, so in theory the 200μs delay should have been enough, unless it’s a situation where you have to wait 200μs after the first access?

OK, I guess that’s enough theories for another test. I’ve been a broken record with this, but thanks so much for your patience with me, you’re doing the whole VB scene a huge favor by helping to resolve these issues.

I’m going to attach two new patches.

One of them has the dummy reads followed by a 200μs delay, in case the setup process is “wake SRAM up, wait 200μs, then start reading/writing”.

The second one just has a 1500μs delay with no dummy reads, in case this is purely a timing thing and the dummy reads are irrelevant.

I don’t think you should need to test progress again (and I know it’s a hassle to test that in Space Squash since it takes a pretty long time to clear an Area). It should be enough to test the Config Menu: turn off BGM, set the difficulty to Hard, change the Match points, etc. and see if that gets retained across boots. Similar to high scores, the config gets reset back to the defaults when the save is initialized, so if you can retain that, it should mean that high scores are also working.

Sharing your saves is definitely very helpful, so regardless of whether either of these patches help, it’d be good to see the SRAM files for them. Thanks again for all your help.

Attachments:

1. space-squash_vb_save-support_v1.1-dummy-and-200us.ips
2. space-squash_vb_save-support_v1.1-delay-1500us.ips

Without any understanding of why changing a failed st.w to a successful st.b completely breaks all saving across the board, I can’t really advise whether the old versions which fail save initialization are truly functioning correctly. The 4000 failed writes which occur on boot in the old versions might accidentally be fixing something but also accidentally breaking something else. With zero knowledge of what the problem is, unfortunately I also have zero knowledge of the solution.

EDIT: Probably a long shot, but the Sacred Tech Scroll claims that 8 dummy reads of WorkRAM are required before WorkRAM will begin functioning correctly. This is apparently an error Nintendo themselves believed (their software, e.g. Mario Clash, also performs these dummy reads) but according to pizzarollsroyce, it’s instead the VIP’s DRAM which requires these dummy reads, and either way the hardware handles performing them anyway.

All that said, KR155E directed me to VUEngine’s SRAM handler, which similarly performs 8 dummy reads of SRAM before it starts accessing it for actual use. There’s no reference to such a requirement in the Tech Scroll or anywhere else I’ve been able to read, but it can’t hurt. I’m attaching a new build of Red Alarm, since it’s probably the easiest one to confirm whether or not saving works (easy to get a high score of 100 points or adjust the depth/brightness, etc.). This version performs 8 dummy reads of SRAM on startup, similar to VUEngine software. This is a bit of a hail Mary; I have a low degree of confidence in this making a difference, but it was easy to implement, so if it makes a difference then that’d be nice.

EDIT2: Actually, I may see an issue in the Red Alarm patch. Attachment removed for now, I wish to investigate this a bit more before I ask you to test.

EDIT3: For now I’m attaching two alternate versions of the Space Squash patch which I’d appreciate if you could test. One implements the 8 dummy reads and one implements a 200μs delay before it starts reading SRAM, the two requirements Nintendo lists for accessing WRAM. If either of them makes a difference to your ability to save on real hardware, that would be great news, but it’s hard to say how likely it is they’ll do anything.

EDIT4: I have at least half of a theory of what’s going on but not the whole of one. The first thing I do on startup is check that there is a valid save for the current game in SRAM. If there is, execution continues normally. If there is not, we jump out, erase the entire SRAM and start over. In old builds, this erasure step was not functional on HyperBoy and similar carts due to use of store word instructions. This meant that whether or not my hack detected a valid save, the save would never be erased either way. Since I fixed the save-clearing function by using store byte instructions only, the save-erasing step now works as expected.

However, it seems that the initial check of SRAM has actually been failing this entire time on HyperBoy hardware. That wasn’t clear because instead of the save being erased, the hack would try to erase the save, fail and continue on to the initialization step (e.g. in Space Squash, copying over the default high scores, hence why yours vanished). This would leave your save in a partially initialized state, with your high scores replaced but your game progress intact because of the failed SRAM clear. Now that the SRAM clear is working correctly, it has become clear that SRAM is getting cleared on every boot for at least some games, hence why you cannot save at all any more in Red Alarm or Space Squash. The question now is why the SRAM check fails every time. Hopefully, it’s just some arbitrary requirement to access SRAM like the 8 dummy reads or the 200μs delay. If not that, then we’re back to square one with no idea why the check fails.

Attachments:

1. space-squash_vb_save-support_v1.1-dummy.ips
2. space-squash_vb_save-support_v1.1-delay.ips

Well, for whatever it’s worth, save initialization is working correctly now, but I don’t understand why it broke everything else in some titles. Regrettably, I don’t really see a path forward from here. I have absolutely no grasp of how those changes could have broken saving entirely in titles like Red Alarm and Space Squash. This represents the entirety of the changes made to Space Squash:

diff --git a/sposh-save.asm b/sposh-save.asm
index 99a89bc..3b44b05 100644
--- a/sposh-save.asm
+++ b/sposh-save.asm
@@ -335,10 +335,11 @@ CLEAR_SRAM:
?mov CHECKWORD, r9
ld.w 0x0000[r9], r9
movhi 0x600, r0, r6
- movea 0x4000, r0, r7
+ mov 1, r7
+ shl 15, r7
NEXT_SRAM:
- st.w r0, 0x0000[r6]
- add 4, r6
+ st.b r0, 0x0000[r6]
+ add 2, r6
add -1, r7
bne NEXT_SRAM
?mov CHECKWORD, r9
@@ -537,7 +538,7 @@ ERASE_CHECK: ; r10 is free
cmp r6, r7
bne .NO_ERASE
movhi 0x600, r0, r10
- st.w r0, 0x0000[r10]
+ st.b r0, 0x0000[r10]
jr SOFT_RESET
.NO_ERASE:
?pop r7

Without really needing to be able to read code, what this means is that I changed one instruction that loaded the value 4000 into two instructions that load 8000, changed two previously non-functional store words (st.w) into store bytes (st.b) and in line with that change am cycling through SRAM 2 bytes at a time instead of 4. These are extremely minor changes in the code which clears out SRAM on first boot, with no relation to any of the actual saving or loading behavior.

I simply have no idea what could be going wrong here and not even any theories I can explore. I don’t really have any other option but to hope that somebody else can understand why these issues are occurring. At least all of the work up to this point has been open source, so if a capable VB hacker wishes to look into them they may be able to fix these problems.

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