Matthew Kendora - Mar 16, 2004
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.
Overload - Mar 16, 2004
When I first started in SNES emulation there was no documentation on the SNES except for the docs that Yoshi had written, hardly enough information to even warrant starting work on a SNES emulator. At the time Snes9x nor ZSNES were open source and the only net access i had was at Uni. I started in Emulation because I loved playing the SNES, it still gets more playtime than my Nintendo 64 and Gamecube. 6 years later I still find myself actively invovled in the SNES community. A little over a year ago John asked me to work on the dsp-1, a project that i have lead for the past year. I would love to see the chip emulated perfectly as would the other developers that have helped along the way. I also think that those developers having little to do with the SNES core, would find working on a special chip more interesting and beneficial. I think another question that one needs to ask is whether working on this project is going to be of benifit in my future career. Any one of our developers can say that they helped design a fixed-point 3D math digital Processor.
It's your choice Matthew whether you no longer want to work on Snes9x, but something tells me that you do. Maybe what we need to document what we know so that future developers understand what we have done and how everthing works.
Matthew Kendora - Mar 16, 2004
Overload: It's not really that I want to work on Snes9x. It's that there were a lot of things I left undone. That doesn't sit too well with me, but I'll have to learn to deal with it. Snes9x is in no way an option for me. It would take a dramatic change to alter that. I don't see that happening, considering how things were dealt with when I was too stressed to work on 9x.
I feel that if I were to help out again, it would turn out that not much changed, and it would eventually lead swiftly back to the same problems that caused my vacation in the first place. That's half of why the vacation never ended. If I came back, I didn't see any signs of a real environmental change. If I had came back from vacation, I would have been right back out, and in a worse mental state. The other reason I never came back is simply that, when I wasn't involved with the project, I enjoyed life much more. I didn't have the energy to work just to get an opinion on whether a major emulator behavior should be modified. Nor do I intend to go back into any situation where that seems remotely necessary.
I think everyone would be best served by assuming that you'll never see another line of code from me in a SNES emulator.
Nach - Mar 16, 2004
Thanks MK.
I question wether all of us are really misguided. I feel that a lot of our issues have come from a lack of knowledge. There are so many things I would love to fix and improve to perfection, but I simply lack the knowledge of what the correct outcome is. That problem may lie within the people capable of doing research. Most of our research we have being conducted lately is for the more exciting special chips and not base components.
A lot of ground that I covered with NSRT was from my wanting to perfect the tool line for the SNES. I started with nothing but a bunch of ROMs to study, I did my own research and ignored all the "wisdom" out there. Initial research was very easy to come by, later on I had to ask people to get me info on different matters, but none of it was hard to come by.
SNES core emulation on the other hand is an entirely different matter. Where will I get correct info? What kind of research can I do if I need special hardware to do it? Sure there are docs out there, but except for the ones written by anomie there's nothing for me to get verified info from.
Regarding the speed demon among us. I can't speak for all of us, but I would not want to sacrifice correctness for speed. Sure, when someone does something that severly affects correctness, I should be satisfied that we now do it properly. But did we implement it in a fasion that is reasonably efficient? Could there have been a better way? If something which ran on a 30 Mhz CPU last week now needs a 200 Mhz CPU, I feel compelled to look into speed issues. Sure we do it right now, but MK, was speed considered at all in the implementation? Perfection is of utmost importance, but we can't be sloppy about it either. When Andreas Naive supplied us with S-DD1 code which was correct, did we just accept it and be done with it? No! anomie went ahead and improved the implementation. If after 200 Mhz is the new minimum no matter how we try to optimize, then so be it, I'm happy.
Overload: about how working on this may benefit your career...
I must say working on ZSNES has helped me a great deal. Before I joined ZSNES, I've worked with assembly before, but wasn't that good with it, and used it rarely if at all. After joining, my knowledge and abilities to work with assembly have really improved, and my understanding of how many lower level mechanics worked was greatly enhanced.
Working with assembly to such a great extent has also expanded my problem solving abilities. Only on ZSNES have I been stuck into a situation where I'm left thinking "Others have implemented this using 7 variables, but I am only able to use 4. I must find a way to write this code using 4 variables."
That however is not all the benefits. Since unlike work where 2 coworkers and possibly my boss review my code, I'm writing code which people all over the world will review. This has pushed my ideas how to clean up code to new levels. Recent performance reviews from my boss have shown that my work on SNES emulation transfered to real skill in day to day coding activities.
For your resume you might not be able to express your improved skill, but you can write things such as "Worked on a 100,000 line project with 12 other people." or "Headed research, design and implementation on 4 complicated mathimatical sub systems within a large project."
Back onto the subject, we do have a problem, and redesigning many core features seems like adding on and fixing up rooms in a run down building.
Is building a new emulator from the ground up with new enhanced knowledge and better ways of doing things the correct answer?
Maybe, but as MK did express we need the proper motivations when doing so.
anomie - Mar 16, 2004
Time for me $0.02, I guess.
Personally, I see it as a major loss that MK has quit SNES emulation. While we haven't always have agreed on how to go about certain features, MK has made an incredible number of important contributions. Unfortunately, for some reason everyone with a complaint went to MK until he was fed up with telling them NO. Maybe what we need is a secret developers' emulator, coded by secret developers and only occasionally released to the public through trusted third parties who will handle all the flames. ;)
If only I had more time, and more equipment. I have a copier on loan (thank you!) so I can at least run any test I can find time to write. But there's only so much that can be determined through software, in particular the best I can do for just about any timings is to latch the PPU repeatedly and hope that I can statistically determine when the event may occur based on that. And i've yet to find anyone with oscilloscopes and such who can attempt to directly measure various clocks, rates, and timings. Hell, I haven't even found anyone who can tell me for sure the PAL master clock rate...
As for rewriting the emulator from scratch, if we could get enough talented people with enough time that we could actually make progress it would be a good idea. But as it is....
Evan - Mar 16, 2004
Before any new project can be started, collecting information is a must. I have thought of doing this myself, but I quickly realized that my lack of technical expertise would inhibit this. There needs to be documents of what is known about ever aspect of the hardware, and this needs to be published in a well organized document, not just forum posts, which are not static. This is my recommendation. If the documents are made available, I guarentee that there will be people interested in creating the new emulator other than just Trac and Matthew Kendora.
Matthew Kendora - Mar 16, 2004
The problems with a new emulator aren't just information.
It's one of many things I think would prevent a new emulator from going very far, save if it didn't get entangled into the current SNES scene.
It would need to be independant of everything that already exists (if it isn't why start a new emulator?), and so it would be literally a scratch effort.
First, that means coming up with a design that actually allows you to fix anticipated shortcomings without a massive rewrite. That includes possible memory mapping issues, the addition of special hardware, and easy addition of read/write limitations by time.
If you don't know those things, there are two options: don't start until you have everything you need to know, or start by considering what areas will be revised by later information, and make sure they are coded in such a way that the structure of the code is conducive to the changes that need to be made.
So let's say you wait for the information. The more you know, the more you realize you don't know. Will you ever get started?
So you go the other route, since that has a defined starting point. The immediate problem is that you'll realize that eventually, you will hit unexpected obstacles, and probably rewrite code. Such is the danger, but the best you can do is minimize the number of total sectional rewrites needed. Even so...
let's say you start with the timing engine. That can take quite a bit of time, but even so, nothing is emulated. YOu just have a foundation to work from now.
So next comes the CPU core, right? well, that can take several months. You've got, not a SNES emulator, but a 65c816 emulator, timed to match the 5A22 of a SNES.
The various SNES registers need to be emulated. Years ago, this would have taken maybe a week to do, and years to do well. Now, it would take around a month to do, but that month will be spent on better results. Of course, this still doesn't actually let you emulate even a CPU-only SNES game, because you still haven't mapped the registers.
Memory mapping is, as far as I'm concerned, the hidden evil of SNES emulation, because so few people really understand what their emulator does. In Snes9x, this was almost exclusively my territory. In ZSNES, the system is fairly well understood by the active developers, but I would wager it's also more difficult to verify as a consequence of how it works. In any case, the new emulator would need its own memory mapping system.
Once those are in place, you'll actually be able to emulate a SNES game... if it doesn't any unemulated features, and you only want a CPU trace.
However, DMA is a given, and that's not emulated, nor is HDMA. Add those on, and correct what are perceived (and most likely true) issues with the current emulation, and you're looking better. In theory, now, your core runs anything that doesn't use the sound CPU.
There's your next feat. Emulate the SPC700 CPU. That doesn't cover sound generation, just the programming. Thanks to years of refinement, many of the problems that plagued early cores can be side-stepped. The more exotic registers available here, however, require sound generation.
Assuming your timing engine is good, this isn't so difficult. Snes9x is mainly held back because of timing constraints here. If you do things right, then your compatibility is pretty good.
Now, there's just one thing left: a renderer. Items like Mode 7 will be much more accurate than older SNES emulators, because there has been a lot of work done here, and you can debut at least on par with them. Others, like Mode 6, are pretty much unemulated currently.
Since each of these tasks is liable to take at least a month each, and items like CPU cores and renderers are likely to take several months each, you can see there's a significant time investment already.
Oh, did I mention you've got no special chip support, nor a user interface, nor actual display code, sound output code, and input code?
There's a reason not many people want to start a new emulator project. The inital time investment is pretty massive, and the end result, while superior to most emulators in accuracy, would have fewer features, and no special hardware support, and you'd get a lot of criticism for the fact that it has lower speed and doesn't play a lot of favored games.
Of course, where you'd host the emulator, and things like that enter into it. A bare minimum emulator could easily take a year or more, and in most minds, would be "inferior" to the current generation. Not to mention hosting, legalities (such as what you do when some programmers outright insist on GPL while others refuse it), and all the other good crap that you need to deal with. And, of course, the problems inherent in any group come into play...
[Addendum:]
I'm not saying people shouldn't start a new emulator. I'm just pointing out that rewriting 99% of an existing project is, in many ways, the path of least resistance, and that there's really a lot involved in truly starting a new emulator. I can see why no one has gotten sick enough of dealing with the current generation of emulators to start fresh.
By all means, if someone feels it's really worth it to start from scratch, and everything I highlighted doesn't deter you, go for it. Find good people (for starters, avoid me. I'm no longer a good choice, despite what I may or may not have done), and show everyone that it was worth it. If you lay a good foundation, when you go to add the SA-1 or SuperFx, you'll find that many of the timing issues in current emulators are pretty trivial, because you started off on the right foot.
© 2004 SNES9x forums - archive.is/QSYP2, archive.is/JbYJG