Occasionally I open up and clean my controllers, maybe use a little oil on moving parts, other maintenance like that, but if the rubber domes under the buttons tear, I have no way to repair it myself.

I've tried buying rubber dome replacements for SNES, NES and GameBoy from various sources, some who charge a lot more, some who charge a lot less, but I find the quality is generally terrible, and ones I have paid more for were indistinguishable from the cheapest ones. In particular d-pad rubber domes can make a big difference regarding precise diagonals, or accidentally pushing diagonals.

What I've ended up doing is buying 10 or so cheap ones from eBay, and then one by one put them in the controller, screw it back together, test it out, repeat. The quality may be poor, but it's also inconsistent, and what I find is that out of 10 maybe 1 or 2 feels okay for the d-pad.

Push buttons seem to be less demanding, I guess because they're more constrained in their travel. Generally I find most replacements are okay for those.

Does anyone have a good experience trying to find replacement rubber domes? Does anyone make some that are consistently good? Or maybe is there a good way to repair old ones?

For most games the flash cart behaviour should be nearly identical to the cartridge with the same ROM. It should really be decided on a per-game basis whether the flash cart is valid for a run, but I think the large majority should be found to have no difference relevant to a speedrun.

The biggest source of difference is glitch exploits. Causing game errors can do stuff like access unexpected memory regions, or write to hardware in unexpected ways, where the flash cart might actually be different. In general, the flash cart replicates the hardware as best it can, but it's tested with "normal" gameplay, and there are often dark corners of the hardware behaviour that have not been reverse engineered or replicated. Most glitch exploits I've seen seem to work the same on flash carts, but if you find one that doesn't, that's a case where you might have to say it's invalid for this game.

The second biggest source of difference is expansion hardware inside the cartridge that the flash cart has to replicate. (On NES, things like MMC3 or MMC5. On SNES, the DSP games, Super FX, etc.) Generally these are replicated very faithfully for normal play, but there are obscure things about this kind of hardware that may not be researched yet or reproducible with the flash cart hardware, especially with the more complex ones.

Basically, by default I think you can assume it's identical, but just watch the run carefully and compare against real-cart runs. Pay special attention to glitches and make sure they match expectations.

If you're seriously competitive with a game, though, you might as well remove all doubt and get the cart. Flash carts are a functional replacement, but they'll never be guaranteed 100% the same.

As for modified ROMs, that's a trust issue I guess. You could show the ROM-hash in the everdrive menu maybe, but hashes can be faked. Honestly even the ROM on a real cart can be replaced, it's just more work and more difficult to do so. I think in most cases if someone was cheating that way, it has to be figured out by watching the run.

Here's a list of all passwords, flags and coins in the game.

The regular checkpoints can be entered on the CONTINUE screen. Otherwise use SELECT+A to enter the other passwords. The Beyond passwords don't work unless you have 125 coins, but you can give yourself those in the Diagnostics Zone using the DULL code.

The first set of flags are referenced in the source code and have names there. The second set of flags lists any that are attached to objects. (This includes some auto-generated flags for ice blocks which keep track of melting.)

You can toggle the flags and coins from the Diagnostics Zone using the DULL code.

Download: secrets.csv 92kb

I made a patch to make this game run at consistent speeds on faster computers. The patch also applies to the first Mega Man game, so I'll just link that thread here rather than repeat everything I wrote there:

https://www.speedrun.com/Mega_Man_DOS/thread/c0nxu

I dunno if runners of this game would be interested, but I recently patched this game to be able to run at consistent framerates on faster hardware:

https://github.com/bbbradsmith/mmpatch

This patch should make the speed of the game very consistent if played on faster hardware. This will even run quite well on a modern PC using FreeDOS. The changes are minimal, and intended to address the hardware speed issues only.

TLDR

• Without the patch: this game has to run on some very specific speed of hardware, and it would be hard to compare any runs not made on exactly the same machine.
• With this patch: it will run the same on almost any PC.

More detailed information below.

Some notes on things that will effect overall game time:

1. VGA hardware will sync these games at 70Hz (regardless of mode selected). I believe true EGA or CGA hardware will sync at 60Hz instead, and would be 6/7 speed, but VGA hardware is pretty much ubiquitous (and still used in modern PCs). You probably wouldn't normally find a true EGA card in anything later than a 286.

The game says it has CGA, EGA, VGA and TANDY modes, but really it just has CGA and EGA. A VGA graphics device is backward compatible with both of those, but it has this slightly faster refresh rate. (Note: DOSBox simulates VGA hardware by default, not EGA.)

2. There is some processing time in transitions between screens, the longest of which can be seen at the opening of MM3 with several seconds of black screen. On a fast computer these generally shrink to "instant". I think the difference here becomes pretty much insignificant to a speedrun somewhere around 386 or 486 speed.

Most of these are pretty short to begin with though, and the only really long one is before the start of the run I think. Might make a few seconds difference across the run if played on a slower (<386?) computer?

3. In general, the faster the computer, the more consistently it will run with this patch. Slow computers (<=286?) that were experiencing enough slowdown to make this play tolerably will still have this additional slowdown, though at least would sync to a video frame, so that might be slightly more consistent than before.

In the original game the CGA mode never had any synchronization, but the EGA mode actually did actually sync to the next video frame during gameplay. A slowdown setting of 0 basically puts things back the way they were. Because EGA mode already had a sync, settings of 0 and 1 are essentially the same on fast computers. On slow computers there is an additional delay.

0 = 70.0 Hz (EGA) or Unlimited (CGA) 1 = 70.0 Hz (sync 1 frame) 2 = 35.0 Hz (2 frames) 3 = 23.3 Hz (3 frames) 4 = 17.5 Hz (4 frames) et cetera.

.

So... maybe people here are happy with the arbitrary DOSBox at speed 500 setup you've been using, and I'm not trying to insist you should use this patch instead, but if anyone's interested in doing runs on hardware this might be a way to make that possibility more accessible.

The changes applied by the patch are very minimal. The default speed setting of 3 should be comparable to existing DOSBox runs, though not identical.

The patch also applies to Mega Man 3.

Lizard now has an official randomizer:

http://lizardnes.com/lizard_of_random.html

This randomizes lizard locations, boss locations, and door connections for the NES version of the game.

Well, that question is moot anyway 'cause I don't yet have a route in mind that would make it worthwhile. ;)

The console will accept it as input, but yes it's not possible to enter on a single normally functioning NES d-pad. There are a couple of ways to do it, though.

On the Famicom, you can use a Famicom expansion port controller adapter and use 2 pads at once. I build the one in this video but Hori and other companies made commercial products that worked the same:

Unfortunately the equivalent expansion connector on the NES is sealed away under a plastic tab and there aren't really any commercial products that would plug into it (though I've seen one or two things made for it by the homebrew community).

Could also just modify the existing controller in some way, .e.g. an extra button that gives an extra left push, or even just cutting the d-pad in half (if you like destroying things).

Otherwise you can try it in an emulator that allows Left + Right, at least. In retrospect I kinda wish I'd left some access to this same feature by the second controller instead of this method. I had only really considered it as a need for TASbot (which was happily confirmed to work a few months ago) but maybe it'd have been fun to try and exploit for live speedruns too if it was more accessible.

...though also I'm not even sure how possible it is to keep up synch with it. Will require a sequence of rooms that are frame-perfect, at least from the POV of the RNG. The thought is something like this:

1. Hold Left + Right + Up before hitting Start and immediately releasing Left (before the player finishes fading in). This should get you to the door of the first room in a perfect number of frames.
2. During the fade, hold hard left. This should let you fall through the next room, and walk away from the save point below also in a perfect number of frames.
3. Etc. I'm not sure how long this can be kept up. Probably not possible to reach a boss this way?

Either way, though, you can inspect the value in emulators if you want to learn about what can or can't be used to adjust the RNG, which could be useful knowledge for both TAS and live runs.

For anyone that wants to investigate the random number generator with an emulator, use a RAM Watch feature to look at a 2-byte value at $0044. This is the seed value for the RNG. (Two bytes at $44 and $45.)

If you can start the game with a Left + Right + Start press, the RNG will be reset to a known state.

