byuu's message board

Maybe this guy should go talk to losethos? They seem to have a certain ethos in common.

This is a common proposal by people new to emulation. Unfortunately, it DOESN'T WORK.
Otherwise we'd've been doing it that way for the last twenty years).

The same assembly commands may do roughly the same thing on both processors, but they can take VERY different ways to get there, and software often relies not on the final results being roughly similar, but on the final results being exactly the same, the hardware bugs being exactly the same, and in some cases, the TIME TAKEN being exactly the same, and even the steps taken to produce the end results being exactly the same.

There will also be subtle(or sometimes drastic) differences in complex behavior, and unexpected interaction between seemingly unrelated instructions.


And again, this is still ignoring the fact that the SNES sound and video units HAVE NO PARALLEL in the PC world.
While ARGUABLY an x86-64 processor does more or less the same thing as a 65816, a RadForce HD90210FX video card behaves WILDLY different than SPPU1 and SPPU2.
There's basically no functional similarities other than they both output a picture. But that's like saying Da Vinci's and Picasso's paintings are basically the same because they both drew pictures.


No, it SHOULD be very intensive, because the not-math required to simulate one computer's behavior on another, unrelated computer is VERY COMPLEX.

You can take shortcuts, and things will kinda-sorta work. ZSNES stands as testament to that fact.
But they will only kinda-sorta work. They won't work RIGHT.




I strongly urge you to stop reading dictionary definitions and Wikipedia overviews and start ACTUALLY TRYING TO PROGRAM A COMPUTER before you offer further input on how computers work.

Only in Kenya!

I am going to hunt you down and kill you.

Hardware moves? I didn´t know that

hehe let´s take a Rom and put some hardware movement on it

You've clearly never turned on a PC with a hard drive you hadn't screwed down yet.
...
When you do, make sure you set a hand on top of that drive so it doesn't jump into your motherboard.

Hardware movement - flow of paths by steps.

All hardware, irrespective of design, will do some kind of math steps which are preprogrammed and some logic also.
The cycles in order to perform these steps is where speed/design will compliment.
The computer will do a series of preprogrammed math steps continuously with some limited logic functions (all relateable to an algorithm).
Where the basic math steps represented by the machine code (and logic) are done, the rest is cycles to do math step-by-step which should be seamless when fed input like the ROM.


http://en.wikipedia.org/wiki/File:Apple_II_Monitor.png
To illustrate, this shows machine code and the respective assembly version.
Each step in general will perform some mathematics (like compare can subtract numbers and check if the result is positive/negative) on the lowest level.

Generally detailing the math steps each machine code instruction will perform to portray the steps in an algorithm is what I mention - i.e. the math steps being done by the machine code instructions (and any further details for logic which are also mechanical).

While computer layout is different, the fundamental math ability is common and labelled/traced in alternate manners.

The math steps are universal in an algorithm, and its compilation for a system should be accommodated when the same algorithm is compiled for another system to perform the math to suit its layout. The algorithm should one step-by-step process to suit what the SNES does in math steps (and logic), relatable to the steps the machine code instructions will perform when read (including room for buffer in the algorithm for the steps), and the rest is just doing processing of each step where required.

The definition of an emulator proposes that one algorithm will detail the precise functioning design of the system, and any further tweaks can be to accommodate shortcuts where applicable (without breaking proportion).
For archival purposes, the SNES can be written in the exact algorithm of what the machine code will do in its steps, and this can be compiled (with adjustments in a functional emulator binary) for its steps to suit another architecture and its ability to perform.


EDIT:
Like a list of 'if' for machine code (opcodes) and the math / logic they will do, and a shared virtual buffer. The rest is letting the steps perform, and for some specific commands like sending numbers to video output be considered (in the tweaked, non archival algorithm) to a plugin/coding which will link it to the monitor of the device.

Believe it or not, this part is not a mathematical operation. While it is certainly closely related to math, "checking" anything isn't math.

While it may be mechanical and considered part of 'logic', these elements are considered part of mathematics and can be written in an algorithm which a computer in essence represents - the determining element after a compare for its 0/1 type response is part of the mechanical representation of this math (part of algorithm) to send signal down a certain path, allowing for current from the result and the hardware layout for this logic/math/algorithm function e.g.

W-what? Flow of paths by steps? Wtf is that?

Well, ok, now show us some code (a working emulator). Otherwise, shut up.

No.

There are much, much lower levels than this, all the way down to modelling the way electrons flow through silicon. Not all of them are important for emulation, but some of them are.


This is possible, but the result would probably be no faster or more efficient than higan, and it would take a lot more work to specialise an emulator for each game, so why bother?


If studying the hole in a doughnut is math, I'm not going to complain about checking being math.


