byuu's message board

A ROM has number data, and the console is like the calculator.
When powered on, the calculator begins and data will move along and perform arithmetic, and let data go through appropriately decided paths.
After enough cycles/steps a build up of numbers after math is accumulated for what video will be, sound will be, temp will be (according to an fps for example) and output.

The console is a step-by-step calculator which takes the ROM numbers for its input to perform the game steps.


Where one can resemble the maths of the console's steps, one can ultimately get the number stream of data which is sent to video/sound/temp as appropriate math.


The more direct math to the expected result of the stream for video/sound/temp, the quicker you can have output data.

noiii, don't worry yourself. No one knows what is going on.

SoraK05: it sounds like you're trying to treat game programming like a mathematical formula. Stop. It's not like that. While math does play a small role, the rest of it is just conditions and the moving of things in memory. There are few mathematical operations a CPU can do, while all the rest are about moving data, comparing it, and going to different instructions depending on the comparisons.
Another thing: the "numbers" that make up the video/audio output. They make no sense. For every single game console, they are different. Why, you may ask. Because every game console has completely different hardware, and the games are written for that hardware, so it makes no sense if it's not put through that hardware.

EDIT: It sounds like you are trying to say that if a console can be represented through math, then why can't we just simplify the formula to make it easier to calculate? Even if a console could be represented through math, the resulting maths would be so complicated that it would be near impossible to simplify them to a state when they could be run more easily.

FAKE DOUBLE EDIT: I was going to write a whole thing, but I have a history essay written in my second language due tomorrow that I haven't even started researching, much less writing. Oh and it makes up like 10% of my mark.

Further adding to how wonderful this topic is,



Furry spotted.

Sora: You are describing the concept of emulation IN GENERAL. Yes, a ROM is just a set of numbers that represent arbitrary data and instructions. The problem is that those datas and instructions are ARBITRARY.

It's not feasible to statically convert a game from one console to another for ENDLESS reasons. The first and most obvious is data location. The second is self-modifying code. The third is differing console hardware, timing, the dependencies on awkward hardware... The only thing you can really convert a game to is a much higher tier hardware machine, like a PC.

You're basically badly outlining the theoretical basis behind emulating console games on a PC in the first place. Give up, it's never ever going to happen between consoles of similar power; not without rewriting swaths the game manually in the first place, in which case it's a fucking port!

Seconded.

Nintendo can release Virtual Console games which perform better than homebrew emulators on the Wii because they bundle a different version of their emulator with every single game. This tends to skip emulating features of the console which that particular game did not use, and possibly also replaces functions in the original game with versions that run directly on the Wii hardware. (In the case of N64 games on the Wii, this involves basically replacing all 3d graphics drawing code.)

Also note that Nintendo has access to the source code for all games written in a higher level language, so they can sometimes just recompile the game logic for a different platform instead of having to emulate it.

It takes Nintendo a significant amount of time to hand-tune and patch the emulator for each game, which is why their entire library of games is not released on the Virtual Console yet. They don't always bother to get the original game working completely correctly, either. (See Mayhem in Monsterland for an example.) It's sometimes possible to replace the ROM file contained inside a Virtual Console game with another game, but compatibility is generally poor.


If you are talking about static recompilation, here's a paper on why that is not particularly useful for emulating 8-bit systems:

http://andrewkelley.me/post/jamulator.html

tldr: most of the CPU time ends up being used for synchronization, and to emulate the video chip of the NES (which has no analogue in standard PC hardware.)

For porting games from one console to another, usually the issue is fundamental differences in the graphics hardware or CPU architecture. It's not possible to automatically generate 6502 machine code from Z80 machine code and have the performance be identical to code hand-tuned for the 6502, for instance, because the two processors were built with different assumptions about number of registers, endianness, status register flags, interrupts etc. and it's difficult to tell which of these side effects are important without understanding the original intent behind the code in the first place.

For consoles with very similar hardware or an emulation mode, it is sometimes possible to directly reuse source code; see Super Mario All-Stars or this PC Engine port of Mega Man for examples of that. Yet again, this cannot just be done automatically by a compiler.

He probably isn't going to read any of this, but maybe this will help someone someday, so here.

Okay, ALMOST serious question here....

So, if you know the current state of the system, the end result of any given change is deterministic. You know what it will change to, and how fast.


How many exabytes of storage would you need to make a table containing EVERY POSSIBLE SYSTEM STATE, so that any given action could be calculated not via "real" emulation, but through stepping through a table?

Even assuming unlimited space, would a table even be faster? I'd think at that size you start running into issues with seek times.

Most likely. Unless you had comically large amounts of RAM.

Cheetahs are spotted, yes.

Fury of the Furries anyone?

For virtual console, N64 is particularly poor with replacing ROMs as the emu supports unicode/data for the specific ROMs they decided.

Otherwise, SNES, MD, NES and others are generally quite easily portable.
The are not many variations of emulator dol (00000001.app) files, and all share the same common emulator resources (00000002-4.app iirc).
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.


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

Why do you keep referring to the Virtual Console? AFAIK, they work exactly like any other emulator internally.

You also don't know shit about Unicode.