For a TAS this will let you easily see what does or does not affect the RNG seed, but for a live run, theoretically you could control the RNG for maybe the beginning segment of the run, depending on how long you can maintain perfect synchronization with it.

ChoaslegionKaeru switched to the emulator version, but just as a point of verification: he recently timed an 18:43 with 17:14/23 on game clock, compared with Smartball's non-emulated 18:43 with 17:15/03 on the game clock. So, all other things being equal I think that's good confirmation that the emulated times are directly comparable.

I now consider this complete with version 1.0 being released. I have amended the initial post with all the details. I don't plan any further additions, but let me know if there's something I've missed, or if you have any comments at all, really. Enjoy!

The Karnov ROM is commonly found with the wrong header on it. It should be mapper 206, not mapper 4. This IPS will fix it:

http://rainwarrior.ca/projects/nes/karnov_header_fix_206.ips

This should correct garbage graphics on the second screen of the game, on some emulators and Everdrive N8.

.

If you've got a PowerPak, though, you'll get an unsupported mapper error, so if you need to reverse this correction:

http://rainwarrior.ca/projects/nes/karnov_header_unfix_4.ips

I have made for you the Karnov Inspector! It's a Lua script that you can use with FCEUX, Bizhawk, or Mesen.

.

Download: https://gist.github.com/bbbradsmith/46e53f67f681814337001445539995ad

.

.

H - Help - Toggles the help display. S - Stats - Your screen coordinates, scrolling, and map coordinaes at the bottom. K - Tiles - All the level tiles: collision, hidden item triggers, spawn triggers, etc. L - Touch Hitbox - All the hitboxes that you can touch. V - Shoot Hitbox - All the hitboxes that you can shoot, plus enemy health. B - Bomb Triggers - All the places you can use a bomb. N - Hide Screen - Blanks the image to view only the inspector overlays.

.

This should work with most versions of FCEUX, but I recommend the "interim" build available here, which will display the overlaid colours a little better:

http://www.fceux.com/web/download.html

.

To run this, open Karnov in FCEUX then go to: File > Lua > New Lua Script Window > Browse...

1. AEEITKLP
2. AAXSTULP

For people that are practicing this game a lot and want SFX but no music (even though it's a great tune), this pair of game genie codes will do the trick.

1 stops the music from playing at the start of the level, 2 stops it from playing after a death.

Looking at two recent times using the same route, comparing NES to PC:

Smartball: 19:02 real time, 17:31/13 game time (NES) ChoaslegionKaeru: 19:20 real time, 17:45/59 game time (PC)

So we've got 15 seconds from the in-game timer, and 18 seconds in real time. The 60.1Hz vs 60.0Hz difference accounts for about 2 seconds, so that leaves 1 second unaccounted for.

As I said in the previous post, the game's timer does not count pauses (dialogue, etc.) or lag frames during the room transition. From these numbers I think the average NES room transition is a little bit faster than the PC. (There's no exact

So, as a rough ballpark, I'd estimate the PC loses about 0.15s per minute versus the NES.

Here's a "Super RUDD" game genie code that unlocks 3 more Lizards to the RUDD cheat: ZEEIXYYE

For the equivalent DULL code: ZAKZKAYE

For testing the NES ROM, here's a LUA script that works with FCEUX that will display the in-game timer. You can see exactly when it pauses with this.

http://lizardnes.com/downloads/lizard_clock.lua

The in-game timer counts active frames (assuming 60 per second) but it skips lag frames spent loading graphics data between screens. It also halts if you pause the game, and stops when the ending sequence is triggered.

You can turn the clock on in the PC build to see the timer overlaid on the screen. That will show you when it starts and stops, the NES version behaves the same.

On the PC the lag frames between screens are always the same, I think it's always 20 frames from room to room. On NES it varies depending on how much graphics are shared between rooms, seems to take either 19 or 20 frames in most cases. The exact number of frames depends on the route.

Also, the NES is usually close to 60.1 Hz, and the PC version runs at 60 Hz. I think that's about 2 seconds over ~20 minutes.

So, the two platforms are designed to be frame-for-frame compatible while you're able to give input to the player, at least. The in-game time is just a frame counter and should give equivalent times for frame-equivalent runs. Real-time though I'd only expect a difference of a few seconds overall.