This is not a post explaining why I left SNES9X, nor is the purpose to "even the score" with anyone. I left because I felt it was the best decision for Matthew Kendora. That I also considered the move best for Snes9x is secondary, but equally true. Rather, this is about a single aspect of what led me to those conclusions.

Simply put, I felt a deep philosophical rift had formed between myself, and the entire SNES community (meaning it extends beyond Snes9x). The symptoms are many and varied, but the chain of evidence became clear the longer I was inactive during the early parts of this year. Furthermore, some portions of this rift have exposed what I feel are fatal flaws in the existing SNES scene. If these are not remedied, I believe SNES emulation will ultimately stagnate prematurely, and possibly permanently.

Fundamentally, SNES emulation exists because people love the SNES. Emulation coders are drawn to the SNES because of fond memories. However, one must also realize that the pool of persons with fond memories of a real SNES is not bottomless. Already, the numbers of high school graduates each year who remember the SNES are declining. Therefore, the injection of new blood has a limited potential: almost no new SNES lovers with the potential to code are created each year. Hence, it is up to the existing SNES community to choose the proper paths. Are we really on the right track, though?

It would be easy to look at the special chip work done in recent SNES9X releases, and to argue that SNES emulation has never been stronger. The 1.39mk series brought SPC7110 emulation to Snes9x, 1.40 brought OBC1 emulation, and the first ever DSP-2 emulation. 1.42 included Andreas Naive's S-DD1 emulation. 1.43 will emulate the ST-010, another never previously emulated chip. Surely this is a strong indication of health, right?

I disagree. These are big items, but is SNES emulation really about the Next Big Thing? There's only so many Big Things. What happens when they run out? Will the community have the patience and endurance to work even harder for the Next Little Thing? I have seen nothing to indicate that such a transition is likely, from the users or the developers.

Big Things are exciting, and fundamentally easy to show in screenshots. Undeniably, they are a part of the long-term goal. However, there is a danger to focusing too much on them. There is a limited community-wide amount of research that can be done. Fundamentally, the Big Things have to be done at the expense of the Small Things. There isn't enough research time and effort to have both.

If Small Things are small, they can't be important, right? In fact, nothing could be further from the truth! A small thing can be whether a bit is Open Bus, or actually returns a value. Seems trivial, right? it's just 1 bit! Of course, if that bit is used as a branch condition, emulating it properly is very important. This is where my philosophy seems to differ, and my assessment of all SNES emulators convinces me that the situation is critical.

Let's take a simple, made-up problem for a moment. Game A is really popular, and requires register 34 to return a constant 7. Game B was only released in Japan, and expects many different values, but never 7, and indeed, the source is register 34. On the other hand, you have the GB42 chip that runs some random game. Right now, the GB42 would be focused on. That's the state of emulation. For the majority of both users and developers, register 34 just is not as interesting. However, every game could be using register 34, since it's in the base unit. So which would YOU work on?

I'm not saying that the developers are misguided or wrong. Are they emulating things better than before? Obviously. Some emulation is better than none. I'm just saying that I don't think that creates a sustainable environment. Eventually, you run out of special chips. Can the enthusiasm be sustained? Probably not. It's a matter of enthusiam generally being related to the percieved value of the task. The more important the task, the more people want to tackle it. Who dreams of making the sacrifice fly in the 6th inning to tie game 7 of the World Series? No one. The kids dream of the 9th inning homer to win. It's never about making the first period poke-check from behind in the first period of game 1 of the Stanley Cup finals. It's the game 7 double overtime winner. That's human nature.

