byuu's message board

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)

Even my posting this from a text-only browser running on a VPS that I SSH'd into makes more sense than SoraK05.

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.

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.

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.

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.

I guess I'll toss my hat into the ring.


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.


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.

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

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.

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.



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.

Meanwhile in #higan:


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

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.))

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.



Quoted for truth.

Which got renamed to The Brainies. For reasons.

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.


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.




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.