byuu's message board

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


Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 27  Next
emulator efficiency 
Author Message

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

Posts: 81
Post Re: emulator efficiency
At the end of the day, a computer will read a file and its data, and a program will execute based on compiler and hardware design to perform the calculations on the data. All pixels calculated will be done according to the compiler setup in conjunction to hardware design to perform the calculation.
The calculation is generally identical and result, and the console use different parameters/syntaxes from their compiler/hardware design.
Like 1+1=2 is identical, and the method from layout/syntax is altered.

As the calculation is common, this is a go-between to make the ROM instructions relate to what the calculations should be so that the PC can then do the math on its design?
Each part will require some general translation for its cycle and account for processing of the conversion. The less steps (which are redundant overall) the easier? :)


EDIT:
So, LLE and 'accurate' is something like a SNES sandbox, and HLE is in a way the required data with shortcuts.
A way to keep track of the hardware constraints/commands should let any ROM be able to have a way to get its data to 'execute' and have accurate compatibility while getting only the required data (and shortcuts)

Mon 26 May 2014, 21:06:35
User avatar

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

Posts: 1344
Post Re: emulator efficiency
Even my posting this from a text-only browser running on a VPS that I SSH'd into makes more sense than SoraK05.

_________________
http://helmet.kafuka.org

Mon 26 May 2014, 22:17:29

Joined: Wed 30 Jun 2010, 22:54:37

Posts: 86
Location: Canada
Post Re: emulator efficiency
Using a SNES as an example.

> At the end of the day, a computer will read a file and its data,
False. A file is an abstract concept. The CPU could not care less what it is reading as long as it can execute it.

> and a program will execute based on compiler
False. Most programs written for the SNES were never compiled, they were assembled. Assemblers, relative to compilers, do hardly anything.

> and hardware design to perform the calculations on the data.
False. A SNES program could have 4 MB of data and not use any of it. (Of course there'd be no point, but w/e.)

> All pixels calculated
Either a) you grossly misunderstand how all 8/16-bit era machines do their graphics (in this case, by sending palettes, tiles and maps to the PPU. No bitmaps here) or b) you count the PPU in the SNES as part of a program even though there is no programming involved in it and it is a piece of very complex fixed-function hardware.

> The calculation is generally identical and result, and the console use different parameters/syntaxes from their compiler/hardware design. Like 1+1=2 is identical, and the method from layout/syntax is altered.
1+1 could be done in a number of ways, including:
LDA #$01; CLC; ADC #$01

LDA #$01; INA

STZ $00; INC $00; INC $00

(LDA #$01; SEC; ADC #$00)?

And my favourite, assemble-time: LDA #(1+1)

> As the calculation is common, this is a go-between to make the ROM instructions relate to what the calculations should be so that the PC can then do the math on its design?
As you can see above, it's really hard to figure out what in the hell the original programmer was trying to do, especially when dealing with complex arithmetic on 8-bit platforms, especially without the creativity of a human. I would shy away from heuristics code in fear.

In addition (hah), an aftereffect of this is that all timing is screwed. One example of this actually happening in the past was how ZSNES emulated the multiplication and division registers. It made them calculate instantly, so then hacks relied on this behaviour and broke on the real SNES. This, however, would be much more drastic as the timing for every CPU instruction is dead.

Mon 26 May 2014, 23:09:37

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

Posts: 81
Post Re: emulator efficiency
Thanks.

A console in general has a motherboard, some RAM, cpu, sound chip, registers.
In general, a few basic commands in assembly are used and all code executed is a combination of these basic commands in a sequence.

Where a program has the general hardware labelled and registers etc, and pre-programmed math to determine the few assembly commands, isn't the rest a matter of feeding the program the ROM to perform all those assembly steps which are already pre-calculated with computer calculated buffers for the expectation of RAM and anything else to do virtually?

I am thinking of the most basic math to accomplish, where calculation time is proportional, getting the appropriate calculation performed on any ROM to get the right data modeled after the motherboard and its layout, with emphasis being on the program being a clone of the motherboard/console rather than have any association to a ROM - i.e. it can accept any ROM since the program itself will behave like the motherboard/console and its math/calculation in relation to the data fed by the ROM.

The emulator should in general be a software version of a motherboard/console 1:1 and its math?
i.e. have all steps pre-programmed that the console will perform by its constraint and the math to suit, and any ROM data fed will appropriately calculate irrespective of the game as though inserting it into a snes.


SoraK05


Mon 26 May 2014, 23:32:42

Joined: Sat 18 Apr 2009, 16:06:52

Posts: 2208
Post Re: emulator efficiency
Kawa wrote:
Exophase wrote:
If you can't write an emulator then you almost definitely don't know what you're talking about.
I wrote an emulator once. It emulated the Asspull Mk. II, a hypothetical little RISC that I'd come up with in my dad's CS class when he let me teach the rest of the class about masheen code. It had software interrupts to print and read lines of text, but only displayed a single one at a time :)