Presumably it's a Hebrew idiom that just doesn't translate into English very well.

No, the truth is that he is writing a lot of bullshit. He clearly has not the slightest ideia about this subject.

He talks about math, but seems that he never read Turing's paper.

He is a new guy to programming that has a lot of ideas, but never wrote code related to these ideas. After coding some lines he will notice the absurd things he's talking about.

I still think he's fooling with us. Or maybe it's an experimental bot. Othewise this is an epic thread.

http://courses.engr.illinois.edu/ece390 ... HEADING1-0

http://courses.engr.illinois.edu/ece390 ... H06-2.html




Translating the steps of what each opcode will perform to math steps appropriate to the SNES ones, so that the PC x86 architecture can replicate the equations/logic.


And a PC has a flow of electricity going through paths, and the process of cycles and steps can be described as the flow of the hardware in the steps it is performing.



I have had some basic programming attempts, have some experience with LOGO/BASIC/C++ and have a general idea. I've used computers for some time.

I get that the process of emulating is to have an appropriate algorithm to calculate the ROM numbers for the same results as the SNES.
(I get LLE, HLE, Dynamic Recompiler and the concept)
I get that all opcodes read in the ROM must have a formula to relate.
Thanks.

What math operation does PUSH represent?

I feel like doing some creative writing today. May as well do it inside this gem of a thread!



Assuming you want to find out the math behind each instruction, and then map those to another completely different architecture, we can extrapolate on that.

To keep things simple to start we can use addition, since the processors will all be able to do that, and it's easy to wrap your mind around.

I hope I have all the instructions right here. Also excuse the oversimplification.

You analyses your "ROM" to pull out all the math, and you see a whole bunch of 'ADC' instructions. Okay, that's great. x86 has a ADC instruction too! We'll just map that over directly, and we're done with addition.


Now that we have that out of the way, let's move onto multiplication:

...Oh. It doesn't seem that the SNES has an instruction solely for multiplication. Ahh, but that's good news, this is what we came here for! We can gain performance here.
We can detect the method that the SNES uses, whatever it is, for multiplication and just replace it with one MUL instruction!
Now instead of all those bit shifts, additions, or whatever math magic was being done we just have one simple instruction! Performance++
On to the next instruction!


Well let's hold on now.
On my overclocked Intel 747 Wizbang Edition it takes 0.002μ seconds to do one MUL instruction.
On your puny Intel 2500k it takes 0.009μ seconds to do one MUL instruction.
Finally, the "math" that it does on the SNES to multiply takes 0.1µ seconds.

Now everything is running too fast! All the games will be running too fast! Your optimizations are way too good! It's unplayable!

Okay, so the obvious solution would be insert a bunch of NOP instructions, so that our MUL instruction finishes after 0.1µ instead. That way it matches the SNES.
But how many? My Intel 747 needs more NOPs than your 2500k.
Furthermore, because of the way modern CPU work not only do two CPU of the same type run at different clock speeds and require different amount of NOPs, but the CPU speed itself fluctuates constantly! Not only that, but your CPU is also doing more than one thing at a time, and you never know when another pesky program (or your OS) is going to take CPU time from your MUL instruction. Oh dear! Looks like there isn't really a reliable way to time how many NOPs are required.

In addition to the "running way too fast" problem, you also have the problem that the games were coded with very specific hardware in mind. A SNES has multiple chips on the motherboard, each chip has to talk to each other, and each chip has it's own time it takes to accomplish it's task.

So just for illustrative purposes let's say that it might take 1µ for the sound chip to process what is passed to it.
So in the game I'm programing using the main chip I pass a call to the sound chip that says "Hey! Here is this data, do some math on it, and pass me back the result!"
Now, I could wait for 1µ doing nothing while the sound chip does it's thing, but that's a huge waste of resources!
Instead, I want to do some multiplication while I wait! Knowing that it takes the SNES 0.1µ seconds to do one multiplication I decide to do 10, and then ask get the result back from the sound chip. Now that's being efficient!

However, once you run this in your emulator where you swapped out the multiplication instructions for a simple MUL, the ratios of how long multiplication takes in relation to everything else is way off. You are now going to be asking the sound chip for it's result before it's ready, and everything will come crashing down around you.


These are just a few massively oversimplified problems that you would run into. And even if they weren't overly simplified, they pale in comparison to the other problems that you would run into if you were to try doing things in this way. These problems are trivial compared of the other ones you need to work around.
You need to make sure that everything you do is taking the proper amount of time, and staying in the proper order, so that the different components in the machine you are emulating can actually communicate properly. If they can't, then your emulator won't work.
And wouldn't you know it? That's what the current emulators do. Doing that is literally what makes them so slow.