byuu's message board

It's HLE because you're not doing exactly what the game is doing on real hardware. You're doing an abstract version of it, reimplemented. You're not using math to figure out exactly what the game is doing; you're identifying a pattern (wait for vsync? okay!) and doing something slightly different than the original hardware. In fact, pretty much every single emulator in the world does this for actual video output. The only thing that makes that any different from, say, reimplementing an SDK function, is that putting pixels on the screen instead of sending them off to a CRT happens at a level that can't possibly affect the inner workings of the game code.

As long as a suitable formula (based on hardware formulas + machine code transactions) to get the right numbers can be performed which is ultimately calculated and sent as its bit string on a ROM file, it should work on any ROM and job done?
Architecture representation isn't entirely necessary for this part, and minor adjustments for proportion like resolution,bit rate,fps,sync can generally be considered.

ahahahahahahahhahaha no they can't.

Wow. Six pages of bullshit. I wonder what'd happen if I fed all of Sora's posts so far into a markov generator...

How has this thread reached six pages?

One standard formula to perform where console design is considered on a ROM for its instruction/machine code/math areas should result in the same strings which are output, and act as a software formula/calculator equivalent of the console+machine code transaction?
This should have perfect compatibility, as well as be able to have shortcuts which are unintrusive?

And also thanks for the responses for education.
Where a formula to convert the machine code parts to recognizable math is required, a full compatibility emulator should be ready?

It is interesting this has generally not been done, as I imagine each console can have its own individual optimized/final equivalent.

Nuclear Option
The following has been generated from collected ramblings, posted without further edits.



I mentioned the concept of a 'translator' to relay appropriate video/sound/ram/controller functions directly to the structure of the emulator - to calculate the ROM for the console constraints can end up in the steps of the ram buffer of the ROM numbers for sound/video each second of 4.19 MHz.

This looks like something to calculate/decode on a ROM are 'instruction/machine code' to perform the machine code being a set of numbers.


I'd say VC is the only part necessary for this and some basic input instructions to tweak some parts of this calculator. An SDK/mobo description can assist.

That is generally the jist.

Considering N64 is done when the data by a specific algorithm to perform arithmetic and the remainder is a set of mathematic formulas performed on the monitor, or speaker, and in general I have used, and much faster in performance (like N64 on GC for example).

To demonstrate an 'emulator' should in essence be some kind of a ROM in appropriate steps which suit, the same thing. Each has its own code.

The 'emulator' part is just to calculate the input and its layout, with an input to perform the machine code a set of mathematic operations, the ROM layout for console?


In essence, it is packed to get the identical output numbers when performed on a ROM in general designed to suit more appropriate mathematical formulas to end up doing math on the monitor, or speaker, and in general to determine what the 'emulator' is, to result in the pc would have its own way to be read.

The emulator plugin just needs to decode the ROM data to feed those input/outputs that is optimized?

A snes 'plugin' in a predesigned calculator of numbers.
The numbers can be simplified to be 'this cycle accurate in general designed to be exact to the platform (pc), and the computer being the environment to do equations on the ROM and is generally considered low spec.

It is generally an array of pixel data, same for sound in a step by step mathematical calculator, you can calculate the buffer would be in multiplatform games and 'packed' differently to suit for displaying pixels for video, outputting sound appropriately to sound device, recognizing controller input, managing general memory.

I.e. like a converter between mac / windows in the same pixels, and other game specific memory is the same thing. Each has its architecture and capacity of computation to provide all numbers/bit strings used for video and sound data etc - the only part necessary for an emu would perhaps do something similar to this ROM decoder/calculator with input.

EDIT:
If one has a few options of buttons and combinations to affect motherboard expectations could calculate the buffer are just sent directly to the ROM and job done?
Architecture representation isn't entirely necessary for this part, and minor adjustments for proportion like resolution,bit rate,fps,sync can generally be identical for each game, and all buffer preparation is sent to video/sound/temp as appropriate math.

The more direct where a tweak is done when the data by a specific algorithm to perform on the monitor, or speaker, and in temporary data - result of processing/calculation is the ram buffer is all that is optimized already will do this right according to ROM, to result in the ROM of the video array of pixel data, sound data, other data, and the output strings which is the same emulator dol (00000001.app) files, and all data present in the ram buffer of the common video/sound/temp for the PC/etc based on its data to feed to the console which is officially dedicated on being accurate as a software formula/calculator equivalent of the input commands to relay data along.
RAM has the video pixel buffer per cycle, sound buffer, temporary memory buffer and the snes/megadrive plugin of calculating ROM and synchronize these data buffers, and having some input to do arithmetic, eventually to move the data is strings which are unintrusive?

You guys, math and logic are the same thing. You can use math to solve the answer to an if-then statement, even before you're given the if. We can use this to determine whether a player will beat the next level in Mario. If you already know what the player's input will be, you can save a bunch of CPU time and replace your emulator with an AVI file.

The requirement is to have a means to read a ROM calculator to read a ROM, whether MD/SNES ROM of same game in an alternate layout to feed monitor/speaker.

Each system will have video pixels, sound data, and have those strings just used, with input calculated to move the data for score/health etc.

The emulator just requires calculating the ROM for its registers,general operations etc to essentially perform calculator steps on the ROM and synchronize these data buffers, and having some input function to progress the data (ROM) is fed.

The strings used for output, all with mathematical steps.

It would be possible to entirely transform/remap a ROM in appropriate steps which suit, the same strings which are unintrusive?

And also thanks for the platform, and sound and temp done each second of data is read, one can relate the calculator begins and data will move along and to a degree Majora's Mask, with the same game in an alternate layout 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 appropriate data to decode the ROM data and sound data to decode the ROM layout to feed the appropriate constraints, you will get the ram is all that is needed.

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

If you get the data along?

Specific coding of the cpu speed for this? And this can be compiled according to data requirement?


That in essence simply be relating the output for MD ROM and its combination of button options, a 'decoder' with the inclusion of the video array data and its layout to get the data, as well as take shortcuts, or end up being very calculation intensive to resemble the maths of the original console than any emulator in general I have used, and much faster in performance (like N64 on GC for example).

To demonstrate an 'emulator' should in essence should be able to get the identical output numbers for its speed/accuracy.
While other emulators without and variations on calculating the game is there as video plugin for outputting pixels. The only requirement is to have shortcuts which are unintrusive?

And also thanks for the arithmetic / steps according to ROM, to result in numbers to be 'this cycle accurate in general designed to suit another console spec, and thus do a low end game at full speed right.

The virtual console on Wii appears to do this, it appears something like OOT flawlessly.

Any my posts are unnecessary?
Thanks for the education and further study toward a general expectation for a functional and effective emulator.

I still think the requirement should not be too high and can be a matter of appropriate math based on hardware instruction to get the right numbers and have 100% compatibility.

yeah guys running complex state machines isn't procedurally expensive at all

The more the resolution etc, the more calculations for converting that machine code to readable instructions.

Where this can be appropriate for the older less required systems, newer ones can possibly have the machine code parts adjusted/injected with more suitable and direct instructions to skip the intensive machine code conversion process?

I don't think you understand how intensive a "megahertz" is.

That is generally the jist.


That too is from my markov results.

Congratulations, you have just described HLE. The key is that HLE almost can't be accurate; the very shortcuts that make it faster break accuracy; skipping these shortcuts in favor of accuracy would tend to eliminate its benefits, creating slow emulation again.