That's pretty cool.

I had to do something like that for my computer organization class sophomore year of undergrad. Previous years the class textbook taught for this simple virtual CPU called "LC2." This year we were doing x86 instead (and the teacher was actually a fellow undergrad student, that's how understaffed the department had gotten.. he was actually a good fit though). For the final project there was a choice between doing an expression interpreter and an emulator for LC2. I picked the latter, which was the first "emulator" I wrote.. Of course it had to be in x86 assembly, and I chose to implement it with a dynamic recompiler >_> That was good practice, I guess. Although I didn't really do everything in the greatest way.

Mon 26 May 2014, 23:42:27

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

Posts: 81
Post Re: emulator efficiency
Anyway, as much as I am learning I wouldn't want to disturb.

I came thinking that a ROM can be 'decoded' in a way with appropriate calculations that resemble the motherboard, its steps and its own math to result in appropriate data and all 'output data' is sent appropriately to the monitor/speaker.
As it is a collection of numbers as a file, and the console will perform math on it to result in the output data, it would be fair that some algorithm can directly do number calculations/math on any ROM with success and with tweaks to be more direct in the math steps.

Like a hybrid of the math the console is designed to do with its constraints on reception of ROM information and tweaks where appropriate to skip/go directly as well as prep output data for the receiving platform.

Thanks.

Mon 26 May 2014, 23:55:57
Board Admin
User avatar

Joined: Sat 11 Apr 2009, 04:21:58

Posts: 4783
Location: Australia
Post Re: emulator efficiency
I guess I'll toss my hat into the ring.

SoraK05 wrote:
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.

At a very high level, yes, you could develop a system of equations that describe how a Gameboy or SNES transforms the bytes of the input ROM into audiovisual output, and then that would be perfect emulation.

However, there's some significant limits:

- We don't know exactly (that is, with sufficient precision for such a system of equations) how the original Gameboy or SNES works. byuu has spent years of research trying to figure that out (at least for the SNES).
- Even Nintendo's internal documentation wouldn't have enough precision. A lot of the components of these things were designed individually by very smart people, and when they're put together into a single console they can interact in unexpected ways. To understand all the possible interactions, you'd need one person as smart as the entire team that built the SNES, put together, and nobody's that smart (the smartest person in the world is probably as smart as two or three regular people, but there were probably dozens of people working on the SNES).
- Even if we had a perfect set of equations to describe a SNES, that might not be useful. For example, it takes an apple less than a second to fall off a tree, but it might take an algebra student a minute to work out the calculations required to describe it. And if the apple spins as it falls, or you want to take air friction into account, that will be much harder. Likewise, computing the equations that describe a SNES would be very tedious and difficult indeed.

In order to make emulators useful, we ignore the details we don't know or understand, and even the details we do understand are simplified until they can be computed on desktop PCs.

Quote:
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.

The advantage Nintendo has here is that every VC emu is tweaked to support just the features that particular game needs, and everything else is done as cheaply as possible, even if it's completely different to what the original console did. Nintendo can even patch the game if it tries to do something that's difficult to emulate.

In contrast, an emulator like higan tries to do exactly what the original SNES did, as best we can understand it, which means that higan is more complex than a VC emu, but it also means that it can run any game the original SNES could run, without having to patch the emulator or the game.

_________________
Maintainer of the unofficial git repository for bsnes.

The ending of the words is ALMSIVI.

Tue 27 May 2014, 00:36:43

Joined: Tue 31 May 2011, 22:39:35

Posts: 348
Post Re: emulator efficiency
And now I sit down with a glass of fine wine in front of a fire to read this thread.

It's like looking into infinity. I cannot look away. Nor do I want to. I love you thread. Never leave me.

Thanks for that statically recompiling NES emulator link. Good read

Tue 27 May 2014, 01:24:24
User avatar

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

Posts: 5266
Location: 日本
Post Re: emulator efficiency
This thread is so awesome:

SoraK05: A motherboard is a calculator and a ROM is a set of equations, right?
Everyone: No.
SoraK05: A ROM is a set of equations and a motherboard is a calculator, no?
Everyone: No.
SoraK05: Wait, I thought that a motherboard calculated numbers and the ROM provides them?
Everyone: No.
SoraK05: Hang on. Let me get this straight; a motherboard crunches numbers provided by the ROM?
Everyone: No.
SoraK05: I'm still confused. A motherboard doesn't process ROMs as pure mathematical equations?
Everyone: No.
SoraK05: But the Virtual Console does this.
Everyone: No.
SoraK05: But, but....UNICODE!!!
Everyone: No.
SoraK05: What's a static recompiler? What's HLE? What's LLE?
Everyone: *facepalm*
SoraK05: SEGA makes emulators!!
Everyone: Your point being?
SoraK05: CALCULATORS!!!!!
Everyone: God damnit.

_________________
CaptainJistuce: He's totally in the wrong, Kakashi's 100% in the right.
Note: The above statement is subject to act of byuu.

Tue 27 May 2014, 02:35:21

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

Posts: 4543
Post Re: emulator efficiency
SoraK05 wrote:
For SNES, I know there is a specific change for the Super Mario RPG one, but otherwise the files are generally identical. As long as one can pack a ROM appropriately whether injecting or manually rebuilding an app file with the ROM, it is generally the same emulator dol executable.

They don't refer to the game's source code. It is all done in their emulator, besides some minor game tweaks like Sin and Punishment.

I actually know for a fact you are wrong here, as I was helping someone in IRC trying to rip ROM images from the Wii, and it turned out all the sound data was ripped out and replaced with new data so they could use the Wii's sound engine and shave some clock cycles off the emulation.

So no, it's NOT all done by the emulator.


Quote:
The point is with documentation the system requirement drops drastically, from having constraint data of their mobo/os/sdk etc for the calculation/math on the ROM.

The games look, sound and run closest to the original console than any emulator in general I have used, and much faster in performance (like N64 on GC for example).

Aside from the places where they DON'T run like on the original console, or where Nintendo edited them to remove flicker effects, or hacked them to boost the resolution, or... yeeeeeeeah.






Anyways, let me ask you something really quick: You keep comparing computers to calculators, so... how do you take the natural log of a number on a calculator that only has +-*/= buttons? On a scientific calculator it's something like "2nd-ln(x)", but on a 4-function calculator it's... a little more complicated than that, and is going to take a lot longer.

Emulators exist because they have to simulate all the hardware features("buttons") that the original hardware DID have but the target hardware DOESN'T have.
Just as an example(I'm not saying this is the ONLY place things are problematic)... the SNES has 4 background layers, one of which can be scaled and rotated by the graphics hardware, 128 sprites, of which 32 can be displayed on a single scanline at a time, and a whole lot of color subtraction "buttons" for transparency.
The PC's video card has... one bitplane. There is no scaling, no multiple layers, no color subtraction, NO SPRITES. EVERYTHING has to be done by the CPU, and it has to be done in the way the SNES graphics hardware would have done it.

And doing it the way the SNES would have done it is a huge problem too.
You remember when games written for an IBM PC didn't run right on a PC/AT? Or how all those games coded for 386es using Borland Pascal crashed on faster 486es? Or how a Windows 95 game just crashes violently on XP?
This is with hardware and software DESIGNED to be backwards-compatible. Now imagine how much worse it must be with wildly unrelated hardware.



An emulator is basically a program that knows the button sequence you need to do a natural log on a 4-function calculator. Unfortunately, it's a LOT of buttons.

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

Tue 27 May 2014, 02:41:52

Joined: Fri 03 May 2013, 06:51:50

Posts: 410
Location: NJ
Post Re: emulator efficiency
wareya wrote:
isn't that basically what n64 emulators do
the ones with dynarecs at least
note: you CAN NOT "HLE" the CPU without rewriting the game completely. recompilation is the closest you'll get.


Meanwhile in #higan:
#higan wrote:
cr1901_modern wareya: note: you CAN NOT "HLE" the CPU without rewriting the game completely. recompilation is the closest you'll get... what do you mean by that
TheIdlemaster s him realize that an emulator IS a program that "converts the maths" or whatever.
09:50 cr1901_modern Why would you HLE the CPU? And I'm not sure what recompilation has to do with that
Kakashi_Note yeah, that kinda confused me
cr1901_modern doesn't think he'll get a response, but...
Kakashi_Note wareya doesn't really look at this channel
TheIdlemaster Ummm, "maths" being used in the american sense of "making fun of people for being stupid and pluralizing math" and not the UK sense of "making fun of people for being stupid and singularizing maths."
Kakashi_Note maybe if we trigger him enough times
Kakashi_Note wareya
snesbot It's been said that wareya is serious about coding in Game Maker Language.
Kakashi_Note wareya
snesbot It's been said that wareya is serious about coding in Game Maker Language.
cr1901_modern wareya
TheIdlemaster Wareya wareya wareya!
snesbot It's been said that wareya is a japscat anime fag.
09:51 Kakashi_Note !append += not in this channel for any real reason apart from keeping up appearances.
snesbot I didn't quite get that, Kakashi_Note.
cr1901_modern Eh, I'll just tack it on as my contribution to the thread
Kakashi_Note ah shti
Kakashi_Note !append wareya += not in this channel for any real reason apart from keeping up appearances.
snesbot Added a factoid to 'wareya'.
Kakashi_Note !append wareya += not paying attention to this channel.
snesbot Added a factoid to 'wareya'.
Kakashi_Note wareya
snesbot It's been said that wareya is serious about coding in Game Maker Language.
Kakashi_Note yes, yes, snesbot.
TheIdlemaster !append wareya += not summoned in the same manner as Beetlejuice.
snesbot Added a factoid to 'wareya'.
Kakashi_Note wareya! Wareya! WAREYA!
Kakashi_Note nope. damn.


Erm... with that said, wareya, would you care to elaborate what you meant by HLE-ing the CPU while you ignore #higan :P?

_________________
"It wouldn't be a byuu.org forum thread if the thread topic didn't derail at least once."- Some byuu.org forum member
"Clearly the answer to [cross platform portability] is to write a DOS application and then everybody can run DOSBox. Except for [cr1901], who can run it natively."- Screwtape

Tue 27 May 2014, 02:54:14

Joined: Wed 30 Jun 2010, 22:54:37

Posts: 86
Location: Canada
Post Re: emulator efficiency
CaptainJistuce wrote:
Or how a Windows 95 game just crashes violently on XP?

I swear to god, I have only ever run into the reverse scenario.
Installs Windows 98 on a machine to use the built-in MIDI synthesizer. Installs Diablo because he has it sitting around. Doesn't work.
Pops the disc in Core 2 Duo desktop running XP. Plays flawlessly.
Of course, I know Diablo is a terrible game to use as an example, and that it would be better to use a game that hadn't been run through compatibility programs at Microsoft, but it kind of reminded me how terrible it was to use Win9x back in the day. (I used to have to reinstall Windows ME about twice a day. Oh look, that program has stopped working. Reinstall. (Probably had viruses. I was like 5, so I wouldn't be surprised.))

