byuu's message board

Yes, that's called emulation.

How are emulators so different from accuracy/compatibility/requirement if equations to resemble the motherboard arithmetics is what the 'emulator' is, to result in (the same) numbers per second.

And considering OOT on N64, and is similar for the VC Wii emu, I would say in general besides some minor compatibility things that it is ideal - the output for MD / SNES is reminiscent of the original e.g. Emus don't look/sound like it per se.

They're so different because they use different math. There are endless ways to come up with similar results, but they have side effects, like being hard to compute, having weird performance properties, implementing the original hardware poorly, etc. It's still math based on the hardware's behavior, though; it's just usually shitty math. Making the math work well on top of another platform is a huge effort, and that's the whole point of bsnes.

Where the math of the motherboard is written exact, shouldn't any ROM load and run with 100% compatibility?

Also, where a tweak is done to put the video pixels to the PC monitor and sound data to speakers like an inbetween tweak to the system, should this not be complete?

GC can do OOT, and bsnes is meant to be accurate yet requires relatively large specs.
I'm wondering if the math can be simplified to be all done in the steps on processor / video card and just use the results to 'play'.

GC shows requirements are not too high for an accurate emu.

Some math is used to move bits around, and then math is done to determine states/result for output.

Some steps are clearly console specific from architecture and can be shortened/rewritten to suit more appropriate mathematical formulas to end up with the same general flowing data.


The steps don't need to be exact to the console - just essential calculation as math to transform the ROM data to the output data.

And thanks for the link btw - it demonstrates (to me) that bit level math to architecture is unnecessary if one were to for example use a pen and paper to do equations on the ROM for a general consistent flow of expected data.

That's because it's not accurate at all.

The motherboard has a collection of paths and their own respective equations.
If all were mapped appropriately and receptive to data (like a ROM), all should function?

http://en.wikipedia.org/wiki/Game_Boy
It is generally considered low spec.

It is designed to compute two colours, work with 160 × 144 pixels per frame, has its architecture and capacity of computation to provide the numbers for sound/video each second of 4.19 MHz.

This looks like something incredibly light where if each motherboard equation was appropriately written 1:1, when fed a rom the expected output of pixels and sound, as well as input for buttons to affect motherboard expectations could calculate the numbers for each second of data in something not too much higher (like 10x times) than 4.19Mhz where all motherboard calculations / arithmetic are done intensively on a processor and the output is just fed to monitor/speaker.


It would be a relatively short list of possible equations which can be met, and the rest is the repetition of these and rom data
Compatibility would be 100%?

In principle, the list of equations is generally short and the rest is cycles and repetition of these in accordance to rom expectations which requires the cpu speed for this? And this can be modified to be more direct where a shortcut is applicable and non-intrusive?

You are basically saying "Writing an accurate emulator shouldn't be hard, look at how simple the consoles are!" with zero regard for how the relevant math works, zero regard for the decades of research going into emulator development, and zero regard for the people telling you to slow down and look at things from a slightly different perspective where instead of "math" you think "instructions" (because computers use instructions, not math).

4 colors (shades of gray), not 2.

Are you proposing that an emulator should calculate a function like this?


This would make the emulator very inefficient and very hard to read.

And if you write down code for each component of the machine, it would make the emulator much slower.

I'm referring to the machine code being a set of mathematic formulas performed on the ROM data, and the computer being the environment to do the math.

Where one can relate the calculator design which takes machine code a set of mathematic operations, the ROM data can be calculated for direct numbers of expected output using the ROM data.

i.e. all video data per second is in the ROM and is done in a series of mathematical calculations. A formula is what I am referring to, which when performed on a ROM will get the exact same video data per second - i.e. a formula for the device which can run on a ROM and accept input for identical number output (with applicable shortcuts/tweaks).

And I am open to learn.

I know I said I wasn't going to get involved in this thread, but it appears SoraK05's misconception stems from a belief that a "motherboard" is basically like a DSP, where you feed in a bunch of "numbers" (the ROM), it performs some specific, reproducible function on the numbers, and then outputs a series of resulting numbers that equate to blips and bloops on the screen and speakers, respectively (not sure how s/he thinks those numbers get transformed into said blips and bloops, but whatever).

This is not at all how modern programmable computers or consoles work. It is similar to the way ancient mechanical "computers" worked, sort of: provide some input, turn a crank, out comes a transformed output.

If it were how computers/consoles worked, then yes, you could just figure out the "motherboard's" internal function and run the "numbers" directly on a modern computer.

I still think portions of a ROM are 'instruction/machine code' to perform maths suitable to the hardware design, sections of a ROM are taken directly (rather than used as instruction bits), and mathematic conversions are performed on the ROM data to provide all numbers/bit strings used for the video/sound/etc.

Where some math can be done directly on a ROM in appropriate steps which suit, the same numbers should be reproducible.

And that's how HLE works.

Isn't what matters a suitable formula (with tweaks where not intrusive) to get the identical output numbers when performed on a ROM that can be used?
The same numbers which in general would be in multiplatform games and 'packed' differently to suit a formula that suits the console calculation design? i.e. the resultant calculated output data?

How is this HLE? Is it not also like LLE where basic arithmetic is done to match expectations of the hardware and used on the ROM for the resultant calculated output data?

In essence it is like a formula to determine how to effectively perform the machine code instruction/calculation parts (in less steps/more appropriately where applicable).