byuu's message board

From this text seems that he really is a begginer in programming, and now he's starting to understand what a processor and emulator are.

Probably some years from now he'll laugh at himself for such an epic topic.

But I totally did that on purpose. I also sing that song out loud whenever I have or even glance at my Kenyan AA coffee K-Cups.

We all begin somewhere, driven by ideas bigger than us, and I like the passion the guy puts into it. Grasping the basics is usually the longer step, but the most crucial too.

As long as each opcode has its own function to represent and is ordered in the appropriate systematic step-by-step approach that would be done on the SNES with an algorithm, including virtual buffers for what the SNES hardware would use, the result is some calculations to get what the output strings going to video/sound/temp would be and the rest is faked pauses to keep in sync - one burst of calculations to get numbers of each 'frame' or other expected calculation in the appropriate steps and the rest is just to output/sync.
This can be finetuned to suit steps done by other architecture.

Anyway, thanks for the post about sync (which is considered in an algorithm where each step should be appropriate to those done by SNES and its opcode steps to match the 1:1 scheduled list - for being specific for archival purposes following traces can assist in developing the representation and formula).

Gold. Absolute gold.

The point is to do the math in one go, and then sync things like outputting video/sound. A block of calculations based on formulas for each opcode in the step-by-step manner which the SNES would in general would be able to accomplish doing a chunk of calculations and then having numbers ready for output in a synced manner.

A specific formula for each opcode and having them operate step-by-step should give the right compatibility - something by design in the algorithm which should cater for calculating any ROM appropriately, and having the focus on doing the calculations in a chunk and syncing appropriately for a thing like output is not something 'all emulators do' and is a means to getting those numbers appropriately.
Tweaking the steps to suit opcodes available on x86 hardware and doing a block with syncing in mind for input/output will be functional and have compatibility suitable to the console.

The point of the thread is about the efficiency, and where each opcode is written appropriately for its steps there should be compatibility suitable to the console for a ROM, and each should function step-by-step as the SNES does. With syncing in mind for interaction of input and output (like fps), the calculations can be done in a go for the respective numbers, and any outputting when met will be treated as going to the PC monitor/speaker for example.

Clearly not every emulator does it, and this has the calculations in the shortest steps in mind to get the right numbers and parameters for syncing / global buffer.
An accurate emu which gets matching output numbers for a ROM with syncing/buffering in its algorithm does not mean high requirements. The right data is retrieved and output more appropriately than emus in general on VC and it can handle its games at full speed - OOT runs on GC.

Anyways, thanks.

I'm sorry. No modern desktop computer is powerful enough to parallelize a circuit level simulation of such a complex piece of hardware. At least, not anywhere near real time.

For reference, there is Visual 6502, a circuit level simulation of the 6502, capable of acting as the core of the NES. On my Core i5 3570K, it can simulate a 326Hz processor. Consider that the original Apple II+ had a 6502 clocked at 1MHz. That's one 3067th the speed right there. For circuit level simulation in software.

There's also more recently (a few years, perhaps) a Visual 2C02. On this same system, it gets 171.3Hz, which is one 125394th of the speed of the NES master clock fed to the chip. Circuit simulation in software.

Now, I know you suggested something massively parallel. Indeed, circuit level simulation would greatly benefit from all of those virtual transistors being run in parallel to each other instead of in a serial fashion.

You know what we do to run so many transistors in parallel in a software fabricated device? We program an FPGA. That's Field Programmable Gate Array. That's right, you can take a FPGA device, program it to simulate a circuit completely using software circuit designs, in the field. Of course, this isn't usually as flexible as loadable computer software, and is usually fixed to one process. However, most modern FPGAs are now reprogrammable, which allows their circuits to be redesigned. Again, still not quite the same as computer software.

With FPGA, you're not emulating or simulating the original function of the device with a series of operations, performed end to end. Instead, you are simulating the original circuitry at the electrical level, with all specialized operations hopefully running in the correct lockstep fashion as the original pre-fabricated components. FPGA is usually the next best thing compared to having your own silicon fabrication operation.

Two different things. Computers today aren't really parallel enough to simulate circuits efficiently, and FPGAs aren't really powerful enough yet to replace densely populated pre-fabricated processors with established instruction sets. Maybe one day, this gap will be bridged.

Wait, did I just fall for a troll topic?

Accuracy DOES require high system requirements, as more accuracy is more code running every step.


The Virtual Console emulators ARE NOT ACCURATE.
Ocarina of Time on GameCube, if it is emulation and not a port, is not accurate N64 emulation.
Both are just accurate enough to run the games they are fed without glaring audiovisual errors.

I don't know how else to put this. Just because a carefully-selected handful of games appear to run right at a casual investigation DOES NOT MEAN THE EMULATOR IS ACCURATE.

In fact, there are known and documented gameplay differences between the N64 and GameCube and Virtual Console versions of Zelda 64. All three versions behave differently. That is documentation of emulation inaccuracy right there, so STOP USING IT as an example.

Can confirm that the GC OoT emulator doesn't even run the japanese n64 version of animal crossing properly, which is supposed to be vaguely based on the zelda 64 engine.

We've pretty much reached the upper bound on efficiency.

We can go faster if we do certain parts high-level, such as the various DSP chips available to the SNES, but then we'd risk getting things wrong -- blatantly or otherwise. Doing them low-level reduces such risks significantly. For example, SNES Pilotwings uses the DSP1. The DSP1 has multiple revisions, but they all basically have the same functions. If you high-level emulate the DSP1 (ZSNES, Snes9x...) you run these functions by your own code, and hope you observed things right. If you low-level emulate it (bsnes/higan), that is not catching the function calls and running your own code but actually running a separate processor with a fixed program (loaded from ROM like the game is), as long as you emulate the processor right you will get the right results. If you've read this, say banana. And in Pilotwings, suddenly a fun little error occurs: on one revision of the DSP1, the player's movements will be off and cause a death-by-impact at one point in the demo loop while another revision gives slightly different results and the player's movements are just a little better and nothing happens.

Better example? Mega Man X2. Its extension chip is used to do 3D transformations, vector animations, and a bunch of other things. HLE, it did these things and did them passably well. When they did the LLE emulation for that chip, it turned out that it didn't have its own program ROM -- the game ROM contained that, and it was Mega Man X2 itself that determined its extension chip would do vector animation and all that. So even though MMX2/3 ran perfectly well in ZSNES (haw haw!) it didn't actually do so in a nearly accurate way. If a third game with that same chip were to appear, and use it do to something else entirely, it wouldn't work on HLE and hilarity ensues.

Banana.

If you read this, send $5000 to my Paypal account.