byuu's message board

For discussion of projects related to www.byuu.org/


 Page 24 of 27
 Previous  1 ... 21, 22, 23, 24, 25, 26, 27  Next
emulator efficiency 
Author Message
Kakashi
User avatar

Joined: Mon 20 Apr 2009, 08:11:50

Posts: 5266
Location: 日本
Post Re: emulator efficiency
trap15 wrote:
Just a quick reminder:

THIS THREAD IS 23 PAGES LONG

Do you think there's a mathematical equation to explain it?

_________________
CaptainJistuce: He's totally in the wrong, Kakashi's 100% in the right.
Note: The above statement is subject to act of byuu.
Sun 08 Jun 2014, 08:30:36
wareya
User avatar

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

Posts: 502
Post Re: emulator efficiency
pages = (rage function(miscommunication) * (concepts covered + number of trolls))^trolling potential * scale constant
Sun 08 Jun 2014, 08:32:58
kode54
User avatar

Joined: Fri 10 Apr 2009, 20:54:19

Posts: 2679
Post Re: emulator efficiency
Image

_________________
blag
Sun 08 Jun 2014, 08:41:49
CaptainJistuce

Joined: Wed 06 May 2009, 04:13:19

Posts: 4543
Post Re: emulator efficiency
trap15 wrote:
Just a quick reminder:

THIS THREAD IS 23 PAGES LONG

24. :P

_________________
This post best viewed at 800x600
;write ! ! !
Sun 08 Jun 2014, 09:56:32
wareya
User avatar

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

Posts: 502
Post Re: emulator efficiency
pages = (rage function(miscommunication) * (concepts covered + (number of trolls * peanut gallery + 1)^0.65))^trolling potential * scale constant
Sun 08 Jun 2014, 10:02:18
CaptainJistuce

Joined: Wed 06 May 2009, 04:13:19

Posts: 4543
Post Re: emulator efficiency
yourmom=in(my+bed)

_________________
This post best viewed at 800x600
;write ! ! !

CaptainJistuce
Sun 08 Jun 2014, 10:12:06
Kawa
User avatar

Joined: Sun 05 Sep 2010, 15:42:48

Posts: 1344
Post Re: emulator efficiency
wareya wrote:
pages = (rage function(miscommunication) * (concepts covered + (number of trolls * peanut gallery + 1)^0.65))^trolling potential * scale constant
Please define the rage function.

_________________
http://helmet.kafuka.org
Sun 08 Jun 2014, 12:19:47
wareya
User avatar

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

Posts: 502
Post Re: emulator efficiency
Always above zero; reaches a peak at some point, then decreases. Exact measurements unknown. Not defined for negative or imaginary input.
Sun 08 Jun 2014, 13:12:27
CaptainJistuce

Joined: Wed 06 May 2009, 04:13:19

Posts: 4543
Post Re: emulator efficiency
The highest known value for the rage function occured on August 9, 1945.

_________________
This post best viewed at 800x600
;write ! ! !
Sun 08 Jun 2014, 13:14:20
Kawa
User avatar

Joined: Sun 05 Sep 2010, 15:42:48

Posts: 1344
Post Re: emulator efficiency
CaptainJistuce wrote:
The highest known value for the rage function occured on August 9, 1945.
I see what you did there.

Update:
Image
I ask again: do you have any work to show, Sora?

_________________
http://helmet.kafuka.org
Sun 08 Jun 2014, 13:47:06
ggalitz

Joined: Thu 31 Mar 2011, 07:24:12

Posts: 439
Post Re: emulator efficiency
Exophase wrote:
ggalitz wrote:
Skipping architectural and clock cycle accuracy impossibilities, it'd be a bad idea to vanilla compile port everything anyhow. Many ROMs busy wait, so they'd tie up a core on a modern system, while an emulator would throttle said clocking to that of the arch the ROM was made for.


It'll still work if you emulate periodic system level stuff by using timer callbacks that operate independently of the emulated instructions. For example, you'd still generate vblanks 60 times a second, and you'd do it by somehow injecting interrupts into the emulated code. This is what qemu does and AFAIK it's what current PSP emulators do. If you have a whole ton of events a second, like hblank IRQs or fast timers going off, this could end up overwhelming your host system.

Another caveat with this (outside of having severely inaccurate timing) is that it becomes a lot more cumbersome to speed up or slow down the emulation without breaking things, and virtually impossible to reproduce execution. And if the emulator is too slow there's a chance you'll break the game instead of just making it slower.


What you described shows changing how many cycles you throw at said ROM theoretically can break it, which I believe "breaks" it if someone is gonna do a foolproof compile to native.

I'mma back outta this thread before we get an integer overflow on the number of pages.

_________________
ERROR: GGALITZ HAS REACHED HIS IMAGE MEME QUOTA AND CAN'T FOLLOW RULES
Mon 09 Jun 2014, 00:34:00
SoraK05

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

Posts: 81
Post Re: emulator efficiency
Sintendo wrote:
SoraK05 wrote:
Any generated code is code which will be created by the code in the ROM, and anything of the nature of taking this generated code like from RAM instead of ROM can be determined and dealt with, and either patched on-the-fly or have any possible data which is used to generate this replaced with patched data.

You can't just say "X can be determined an dealt with". You should demonstrate how, like Kawa previously told you.

Here's another question for you, though. How can you automatically tell what is code and what is data in a ROM?



The same way the game does - any data which is image data for example is part of data which opcodes+operands will identify.
i.e. any data which by opcodes+operands can be identified for offset ranges and thus acknowledged to be skipped, as well as any data which does not suit an opcode+operand structure can be skipped.
Mon 09 Jun 2014, 05:18:33
kode54
User avatar

Joined: Fri 10 Apr 2009, 20:54:19

Posts: 2679
Post Re: emulator efficiency
Ah, now we're getting on to artificial intelligence. Because that's what it would take to perfectly identify what is code and what is data with zero interaction whatsoever.

_________________
blag
Mon 09 Jun 2014, 05:21:35
rodrigoalonso

Joined: Fri 03 Jun 2011, 02:41:19

Posts: 77
Post Re: emulator efficiency
DFS/BFS starting from the init address, I guess. Follow all possible values the instruction register can take (I don't have any knowledge about the SNES, but I suppose it has an instruction register and a memory address to execute at boot). Everything else would be data, wouldn't be?

The previous algorithm will probably fail if some unreachable code is used as data, though. Then, all of the ROM could be potentially (incorrectly) identified as code. But I wonder how many games actually have unreachable code, considering the limited space developers had to work with.
Mon 09 Jun 2014, 05:38:02
kode54
User avatar

Joined: Fri 10 Apr 2009, 20:54:19

Posts: 2679
Post Re: emulator efficiency
Disabled debugging code that could be enabled with debugging hardware or cheating devices, for instance.

_________________
blag
Mon 09 Jun 2014, 05:47:13
 Page 24 of 27
 Previous  1 ... 21, 22, 23, 24, 25, 26, 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