Tue 27 May 2014, 03:33:29

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

Posts: 4543
Post Re: emulator efficiency
cooprocks123e wrote:
CaptainJistuce wrote:
Or how a Windows 95 game just crashes violently on XP?

I swear to god, I have only ever run into the reverse scenario.

Try playing the PC Battlezone game.
My understanding of the problem is that it breaks on any DirectX greater than 5 if you don't go in and delete all the movie files(not as tragic as it sounds, they were used to show rotating planets in the stage briefings mostly), because DirectX wasn't back-compatible stable yet.


cooprocks123e wrote:
Of course, I know Diablo is a terrible game

Quoted for truth.

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

Tue 27 May 2014, 03:56:05
User avatar

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

Posts: 2679
Post Re: emulator efficiency
Kawa wrote:
CaptainJistuce wrote:
kode54 wrote:
Fury spotted.
smirkingfury.jpg
Fury of the Furries anyone?

Which got renamed to The Brainies. For reasons.

_________________
blag

Tue 27 May 2014, 09:36:39

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

Posts: 4543
Post Re: emulator efficiency
SoraK05 wrote:
Thanks.

A console in general has a motherboard, some RAM, cpu, sound chip, registers.

You forgot the graphics chip and the input chip.
Also, registers aren't on the motherboard. They are part of other chips.
The CPU, graphics chip, and sound chip all have registers that they work from, as in most architectures calculations are not done directly to and from RAM and ROM, but out of registers on the processors.You copy data to the registers, the math is done, the results are put in registers.
THEN you can copy that back out to RAM for safekeeping.
Or send it to another chip's input registers.
Or crash violently.

Quote:
In general, a few basic commands in assembly are used and all code executed is a combination of these basic commands in a sequence.

Congratulations, you just defined "program"
Well, for programs without conditional branching.

Also for unusual definitions of "basic commands."
Teh googlez says there's about 90 different opcodes for the 65816. While NOP is fairly straightforward, some of the other commands can be fairly complex.
Sound and video hardware have their own different sets of instructions. Hell, the SNES sound unit has it's own dedicated processor that runs independently of the 65816.



Quote:
I am thinking of the most basic math to accomplish, where calculation time is proportional, getting the appropriate calculation performed on any ROM to get the right data modeled after the motherboard and its layout, with emphasis being on the program being a clone of the motherboard/console rather than have any association to a ROM - i.e. it can accept any ROM since the program itself will behave like the motherboard/console and its math/calculation in relation to the data fed by the ROM.

That math to convert original target platform behavior to modern computer behavior is exactly what an emulator DOES.
The more accurate you want to be, the more complex that math needs to be. While there are occasional exceptions, that is generally a good rule.

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

Tue 27 May 2014, 12:16:18
Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 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