Im kinda of a noob at emulation, But why does when you emulate on a more powerful console or system, why is there still lag and graphics and audio issues? Is it because the hardware built for the newer console isnt meant to play older games then its console famliy and meant for that one system. Is there not specific hardware to fully emulate games that that game's console had? Does the emulator used for a console, try to maximize the emulation by using the target console's hardware that it wants to emulate and try to link some hardware that that old console had for the newer console hardware to try to use for emulation? Idk if you guys know at all
You are technically asking multiple things, even if you did not quite realise it.
For the best accuracy you need a fully working model of a system inside another, if you want to get really insane you can model the transistors inside the chips or recreate the chips in programmable hardware (see the opening post as I linked a few things up there) but nobody really does that for end user things right now. You can however get useful results for some games if you sacrifice some accuracy. In sacrificing accuracy it can also be possible to gain some speed.
Speed then. Emulating a single chip is usually doable enough. Most consoles are not just one chip though -- a CPU, possibly multiple CPUs, a graphics chip, some sound chips, in the case of the NES and SNES they often had chips on the carts themselves that enhanced the processing power of the system (see also why certain games pose problems for certain flash carts and emulators), some chips governing controllers/drive reads/the system itself... and they all have to be in sync as it were which itself is a nightmare -- not strictly for emulation but look up Amdahl's law for more on that. Many years ago we used to have a rule of thumb that you wanted a computer 10 times faster than the machine you are emulating to do it well, though it can get more extreme than that --
https://arstechnica.com/gaming/2011...-3ghz-quest-to-build-a-perfect-snes-emulator/
An example of accuracy might be... saving. A while ago there was a thread from someone looking for some help to save their high scores in gameboy tetris between sessions (the base game technically lacks it, probably as it would be expensive to add that feature to however many millions of gameboy tetris carts were being made -- 20 cents x millions is still a lot of money). Fair enough, have a little hack that writes the data from the score table into the save section (it is only being emulated after all) and read it back out afterwards. Simple copy was employed. Worked fine on most emulators. Flash carts and super accurate emulators failed. The problem in the end? Most chips have a "write enable" command so you first have to tell it you want to write, then do the writing and then disable the writing mode. No normal game would ever write without it (give or take someone use it for anti piracy/anti emulator) so you just ignore the enable command and you have saved yourself some resources in emulating that functionality at no cost to any commercial game or homebrew. That is probably a small saving but make enough of those and it adds up.
You may also notice that your host device has a similarity with the system being emulated. If you can use this inherent feature then you don't have to emulate -- if you are emulating the GBA on a 3ds then as they both have ARM processors you don't have to mess about reformulating say an ADD command as much as you would for a PC which also has ADD (despite what I will say below everything in computers is adding) but it works in a fairly different way. Accuracy can also come back here. A good example might be SNES emulation on the GBA -- graphics come in layers (backgrounds, a few sprites, some more sprites... see any tutorial on sprite animations really) and the GBA has layers but not the same as the SNES. As there are so few layers (4 of the things which is not many combinations when all is said and done, even fewer if you have some toggle switches) you can be expected to manage it yourself and not have to handle it in software, so the SNES emu devs on the GBA did just that.
There are also other tricks. The first one most would suggest we look at is dynamic recompilation. Owing to a fundamental aspect of computing (the halting problem -- short version is much of computing boils down to "if this then that, otherwise do something else" and if you don't know what the conditions will be when it hits that if statement then you can't predict the outcome of a program. It also informs going backwards from compiled code the CPU runs to a human readable type of code, though you can recognise fragments. If you are running the code then you might well know what the conditions are in that instant and you can then predict what happens next. In doing this you can change emulation from being a thing where you have to simulate all the chips involved to something that runs like a normal program on that system which is so much faster. This is not very useful for older systems that for the most part saw games written in code like the CPU uses (a hard way of writing code but exceptionally fast if you can do it well) but for things like the PS1 and N64 on up it (which famously used higher level languages that more devs could handle) becomes very useful indeed.
Lag is more that most consoles/things emulated work on frames. They do one frame, then they do another and another and another (varies but the usual suspects are 25,30,50 or 60 a second depending upon region). If your host system can't keep up then it is not going to be outputting the frames fast enough and you have slowdowns. Some emulators will employ a technique called frameskip where they skip rendering a few frames here and there. This allows your host machine to keep up (you hope anyway) but obviously if you are missing frames it is going to start to affect gameplay -- no great loss for a turn based game but possibly fatal for an action one.
Your PC though is a computing monster, with the added benefit that some of the finest minds in computing have spent decades and probably trillions of dollars refining it, making tools for it and otherwise understanding what it is (even before computers took over designing themselves the implications of a given arrangement might still take years to understand fully).
Your hacked console though is probably a bit less powerful than your PC, certainly will be if it is a handheld, and its tools are made by some very talented people in their free time (
https://devkitpro.org/ ) or stolen from the original developers and patched to get working (the GBA had some of this but most here would look at the original xbox), said original developers equally having only put it together on the cheap over a couple of years.
Alternatively your hacked console might be using an emulator made by the console developers. As they sell one game at a time they can/only have to make the emulator work for only one game -- back to our save example from earlier then if the devs are selling classic GB tetris then they have no incentive at all to spend time making save support for it. Saves are not terribly important but if you found the original game did not use a fairly in depth part of the graphics hardware and you don't then have to spend a few hundred hours of dev time wrestling with it then you skip if, would be console hackers then trying to use that emulator will find it lacks support for that graphics feature and games that use it will fail.
