byuu's message board

For discussion of projects related to www.byuu.org/
Last visit was: Sun 15 Mar 2015, 01:00:45 It is currently Sun 15 Mar 2015, 12:21:19




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 392 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 27  Next
emulator efficiency 
Author Message
User avatar

Joined: Thu 22 Mar 2012, 04:37:56

Posts: 502
Reply with quote
Post Re: emulator efficiency
Yes, that's called emulation.


Mon 26 May 2014, 18:36:38
Report this post
Profile Send private message

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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.


Mon 26 May 2014, 18:41:55
Report this post
Profile Send private message
User avatar

Joined: Thu 22 Mar 2012, 04:37:56

Posts: 502
Reply with quote
Post Re: emulator efficiency
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.


Mon 26 May 2014, 18:45:55
Report this post
Profile Send private message

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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.


Mon 26 May 2014, 18:50:44
Report this post
Profile Send private message
User avatar

Joined: Thu 22 Mar 2012, 04:37:56

Posts: 502
Reply with quote
Post Re: emulator efficiency
http://www.amiga.org/forums/showthread.php?t=66798


Mon 26 May 2014, 18:51:20
Report this post
Profile Send private message

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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.


Mon 26 May 2014, 18:58:25
Report this post
Profile Send private message
User avatar

Joined: Wed 26 May 2010, 19:48:00

Posts: 708
Reply with quote
Post Re: emulator efficiency
SoraK05 wrote:
GC shows requirements are not too high for an accurate emu.
That's because it's not accurate at all.


Mon 26 May 2014, 19:03:00
Report this post
Profile Send private message

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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?


Mon 26 May 2014, 19:16:57
Report this post
Profile Send private message
User avatar

Joined: Thu 22 Mar 2012, 04:37:56

Posts: 502
Reply with quote
Post Re: emulator efficiency
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).


Mon 26 May 2014, 19:29:57
Report this post
Profile Send private message
User avatar

Joined: Fri 10 Apr 2009, 18:17:56

Posts: 3308
Location: Germany
Reply with quote
Post Re: emulator efficiency
SoraK05 wrote:
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?

4 colors (shades of gray), not 2.

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

Code:
pixels[y * 144 + x] = <some gigantic formula>

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.

_________________
"The first time I watched [FLCL] I was like 12 or 13 and I was scared and confused." - isthisagoodusername
"I think it's more natural for human beings to be anxious. I think happiness is nothing but an illusion." - Hideaki Anno
"If you can't joke about incest in anime then what kind of world are we living in?!" - gothicmaster


Mon 26 May 2014, 19:35:46
Report this post
Profile Send private message WWW

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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.


Mon 26 May 2014, 19:43:10
Report this post
Profile Send private message

Joined: Thu 19 Nov 2009, 16:18:55

Posts: 1586
Reply with quote
Post Re: emulator efficiency
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.

_________________
My Emulator Repo for Debian/Ubuntu/Mint/etc (includes bsnes, Retroarch, libretro, VBA, Nestopia, Dolphin)


Mon 26 May 2014, 19:52:38
Report this post
Profile Send private message

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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.


Mon 26 May 2014, 19:57:15
Report this post
Profile Send private message
User avatar

Joined: Thu 22 Mar 2012, 04:37:56

Posts: 502
Reply with quote
Post Re: emulator efficiency
And that's how HLE works.


Mon 26 May 2014, 19:59:59
Report this post
Profile Send private message

Joined: Fri 26 Oct 2012, 14:47:06

Posts: 81
Reply with quote
Post Re: emulator efficiency
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).


Mon 26 May 2014, 20:07:07
Report this post
Profile Send private message
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 392 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 27  Next


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: