byuu's message board

Emulator accuracy vs performance is not a zero-sum game. Please don't imply this, it makes people think that the people who spend a ton of time trying to make emulators faster are just finding ways to make it less accurate.

Indeed, that is not true. However, I do think there is usually going to be a trade-off between any of performance, code complexity and accuracy. higan is likely in the middle thanks to clever C++11 code and a very fast coroutines library. (The ARM instruction decoder is so goddamn cool.)

It should always be noted that higan's source code is also intended to serve as documentation, so if it tried to take any shortcuts, even if they were not visible at all to software, it'd still be a problem.

If I may say something similar to Kega Fusion where for the most part it is accurate and runs at decent speeds (even on the person's lower spec PC mentioned).
There can be some equivalent for SNES that is accurate and will generally load any ROM (like Kega Fusion) which can run at a speed to work on that person's PC as well.


A computer is limited in general to performing one step at a time. All programmed steps are done so with one step at a time, and all concurrency is a matter of having a means to give multiple functions a step each or more specific where defined (something to that effect).
A cycle accurate emulator should be able to replicate the exact steps, step-for-step the hardware does.

While this is effective, this isn't necessary for performance.
Majority of the steps involve doing calculation/math on numbers (mostly for what gfx will display) and then some steps for either receiving more data for calculation or some steps to send the calculated numbers out (like to monitor/speaker).
Where all the steps involved (mainly the calculations of numbers) are appropriately matched in an algorithm, shortcuts can be taken to result in the exact same numbers which end up being sent out / used for temp without breaking proportion on the core math being applied on the received numbers to always result in the identical output numbers.

Where a list of reduced steps is made to result in the same thing being done and the identical numbers calculated, and the steps being performed in the least and most suitable opcodes to match the hardware, besides considering the timing for input and then to consistently output the numbers calculated for display/sound all should still be 'accurate' and do the overall process in less (ideal least) steps.


I mention treating the ROM as numbers and the program as an algorithm to perform operations on the ROM numbers as all output/sound/temp numbers are contained in the ROM and are resulted in a step-by-step list of math/logic and constraints to suit buffers as used on the hardware (like SNES).
Once a pool of numbers for display/sound/temp are collected they are appropriately used. Just require a consistent feed of these numbers, which is obtained in structured math/logic (algorithm) on a set of numbers (ROM).

Steps can be made to generally share the same ram buffer than alternate ones in less steps, use a different equation with same results in less steps, use the same cpu and its opcodes to perform math/logic (instead of steps of sending data to others for it and its memory), among other things (shortcuts/tweaks).
In general it would be for shortest functions of each opcode and perhaps sets of them where detected in advance.
Another reason mentioned to treat it like numbers is where the steps are matched (and reduced) for the same results, clock/timing isn't necessarily relevant - the steps will all be performed for the matching numbers. Manual timing for input and sending numbers out is done outside of this.
What is appropriate is ultimately keeping proportion of the core math done on the ROM numbers while reducing steps which result in the identical output numbers/temp numbers, and less steps for the specific hardware based on the opcodes available.


In general, there could be one list of steps for 'cycle accurate' and another for reduced and tweaked steps for 'efficient', and the steps can be ported appropriately to suitable opcodes. Where the 'cycle accurate' steps are done, the 'efficient' ones can be deduced with accuracy in matching results in mind.

While this wouldn't be cycle accurate to perhaps pinpoint what is done at a specific cycle number and hardware (memory) states, it is accurate and efficient for emulation use (and suitable to hardware architecture opcodes/memory).

I think The Doug has daddy issues.

Why does emulator efficiency even matter? In a few years I doubt you'll have trouble running Higan on tablets.

One main reason - computers are limited by design/heating.
There is only so much tech can allow for instructions etc in a second.

Reduction of steps to allow for other things to run as well as have more things running means optimizing steps and suiting them to hardware.
Something like 4K resolution where majority of calculations done in a modern game for example is numbers for gfx will require a lot of optimizations and shortcuts, and suiting opcodes in order to have any reasonable potential to run at a consistent 'full speed' of 60+fps, and this wouldn't necessarily change in a few years.
Higher end computers today manage reasonably with highest settings on some of the heavier games. Multiplying pixels to consider by 4 is intensive.

For electricity reasons and being lighter on your hardware for wearing, as well as portability for use on hardware in general (older and newer) and for quicker (quickest) results the optimizations are more ideal.

Also, considering ZSNES does run fairly well and it is tweaked to x86 opcodes through assembly, Kega Fusion is quite optimized with high accuracy/compatibility and the consoles in general are from the same era and around similar expectations, an optimized SNES emulator which is accurate and compatible and also designed to suit a hardware opcode set can run on lower spec hardware.
20Mhz being replicated to opcode adjustments and tweaks/shortcuts without 'cycle accurate' in mind will not require many Ghz - it should be relatively low and suit working on the person's low spec pc as well as other generally lower spec hardware as well.


EDIT:
Modern games as it is can have a lot of optimizations/tweaks to have easier performance.
A lot of consoles generally get left without more development to maximize effective usage of lower spec designs and programmers expect more convoluted steps to work on higher spec hardware.
This can be noticed with more modern programming done on older hardware like some homebrew (and tech style demos) / games on older hardware.

The Mega Drive game 'Pier Solar' has Mode 7 type effects which can be done by its hardware (and in general provided the math is implemented) - this isn't necessary to a 'chip'.


EDIT:
For general use, it would be preferred as a cycle accurate framework isn't necessary for most users, and is generally useful to perhaps developers.
Perhaps when a general set of instructions for more optimal assembly references and such in a language is established <and reference to existing code like C> a basic edit of the code and a compile would be more effective. It would be ideal to sift through however.
Executables are more bloated than required from modern compilers as is, and the heavier cycle accurate emulation can be reduced in its requirement from this alone.

At the end of the day, irrespective of which chip and its memory does what, and logic/paths designed in mind for 'logic' rather than arithmetic, all results of data which go to a monitor/speaker and input are numbers which have math performed.
Less steps means less cycles and lower requirement for generally the same expected result.


EDIT:


The 'accurate' and 'compatible' (for the most part) Kega Fusion is also assembly and optimized to use the least opcodes in relation to the original ones <implied>, lowering requirement and being suitable for lower spec hardware (and less electricity)
It isn't cycle accurate but it generally seems to calculate appropriately otherwise for compatibility/accuracy.

I'm just highlighting that with tweaks and optimizations (like using asm) a low end user can have something more compatible than ZSNES and functional, as well as less power consumption (also for portable devices) based on tweaks from a built cycle accurate emulator.
Just giving some suggestions for process, and studying.
Thanks.

Integrated circuits are not like mechanical devices. They do not "wear" with use.


So does Contra: Hard Corps. I fail to see how it's relevant to anything.

I think he is talking about the hardware "flow of paths by steps". The paths are becoming dirty with the pixels, and therefore the steps more difficult to be accomplished.

And about the math, it´s still his main ideia. Each game can be converted to a big function, where you enter the rom bytes, one at a time, and the results are the buffers to feed the video/audio cards.

The example of the Mega Drive was part of a description for optimizing code in general and how older hardware is capable of more when programming is optimized. It was a part of a description of a reason to optimize code than use existing code on higher spec hardware.
Also, Pier Solar has the map type view used with Mode 7 which isn't in another Mega Drive game and is a number (of RPGs) in SNES.


As for hardware degradation, one main reason for having a cycle accurate emulator is preserving the overall function of the console (in a developer type environment) once the hardware eventually corrodes/degrades.
With use, the hardware/cpu/ram components are subject to degradation and the more intensive a program the more likely for degradation.

Would be more useable to have an asm/tweaked/optimized SNES emulator based from something cycle accurate to function on lower spec pcs (which could be used as a substitute to ZSNES) as well as not use as many resources (and for far less power consumption on portable devices).

Meanwhile, I have a graphical display emulated on the Asspull IIb, along with a block device inspired by the MSU1. That calls for damp t-shirts! Next up is hardware sprites.

What've you produced lately, Sora?

Try no$cash´s Snes emulator:

http://problemkaputt.de/sns.htm


From the page:

Features:

-The program is 100% assembler code. Accuracy should be quite high (if not: bug are reports welcome).
-Controllers: 1-2 Joypads, Multitap, Mouse, Lightguns (via mouse), NTT Data Pad, X-Band Keyboard, Twin Tap's, Barcode Battler, Pachinko Dial, Exertainment Bike
-Coprocessors: SA-1, GSU, DSP, ST010/11, CX4, OBC1, S-DD1, SPC7110, S-RTC, RTC-4513, SFC-Box, NSS arcade cabinet
-Add-ons: Satellaview, Turbofile (TFII and STF)
-Debugger: Assembler, Disassembler, Xboo-Upload Function (for testing code on real SNES).
-Requirements: Win95 and up, around 8MB RAM, around 200MHz (tested) (on 1GHz computers, most games can run 5-10 times faster as on real hardware).


Like I said, all that you said people already did decades ago (except the absurd math stuff), and you still need a lot of study to understand where the state of the art in emulation is.

I think it's time to pull out Denis Dutton. Never thought I'd have a use for this quote outside of Philosophy and English Language studies, so congrats on proving me wrong there.


SoraK05, I hereby find you guilty of intentionally obscuring your text through unnecessary jargon, excessively verbose statements, and convoluted sentence structure, for the purpose of hiding a lack of meaningful content. Your punishment is to attempt to read an entire chapter of anything by Jean Baudrillard, to understand what the rest of us go through when we attempt to decipher your over-long nothings.

You really have no idea what you're talking about...