I question whether the users or the developers can adjust from cracking new ground with new chips to the "register 34" problems. I think the community has set itself up for a letdown of unforseen proportions (yeah, I'm the prophet now.). Think about it. One release, you see a never-before-emulated chip emulated. The next, you get a bunch of register tweaks, and the release after that, more of the same, and there are few notiable signs of the changes, aside from a drop in fps. Do you honestly believe that interest can be sustained that way, as things stand now? I don't. It's like coming down off a long high. Even if you reach normal, you feel subpar. That's bad for morale, and that hurts the will to work.

It doesn't stop there. The SNES community is bleeding away experience. ZSNES is essentially Nach and pagefault now, and pagefault has slightly more experience than I do. Snes9x's ranking developer is probably anomie, and he's got the same experience I do, and the community's ranking developer is TRAC. Not a bad collection of talent, until you consider that means the longest serving programmers have 3 years of experience under them with their current projects, or are their entire team. Virtually every project except SNEeSe has lost its original programmer. The replacements are not as adequate. anomie and I combined weren't equal to Gary, and now it's just anomie. When live keeps anomie away, will the next programmer equal anomie? If not, aren't we as a community losing?

I consider this a problem because as each successive generation of coders comes and goes, we may refine the projects some, but in each case, we end with a lesser understanding of the whole. Everyone says I left, someone else will come along. They're right. However, what I see is that in 2007, the programmer who comes in my place will also leave, and he or she will know less of the Snes9x they leave behind than I did of the one I left behind, just as I knew less than the programmers who went before me. How long before in three years, the programmer who comes after barely scratches the surface of the project? And why is it that so many coders leave after about 3 to 5 years? As long as that trend remains, how long can it be sustained before the 3 year window ends up being too little time to make a real improvement?

Of all the emulators anywhere, none is more successful at becoming mainstream than MAME. Part of it is that it's an insane size, and reaches across more generations than any console. However, what draws my attention to MAME is the thing I've long felt is lacking from our community: an attention to detail that borders on the obsessive compulsive. (For the record, Snes9x, at least, is more accurate at a random SNES game than MAME is on a random arcade game, in my opinion).

MAME recently had the entire core timing rewritten to deviate no more than 1 cycle in 5 minutes at 96 MHz. My personal PC deviates more than that based on the temperature! (it can deviate up to 1 Mhz, under normal conditions). Snes9x, on the other hand, cannot get the SPC700 closer than .2% off, enough that some games require an overclock to something like 4.8% off to work. Mind you, Snes9x has the best timing of any SNES emulator. That's all the better it gets, because everyone's APU timing is relative to the main CPU (something MAME doesn't like to do), and Snes9x is considered the best at main CPU timing. (Well, this is what someone on another project told me, based on last released binaries).

The usual response when I bring this up is "we aren't MAME". Great. Nor should you be. But damn, what the hell is the problem with trying to learn from their strengths? Why is a legitimate concern blown off so casually? Yes, we don't have 5 billion programmers, and emulate 2 million systems. However, the number of games we do emulate is actually comparable. As of .72, MAME emulated 4083 sets, for 2319 unique games. For the SNES, there are roughly 1700 rom dumps that are considered clean. A few are duplicates, (1.0/1.1, etc). Given that there are unique games to other regions, 2319 is a bit of a reach, but 2000? maybe unlikely, but within reason, possible.

What that means is that a SNES emulator is, game-wise, on par with MAME. We're talking a big-time project, that emulates thousands of unique games, and many more regional ports. Shouldn't the self-imposed standards be as high and absolute as MAME? They aren't. They just aren't. Yes, we aren't MAME, but is that any excuse for us to be defiantly inferior? Does not the SNES deserve the most exacting emulation of any system? Or is the relentless drive to perfect second to being able to play our games on a 9 year old systems?

The simple truth is that in SNES emulation, unknown games take a back seat to popular games, and doing the job right takes second place to speed. Perfect emulation is less important than getting one more game to run. I'm not happy with these standards. Just like the special chip situation worries me, when every game runs, are we suddenly going to care that R-Type 17 and 7/8ths has its collision detection off a pixel? The priorities that exist right now are not sane, nor sustainable. To be sustainable, they need to count every byte of address space important, every clock cycle, and every pixel, and every output bit as vital to the project. Anything less, and you fall into good enough syndrome (more on this later. It seriously annoys me).

Yes, we aren't MAME. In some ways, that's a good thing. We want to do one system, and do it well. However, if ourt standards for doing something well don't meet or exceed MAME's standards, what basis for pride do we have? What right do we have to discount their successes because "we aren't MAME"? Have we earned our right to defiance, or are we defiant to protect ourselves from the need for major changes? In the end, we need to make major changes that MAME welcomes. All of the developers know that SNES emulators are poorly timed. I've personally made sure of that for 2 years. However, has anyone seen the major changes needed? I can tell you the answer is "No", and the reason is "no one is willing to agree to a plan that does not meet their priorities". Since emulating the SNES fast on a low-end system seems to be a high priority, you can see the foremost problem.

One developer told me that there's no need to revisit all the carts to see how they are wired "because HiROM and LoROM are good enough, if you emulate the MAD-1". I found that unsettling. We know the internal header is a convention, not a requirement. We know that the convention is not rigidly followed. We know that some games require sram in a certain area, while others on the same type of map forbid it. Why shouldn't we be trying to document the exact mapping of every cart? Is it really good enough to rely on conventions that are decidedly not enforced, or to hope every cart wired with off-the-shelf TI chips will act just like a Nintendo-designed address decoder? (There's another angle to this, which I will bring up later) For what it's worth, (probably nothing. I quit, after all) most games *do* work in those bounds. However, my core contention is that it isn't good enough to stop at "it seems to work OK". We should have the aim of making sure every game *does* work correctly, and that starts by making sure when the emulators access a byte, they get the right byte. Not "we think it probably does", but "we know that it does, because it uses this wiring, and that means this byte is here".

Of course, equally troubling is the developer who repeatedly told me that "porters are upset" because speed was traded for accuracy. That's a reason to be upset??? It should be cause for celebration. New games worked because of it. Code became possible because of it that removed hacks, and fixed other games. If the porters are upset because of that, I think we have a community problem. We have a set of visions so conflicting that we're always pissing someone off (usually me). Accuracy has a price in speed. That's one of the first rules in emulation. Why should there be a problem with paying it when the benefits are clear? The same developer heard a proposed timing systme for any SNES emulator that was serious about accuracy. The first response "The porters would hate it". I have a hard time figuring out why a core programmer should care. If more games run on fewer hacks, the core programmer is a credit to the project, end of story. Virtually every NES emulator with a high quality sound option needs more CPU power than a SNES emulator. I agreed with anomie about adding the OpenBus emualtion and I get "The porters are upset". Let me say publicly that if people are upset over that change, "I'M BLOODY GLAD YOU ARE UPSET!"

Mind you, I'm using this particular person because they know who they are, not because they are the only person to express some kind of opinion on the subject that I find utterly opposed to what I consider both the goal and the sustainable path in SNES emulation. There are others. It's a person I can also count on to understand they are used as a concrete example (and hopefully, understand why I think identifying who they are is a bad idea), not because I believe they should be targetted for being "Anti-progress". They aren't, we just have different ideas of progress that can't be harmonized. The timing system mentioned above? It was devised *since* I quit SNES emulation, which is why it will most likely never see the light of day in code form.

I consider both of these cases examples of low community standards for where we are headed. The phrase "good enough" should not be in our vocabulary. "Good enough for this release" can be in there, but simply to state that some arbitrary level of probability is "good enough"? Shoot me if this is our future. Just shoot me now. Anything less than a ruthless pursuit of perfection is not enough. Is our goal to emulate the SNES on every toaster, cell phone, and lightbulb with a CPU above 10 Mhz, or do we want to emulate the SNES perfectly on whatever non-SNES platform can pull it off first, and go from there?

"Ok, Matt, you can rant and rant and rant, but if everything is going the wrong way, what is the right way? And don't stop at idealistic nonsense. Show us that you really thought about this. Give concrete steps." With great pleasure. Of course, let me feed you the idealistic stuff first, to foster a warm and fuzzy feeling.

SNES emulation is by those who know and love the SNES for those who know and love the SNES. In fact, we should love the SNES so much that only total perfection is adequate. That means base system, special chips, and individual carts. It means that almost all of our code is suspect, and nothing is sacred but the real hardware. Not speed, not porting, not tradition, and not handy labels for a sloppy convention. It means when we see a game with timing issues, we should take that as a sign that we need to review every instruction emulated so far, and make sure the emulated timing matches the SNES. We need to question whether the cart is mapped right, whether the sound emulation is off, and that's affecting when a sound loop ends, or whether there's a bit off in some register that is causing an extra loop that is unnecessary. It means we need to be dilligent, proactive, and willing to make any tradeoff needed to benefit the core. If we don't love the SNES enough that "good enough" means "the best we know how to do at this moment", do we really love it? On any given day, we may not be able to reach perfect. But we need to ask ourselves "is it possible to do better?" If the answer is yes, we need to do better now, rather than later.

How do you do that? For starters, the timing system. Every SNES emulator except maybe MESS emulates the SPC700 in ratio to the 5A22 (the SNES 65c816 clone). BAD! Each chip should be emulated independantly timed to a fixed clock that is the same for the NTSC and PAL 5A22s, and the SPC700. Aaron Giles made an integer timer system for MAME that would probably more than suffice. Given that, you need proper cycle interleaving (basically, each processor emulates one cycle at a time, even if one needs to execute 2 or 3 times in a row before the next CPU is ready, it emulates 1 cycle, then 1 cycle, then 1 cycle). For that matter, there's a difference between "cycle" and "opcode". opcodes should have each cycle emulated separately, since the SA-1 is at least 3 times as fast as the 5A22, and it's plausible that the SA-1 could write to a location the 5A22 might read before the read, even in the 5A22 starts the current opcode first. How? any multicycle datapath breaks opcodes into stages. Each stage takes some amount of time that is known. It's part of getting better use of the same clock speed (and a precursor to pipelining). The longest instruction is no longer the length of all instructions. Rather, each instruction takes time based on the work it does. By emulating each stage as an individual act, you're closer to the actual hardware, and you improve the cycle interleaving to be more realistic.

Next, you need to go through and document exactly what every cart does with its address lines. Then you need to turn that into memory mapping code. That clears up every ambiguity of what byte the cart returns where. You now *know* what the game sees on a specific access. It's not a guess that it probably conforms to the most common MAD-1 configuration. It's a hell of a lot of work, but wouldn't you say you'd rather we knew and emulated that? How you store that information is a different matter, and a separate debate.

Those are the large, widescale means. However, even with an improved engine for timing, you need to systematically verify every event timing, make sure all reads and writes are managed through a controlled mechanism, rather than read through a pointer. Some games may actually care, after all, and it avoids uncertainty.

Next, systematically verify the function and read/write periods of each function, as well as when they take effect when written (for example, does a register writable during display affect the current scanline, the next scanline, or the next tile row?). Implement the renderer such that all surfaces describable by the SNES exist when appropriate. Systematically torment every concievable corner case, and make sure that the renderer conforms to them. Color blending must always use the full 15-bits of precision, and should be verified using visual inspection, particularly blends involving black. Priorities are pretty much, I believe, emulated well currently, thanks to anomie's efforts.

Make use of the SPC700 communication ports to make sure samples are decoded bit-perfect, gaussian interpolation is used correctly, and envx values are correct. Make sure all features are implemented, and that sample generation occurs at the proper 32000 Hz (really, this is related to how many APU cycles have passed, and should be emulated as such).

The next thing you need to do is scrap the DSP-X simulation in favor of per-cycle emulation. Sure, you don't notice the game acting oddly, because it waits for an IRQ. However, some of the DSP-X ops look like they really would benefit, as far as implementation, if a complete DSP was emulated.

For that matter, get every special chip emulated in the fashion recommended above: time them all off a fixed source unrelated to what kind of output to TV we are pretending to emulate. It may or may not fix SA-1 and SuperFx issues, but it cannot hurt (except for the speed of things, but on the other hand, you'll know that the timing is really good, so any emulation errors are probably logic, not timing).

At that point, I'd say almost every game will function correctly. Note, aside from fixing the timing as soon as possible, and perhaps then touching up all of the sound generation after that, it is possible to carry out some of these steps outside my recommended order to possibly better effect. Getting into how to handle specific cases is beyond the scope of this rant, but things like OAM addressing during display, I can probably cook up a test *design* in short order. Actually implementing the tests is a different matter, and I have never had the personal capability of running any test that doesn't involve playing a cart normally on a real SNES.

Instead of aggressively trying to remedy the flaws of designs that were cooked up when a P2 was either a rumor, or the hottest thing we'd seen in the home market, we cling to the old design because it's free, and/or because we've always done things that way. We can neither afford to be traditionalists, nor iconclastic. Simply put, the old order does not need to be overturned if it is in fact moving with the times. However, much of just about every emulator is so 1998 vintage that it's pathetic. We do need to modernize.

See, the problem is that, in the end, we can't just refine everything and wind up perfect. It requires some aggressive revisiting of exactly how we emulate. To sustain the drive to perfection, we need to admit the core system is not only essential, but is the center of our efforts. If we deviate from that stance, in thought, or word, or deed, then we lend ourselves to reaching a cliff of expectations, and it's a long drop. Rather, we need to make a concerted effort to audit our existing work and modernize it. No one is currently doing this, but without policing ourselves, we pass the problems off to another generation less prepared than we.

We're not the warez kiddies who want free games at 60/60 all the time. We're the people who supposedly revere the SNES as part of our gaming heritage. However, if we don't adhere to top notch standards, and a near obsessive regard for minute details, are we really going to ever achieve the perfection die the SNES? I don't see it happening, because I don't see the cycles already in play breaking. We'll see continued developer turnover, problems left by the original developers will persist to the next generation of coders, and eventually, we'll find ourselves without willing coders, facing problems that can be solved by acting while the main pool of coders still remembers the SNES as a vibrant system.

Revolutionary changes are needed to keep pace with other systems that have a more entusiastic coder base. The sense that the conventions are "good enough" cannot continue to cut it forever. The culture of emulation takes a severe toll on coders, and that's not changing any time soon. So barring a radical change in somethin too vast for us to shift, the SNES community needs to make its statement now. Will we show an effort to systematically verify what we emulate, or is it "good enough" to have the games look right to us? The gamers of the future will judge us by our answers. As it stands, we will fade away, chained to the inadequacies we failed to remedy.