byuu's message board

My point is along the lines of a different approach where sdk / mobo data is present.
A Nintendo GameCube can do OOT and to a degree Majora's Mask, with the former being completely playable. A homebrew emulator can't do a low end game at full speed right.

The virtual console on Wii appears to do things like N64 right, as well as older consoles with results reminiscent to the original consoles over general emulators around (besides some minor glitches common to some bugs in emulators with injecting ROMs).
A homebrew emulator can't do N64 at full speed right either.


Where SDK/mobo data is present, not only for virtual console do emulators appear more 1:1 to the console than other emulators, it appears something like N64 can be done on a GameCube spec for something like OOT flawlessly.


I can imagine that where all SDK/mobo data etc is present, an executable programmed like a calculator/decoder with mapped data to decode a ROM for getting all video strings/audio strings/temp data strings etc with basic steps for decoding the ROM for this and some basic input instructions to tweak the calculator's position in the ROM can be done to get that and feed the platform's video array/sound etc with it and consider timing..
Some calculations on a ROM in general should be able to get the data, and with an input to tweak some parts of this calculator. An SDK/mobo description can assist.

That is generally the jist.

Considering N64 is done very fine in GameCube let alone Wii (besides Majora's Mask which can slow down), I believe the requirement for an emu should not be too high and (more) accurate where SDK/mobo data is there and an emu would perhaps do something similar to this ROM decoder/calculator with input.


EDIT:
If one looks at a compressed file, a decoder can be used to do calculations on its data to produce a result.
All data for the game is in a ROM, whether MD/SNES ROM of same game for example.
The instructions/calculations to interpret the data is from difference in console design/coding.

All the data for the game is there - all the video array data and sound etc in the ram buffer is all present in the ROM itself and can be determined by calculations of the emulator like a decoder.
As all the video etc data for buffers (i.e pixel array) would be identical for each game, and all data present in their ROM, the calculation to determine how to get that data is from console specific programming.
A tool to act like something to calculate/decode on a ROM to get that data is what I mention.

So what you're proposing is a static recompiler?

I don't know what a static recompiler is.

I'm thinking of a tool with some constraints programmed to resemble calculations that will be processed on a ROM, and all expected calculations like for video/sound/temp which will go (and be prepped) to the ram is all that is needed.

That data goes straight to monitor/speaker without further programming required.

Oh my god, I'm considered a noob in these parts and even I know you're an idiot.

Looks like we're on the start of another great thread.

If you have all mobo data and sdk etc data, what is capable?

The ROM has all information of the game, and the process performed with its data ends up being calculated with math and resulting in video pixels/sound data/temp data which for the most part is common for a game on multi platform (like MD/SNES/<PC etc>).

The process of getting to that common data is different with architecture and perhaps an extra step or two based on system.

With all mobo/sdk etc info, one can construct a tool to act as a calculator or sorts with constraints and do some math on the ROM file to in essence emulate/decode according to those constraints the expected data result from the ROM of the common video/sound/temp etc.


The game data result of processing/calculation is the common video/sound/temp for the most part. The process to get there can be done with a console specific 'decoder/calculator' with its constraints for its registers,general operations etc to essentially perform calculator steps on the ROM and its data to result in the exact numbers of the resultant 'decoded' video/sound/temp etc which can go directly to the PC's monitor/speaker etc.

An input to the constraints has a few options of buttons and combinations to affect the math on the data by a specific algorithm to affect the data, as well as time.

Ultimately with the inclusion of the input and its combination of button options, a 'decoder' with the console constraints can end up doing math on the ROM to get the ram buffer data of the video/sound/temp etc and can be used directly.

If one had the data in the ram buffer of the video/sound/temp it can be put directly into the computer. The process of getting that data can be done with a specifically constructed 'calculator/decoder' using the constraints of the hardware as its math.


Where you can do math on the ROM with the appropriate constraints, you will get the exact data to feed monitor/speaker.

Each system will have its own constraints to consider in the math algorithm to perform on the ROM from registers, operations and all, and in general the resultant data would be identical for multi system.

I see a lot of words, but I'm getting absolutely nothing meaningful out of these posts.

You can do mathematical operations (+, -, /, * etc) on the ROM data using constraints for calculation according to console hardware.
With the console hardware in mind, you can set up an automated list of calculator steps to perform on the ROM data to get the numbers of what is fed to the video/sound/temp memory.

I think he's basically saying that we take all the API/BIOS calls the game makes, and run it in native code, using the ROM only as a list of these calls and as a source for the data, which would work assuming the game used only API calls. (Would that even be useful? Would it even be possible for any consoles newer than the Xbox maybe? no to both )

EDIT: Upon a second glance through the thread, especially the first post, it sounds like he does not know how games work, and thinks that they are entirely content and only enough programming to get all that content on the screen/out the speakers.

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.

nah, I'm pretty sure dynarecs take the assembly in the game and recompile it all to x86. the api calls are dynarec'd as well, which is different than just writing it in native code (as he suggested), but a lot more efficient than interpreting it, as the performance hit is one time when you recompile it, instead of every time you run it, like a standard interpreter

with the closest emulation technique to what he was saying (possibly? it's still oh so unclear), you interpret the code, but every time you reach a function call, you jump to native code instead of interpreting what was in ROM. this would mean that you would basically have to reimplement a large part of every single game in native code. he's saying we basically interpret half the cpu work, and code the other half of the game in native code. this would actually work, if there was a console that used apis for everything and had very few api versions (so basically nothing).

The ROM is a set of numbers.
The numbers can be used for commands for the console to perform arithmetic and result in numbers to be used for output.

I.e. there is numbers for doing arithmetic, and output numbers for video/sound/temp.

The ROM has all the number data to work in accordance to the console which is the automated calculator.

If you get the steps of the console according to its design in a step by step mathematical calculator, you can calculate the input of which data to take and perform arithmetic, and ultimately result in the calculated numbers of the output/temp data.


In essence, where the arithmetic / steps are done in accordance to the console in this way, all arithmetic can be done in calculations to result in the numbers used for output, all with mathematical steps.

It would be possible to entirely transform/remap a ROM by math to be calculated using different parameters to suit another console spec, and thus do a direct conversion.

What the computer/tool will care about at the end of all arithmetic calculations is simply a number to feed to the video/sound output, and the temp number of memory. Input can affect the math and result in different numbers as well as time / steps according to ROM, to result in the whole game being done as arithmetic and the number for output / temp data.

The ROM gives numbers to the console (automated calculator), and what it does is performs maths with registers on the ROM numbers. Eventually, after the math determines/traverses along and to different components, the math accumulates a build up of numbers which will be used for video/sound/temp, and where input can also affect.

These mathematical steps will produce the exact numbers of output when written as the exact calculator the console is.

Reading this thread makes me feel mentally inferior somehow. I don't understand what is going on in this thread.