Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Galron

Pages: [1] 2 3 ... 53
EverDrive GB / Re: Max Capacity MicroSD compatible?
« on: Today at 08:02 AM »
A realistic problem is, in the near future, we can’t buy MicroSD <64GB easily.
Just like that we can’t find any brand new 2GB MicroSD on sale currently.
That means despite of >32GB necessity, we will have to buy >32GB MicroSD in the future no matter how you think about it.

Very true, in most cases as they phase out "smaller' cards, smaller cards become more expensive, while the more common larger cards become cheaper. I've seen sometimes where a 32gb micro sd was cheaper than the 16gb micro sd for example. Sometimes that's caused by sales, on the larger card.

EverDrive GB / Re: Max Capacity MicroSD compatible?
« on: October 17, 2021, 06:48 PM »
What do you do if you get your hands on a newer no-intro set?

Sorting alphabetically is very problematic yes. It makes games hard to find and you don't remember what games you have been playing.

I sort games after genre which makes games very easy to find, and forces you to look up games that you have never tried before so that you know which genre to sort them under. I leave large unsorted folders for games I'm not familiar with or haven't had time to sort yet. Although I only have one copy of each ROM in a set it still takes forever to do, and updating the set is hell. Especially on systems with large game libraries.

What do you do if you get a new No-Intro set?

Only difference is a few new games get added in when those are updated, mainly 3rd party unlicensed indie stuff, recent releases...

All I have to do is delete the older folder put the new folder in... The only reason I have that back up anyways is for making sure I have a list of files available for 'patching' if patch comes out that I'm interested in, to avoid patching my main category files.

Also is easy for basic region stuff... Use search function for "Japan", Europe, "World," USA, etc, and then put them into separate folders.... Then if there is something I'm looking for to sort it into main folders I just use the 'search function' to find it... and copy/paste....

I rarely have to change anything in main categories I use in the main section of the micro sd, because the roms work, and I don't expect them to be replaced... with 'alternate' roms that change anything... if they work I'm not likely going to go out of my way to replace them with a slightly modified 'expanded' no-intro set...

I sort games after genre which makes games very easy to find, and forces you to look up games that you have never tried before so that you know which genre to sort them under. I leave large unsorted folders for games I'm not familiar with or haven't had time to sort yet. Although I only have one copy of each ROM in a set it still takes forever to do, and updating the set is hell. Especially on systems with large game libraries.

This... this is why genre is my main type of sorting.... I learn more about the games that way, it helps me to try out new games that are 'similar' to ones I enjoy, etc.... It's just all around easier to find stuff... Yes I had large unsorted files, but I've taken the time to sort them when I had free time, at this point there is very little that is left to sort... I'm not gonna be moving or touching or replacing those at this point... Unless its to replace a game that 'doesn't work with a game that does work (if there turns out to be a compatibility issue, or buggy rom, and and a patch is neded to fix it).... That's why I maintain a non-working folder as a type of "genre" just to keep track of the games that won't work....

Like I said, the no-intro set is a back up just to make sure I have fresh clean files for patching available, or replacing any files in main genre folders if any roms accidently are deleted or 'patch corrupted'.

As for 'cross-sorting' taking an example Mario and Luigi's Superstar Saga... Ok right now the best version of the game is with a rumble patch that adds rumble back onto the console itself (if you have a rumble capable flashcart) without having ot use Gameboy Player + gamecube controller... It's now become my ideal main rom for the game... I delete the 'no-intro' unpatched from the category it was in "RPG Genre", and in "Mario Games" IP category. That's the two main categories its in...

I leave patched rom in their place, patch rom is also under 'special category" in the "rumble games" category, so that I'm able to test all the games with rumble abilities, and not have to hunt for rumble games I'll probalby forget about mixed around many different genres...

The clean copy no-intro just remains in no-intro backup folder. Assuming I need it for something, or for future patches. It'll be easy to find wiht 'search function' at my computer if I need to make a new patched rom. THis takes less than 20 seconds really to patch and saved the patched file elsehwere, and then copy and paste the patched files to relevent folders. (Genre, IP, and Rumble) in this case.

But, ya it was several days of work to set up for each flashcart. (I.E consoles)... but once set into place I find my method makes everything easier for me, when testing new games coming out, the genre folders are already there to place it into which ever are applicable. via simple copy and pastes.

EverDrive GB / Re: Max Capacity MicroSD compatible?
« on: October 16, 2021, 11:00 PM »
It sounds like he is on EDGB but is using a very wasteful ROM organization method with multiple copies of the same romset many times over. It must take forever to keep up to date unless he is using some kind of automated process.

I own EDGB and EDGB X7.

At the most a single rom tends to be in 3-4 "used" categories, and one 'backup (this is an unsorted no-intro backup, only sorting is by 'region')' (One for its system type GB, GBC, SGB or hybrid (this makes it easier to get to them if I'm using it on a certain system), another for its genre, and another for its series, if applicable). There is a 'technical/special' category but that's got very few items,mostly stuff that won't work on GBAG, or needs specific hardware to work. Where something is incompatible altogether (or with the largest subset of platforms) I don't have them in any other folder, to avoid accidentally useing them when testing something out. So they are only in the special/broken category (or at most also in the no-intro backup)...

Once roms are in place I don't have to change them, or update them.  Other than patching roms and I usually do that manually. But patches don't come out all that much. But yes it took a very long time to do the categorizing. But it really helps me avoiding forgetting the name of something or where I placed it....

Saves are shared by all instances of the same file, as long as the roms shares the same name, no matter what folder it's in.

IF this was a PC i'd use a 'shortcut' file, but that's not possible on a flashcart.
Basically the story in short is that I was using a 8gb flashcart before... It was mostly US a few UK stuff, and some translated Japanese stuff... It was covering aroudn 7 gb or so of the microsd in the way I was categorizing things on it... However, I had noticed I had cut out most of the japanese only game roms too, or japanese gamers with considerable differences. Plus a bunch of Indies had come out, and the gigleak which I needed space to add to the card, but it was short...

It added up to roughly  9gb total, to add all that stuff and have the categories... Which is over what can fit on an 8gb rom (which I had been using previously).

I double checked recently and discovered I had traded for a MicroSD from somewhere else (or rather recycled the old one for it) of 16 gb, which covers everything. I just need to still double check if I added Japanese only stuff I hadn't included before.

It's only around 14gb, because I keep the no-intro set backed up on it.

Plus pc emulator, patching software etc on the Micro SD when I'm working with it on the PC.

I know alot of people use straight up alphabetical categorization (like smokemonster packs), but I find that's confusing and slow to find stuff (in order to go through all the pages of roms)... Even he has some redundancies, and miscellaeous confusing folders to follow.

I think you meant the hardware side. The ROM is the software side and the physical bezel and liquid crystal segments would be considered hardware.
But yes, it's fascinating. The images are made in vector form to mathematically preserve the shapes of the artwork as much as possible and making resizing without hurting the resolution possible. Hopefully it's enough information to manufacture a good replacement screen for a G&W game.


Most G&W simulators are software that simulate both G&W hardware and software as a whole, focusing on the look and feel, not what's under the hood. They do not contain a single bit of code of the original, wether hardware, if that makes sense, or software.
Isn't that exactly what I was saying?

I mean the artwork/photos/graphics are all external 'software' (in this case the GUI/display for the emulator).... It's simulated environment not actual environment. Because its impossible to have an actual LCD display... Game & Watches don't 'display' graphics they just turn on/off sections of a LCD display. The only emulation of the hardware is on the firmware side of things, the rom, the inner workings/calcuations.

In theory though if you had an actual Game and Watch LCD 'display' for a specific game you could wire it up to the 'emulator' to produce original results of how original operating board would have functioned (and have it function on the LCD display), but that would be somewhat redundant.

Even when a Game & Watch game's ROM had been dumped, one of the biggest challenges with accurately emulating it was with how the Game & Watch displayed graphics. Rather than by sending output to an LCD display like most cartridge-based handhelds do, Game & Watch games (as well as most other handheld electronic games from the same time) displayed graphics by lighting up pre-drawn LCD segments, like a calculator. To recreate this as accurately as possible, MAME uses .SVG files traced from high-quality scans of the LCD screen, allowing graphics in supported Game & Watch games to be displayed crisply at any resolution without the loss of any detail. While this is the most accurate way to recreate the LCD graphics outside of obtaining the original art from Nintendo, it is a difficult and time-consuming process as not only does the LCD need to be scanned at a high resolution with all segments lit up to capture all of the graphics but the scans must be traced very carefully to faithfully recreate the original artwork.
SVG are graphics files...

Ok, I see where the confusion is.

I just meant that it's a piece of software that, on its own, simulates the results of the hardware and software that a G&W system consists of.

There is a difference between 'simulator and emulator'... But the use of terms such as 'simulating"/'simulate'/'simulated', or 'Simulation" doesn't necessarily mean running on a "simulator". Other forms of simulating might be using 'models', or 'graphs', 'acting' or some other sort of thing (to show or reinact the processes or 'end of function'/results). It might not necessarily be real time. See related term simulacrum.

This distinction ends up with people giving difference answers depending on their contexts....

Dictionary wise they are very different terms (with several meanings each)... Simulate/simulating (verb) and simulation (noun) are connected.. while Simulator is its own odd-one out term....

 simulation noun
Save Word

To save this word, you'll need to log in.
Log In
sim·​u·​la·​tion | \ ˌsim-yə-ˈlā-shən
Definition of simulation

1 : the act or process of simulating
2 : a sham object : counterfeit
3a : the imitative representation of the functioning of one system or process by means of the functioning of another a computer simulation of an industrial process
b : examination of a problem often not subject to direct experimentation by means of a simulating device

 simulate verb
Save Word

To save this word, you'll need to log in.
Log In
sim·​u·​late | \ ˈsim-yə-ˌlāt
simulated; simulating
Definition of simulate

transitive verb
1 : to give or assume the appearance or effect of often with the intent to deceive : imitate
2 : to make a simulation of (something, such as a physical system)

 simulator noun
Save Word

To save this word, you'll need to log in.
Log In
sim·​u·​la·​tor | \ ˈsim-yə-ˌlā-tər
Definition of simulator

: one that simulates especially : a device that enables the operator to reproduce or represent under test conditions phenomena likely to occur in actual performance

Emulator has multiple meanings.

Hence likely the main reason why emulator and people saying 'simulate', or 'simulating' or 'simulation of' depending on the construction of their sentence, has nothing to do with 'simulator' but can be used in the context of an 'emulator'...

It also helps to see what differences where emulate and simulate fit on a thesaurus for similar meanings...

Simulator does not have any words closely connected to it on WEbster's side, but has a few. But non that are particuarly relevent in relation to the technical field usages of the term.

    bunco artist
    con artist

... While emulator does... Although the thesaurus equivalents for 'emulator' are largely useless in the context of computers and more in the case of an 'actor' or 'con', or a 'mimic', 'ditto' (another word for 'copy'), and copy (the later has overlap with simulation/simulate)...

Webster's thesaurus alternate synonyms...
Synonyms & Antonyms of emulator

1 as in ape, impersonator

Synonyms & Near Synonyms for emulator

    ape, impersonator, impressionist, mimic


    aper, copycat, copyist, echo, follower, imitator, rubber stamp, wannabe (also wannabee)

2 as in rival, competitor

Synonyms & Near Synonyms for simulation

miniature, mock-up

    carbon, carbon copy, clone, copy, dummy, dupe, duplicate, duplication, facsimile, imitation, mock, reduplication, replica, replication, reproduction

    counterfeit, fake, forgery, knockoff, phony (also phoney), rip-off, rubber stamp, sham

    reconstruction, re-creation

    image, likeness, semblance, shadow

    impression, imprint, print

    approximation, reincarnation, version

    extra, reserve, spare


Synonyms of simulate

to present a false appearance of

    cosmetics that simulate a suntan

Synonyms for simulate

    act, affect, assume, bluff, counterfeit, dissemble, fake, feign, pass (for), pretend, profess, put on, sham

Words Related to simulate

    dissimulate, impersonate, let on, masquerade, play, playact, pose

    forge, imitate

    camouflage, conceal, disguise, mask



Phrases Synonymous with simulate

    make believe

Surprisingly while not exactly synonyms to each other, many of the synonyms or near synonyms for "simulation" might have more in common with a "emulator" in the technical field sense. At least when taking 'reconstruction/cloning/copying' into account.

But both simulate/simulation and emulator have similar meanings in general terms of 'immitation'/phony, etc... Which is not particularly as useful in field of technical uses of the terms.

So anyways the final point being here, if someone says "emulator' has 'simulated' somethign they aren't saying an emulator is 'simulator'.. Simulators and "simulated/simulation/simulate/simulating" have unconnected meanings to "simulator"...

As stated in the article....
Enlarge / For a truly perfect emulator, just making ~3,500 commercially released SNES games playable isn't enough. Every function of the system has to be simulated with cycle-perfect accuracy, too.

But I'm digressing again, and going way outside the scope of this original discussion...

EverDrive GB / Re: Max Capacity MicroSD compatible?
« on: October 15, 2021, 04:10 PM »
Formating software should work. Although that's not a indication that the operating system can still read space over a certain amount. It really depends.

I know of the show, but not much about the game. Just that the N64 game is put on a list of best N64 games that never made it to to US. I was just pointing out I think it was a game based on that show. Although I might be thinking of another game with a similar premise.

EverDrive GB / Re: Max Capacity MicroSD compatible?
« on: October 14, 2021, 07:17 PM »
So basically its had to do with how I sort things...

First layer is "BY Genre", "By series", "Special", and 'unsorted'.

Genre is fairly basic right now and I haven't completed all my sorting there, but its general stuff like RPG, Puzzle, Action-adventure, misc, etc... I put Arcade, platformers and shooters under action category. Each of those get broken down int subcategories as well... In these folders I don't mind mixing and matching GB/GBC, and hybrid games together since they are used primarily for Gameboy Player, and GBA use. That's roughly 244 mb, nothing big yet.

Then 'by series', this is basically by IP, I have most nothing finished there in my categorization... But this would cover IP series like games that have Disney characters but cover more than one genre.

Special is basically split by operating system, or special chips, or interesting quirks, all or most of the GB, SGB, Hybrid, and GBC games. 3d games folder, GB classic folder (only games that were for GB Classic but not Super Gameboy), GB-GBC Hybrid, GBC Enhanced (these are games that were originaly for GB Classic, but got special pallets on the GBC), GBC-GBA Enhanced (games that open extra features if played in GBA, like GBA store in the Zelda Oracle series), GBC Only folder (these are GBC cartridge games, also work in GBA of course), SGB for super gameboy stuff, and folders for games that use SPeech clips and video clips (again 'special technology' in this case, not something you generally expect out of GB/GBC games).

Super Gameboy is also split into its own subfoldres mainly based on region, and 'broken' (usually mapper issues, like Robopon, Roboponcots, because these had special features and used built in IR on the cartridge). A section for "Translated SGB Roms".

Compatiblity issues (these are games that have issues between different versions of GB, and GBA, etc. For example folder for GB only, games that have issues on GBC, a folder for games that have issues on GBA or GBA SP, games that originally had rumble built in (these roms may work with rumble on GBP, but I haven't tested it), folders for IR Port compatible games, motion sensor games, GB camera roms, and "unusable" (these are games which X7 can't handle at all due to lack of mappers).

So far this mainly covers 1.75 gb for all the stuff I have categorized in special, and that includes any overlaps and roms sharing multiple categories.

Unsorted covers a bunch of misc. stuff like betas, SAG rompacks, Gigadump stuff, back up rom patches, 'reskin" category (these are games that got prots across multipel regions but each one has a totally diffedrent reskin like Ghost busters and  Garfield, or Radical Rex based games (Baby T-Rex, Agro Soar, Edd the Duck We're GBack", etc, or Crazy Castle (reskined as anything from Bugs Bunny Mickey Mouse, to Hugo). Many of my rom hacked games (these include color hacks for games, and other fun stuff). Intend to have complete No-Intro set here as well (I have at least partial no-intro set in place but it might be missing some). Lots of homebrew stuff too. THere is an unusable category here too for anything that doesn't work with current mappers on the everdrive (this mostly being unlicensed stuff, and prototypes).

I need to double check that I have all the japanese games from no-intro GB and GBC collecitons, as I may have left those off due to space issues originally.

In anycase my files take up roughly 4.85 gb of data on the 14.8 gb capacity (16 gb micro sd).

There is an extra 9.97 space it seems.

It may be that I already moved roms from a 4gb or 8gb card because japanese and/or european stuff (complete romset) didn't fit on the micro sds I previously used. SO I might have already 'fixed' the issue if I had upgraded to 16gb.

I know I had more troubles with GBA stuff and recently went from I think 64 to 128 gb (for use on my Omega DE) because it takes up more space with the romhacks/translations, GBA Video carts, and other special stuff, ended up taking up 78.6 GB... But that also includes 'some' stuff for Goomba purposes (rumble compatible games) as well (but that's not alot of the space). The general categories I have setup take up 40 gb, but there is full backup of nointro set as well (for case of finding fresh roms for patching in future).

Also I notice I tend to put pc emulators on the micro sds as well for testing roms when I'm adding or patching roms.

EverDrive GB / Max Capacity MicroSD compatible?
« on: October 14, 2021, 02:47 AM »
Will a 32gb or 64gb or 128gb work... Don't expect needing much larger than 32 or 64 (but sometimes 'larger' is cheaper)... But found 16gb was too small to keep my selection of romhack/translated games (GB, Super Gameboy, GBC, Gameboy Player/GBA enhanced selection, and other special purpose categories), plus full set of games from every region, plus have space for all the categories I use.

My top 10 would be all the RPGs, and adventure games, plus Japanese Castlevania version... There is also some really cool looking interactive movie type game with giant robots that would be very cool to play in english. Neon Genesis Evagelion I think?

FXPAK (SD2SNES) / Re: Max Capacity Mcrosd on SD2SNES Pro/FXPak Pro?
« on: October 14, 2021, 01:42 AM »
Brilliant thanks! That's the kind of information I was looking for!

FXPAK (SD2SNES) / Max Capacity Mcrosd on SD2SNES Pro/FXPak Pro?
« on: October 13, 2021, 11:50 PM »
I'd like to give my flashcart largest size memory card it can handle (in order to hold more MSU-1 titles). Sandisk seems to be most compatible.

What are the largest size MicroSD people have tested (assuming they properly formatted the micro sd to compatible fat32)?

It seems like Japanese version has the voices too. Nothing about it being in Japanese though, so it might be the same voice acting as the PAL version.
US version was released first.

Well, sounds like if it has enough differences, and voices are in english, and to get regular save game files, it would be well worth getting a translation of both versions (Castlevania 64 + Legacy of Darkness) for NTSC play!

The fact they dumped the rom and not just rebuilding the game from ground up is fascinating as a whole as well. The software side covers the graphics which obviously roms can’t display on their own, and are made from taking images of the actual G&w screens and the artwork from those screens.

Galron, I find no interest in trying to discuss here, you made that impossible.

You may keep quoting the entire web if it pleases you.

That’s fine. Considering I think this discussion goes well and far beyond the scope of the original intent of this tread and the claims made by the reseller.. Which’s clear that all flashcarts use FPGA and work essentially the same... and one isn’t “only emulation” and other isn’t only “hardware”...

Simulation is in my experience more often defined as Nemok described. Like those Game & Watch simulations that this guy made long ago, it was just computer programs that looks and feels like Game & Watch games without doing any kind of emulation at all. Now when many Game & Watch systems have been decapped, studied and got their ROMs dumped, accurate emulation has become possible in Mame.

Right that is one usage of 'simulation', context matters. There are also 'software simulation' and 'hardware simulation'.  Game & Watch falls more to the software simulation side of things.

Hardware simulation is something more complicated, and generally more abstract in that by one definition it tends to be something that is run in the background, and used to test how hardware will theoretically work, but tends to be less 'interactive' for purpose of debugging something... It might be real time, or different speed dependent on how it is used.

Note the self-contained "Ikos NSIM-64 Hardware simulation accelerator."

The low-level and high-level definition looks strange to me. Usually low-level emulation is when the system is emulated down to a low hardware level, which normally means more accurate emulation and high-level means a high abstraction level and more inaccurate emulation.
You are also quite right, in that there is another definition for low-level and high-level...

The above definition is the one based on some of Near's writings, and which he separates 'software based emulators' into three types, low-level, medium-level and high level...

But others reverse the meanings for only low-level and high-level which may be on hardware or software.


Low-level emulation

In low level emulation, the PC pretends it’s the video game console.
In low-level emulation, the PC pretends it’s the video game console.

Low-level emulation (LLE) simulates the behavior of the hardware to be emulated. The host computer will create an environment for the application to run where it’ll be processed, as closely as possible, as the emulated hardware would do it. For the most accurate emulation, not only are all the components simulated, but their signals as well. The more complex the system, either by having more chips or a complicated one, the more difficult it becomes to do LLE.

LLE can be achieved via hardware or software. In hardware, the actual hardware or something that can substitute it resides in the system itself. The PlayStation 3 in its first two models did hardware emulation by containing the actual hardware used in the PlayStation 2. Older Macintosh computers had an add-on card, called the MS-DOS Compatibility Card, that contained a 486 processor–based system to run x86 applications.

Software low-level emulation is as it sounds, it simulates the hardware using software. Many retro video game consoles and 8-bit home computers are emulated this way by using well understood components (it’s harder to find a popular system that didn’t use the venerable MOS 6502 or Zilog Z80). One aspect that can make or break an emulation is how often it syncs up each emulated component. For example, the SNES emulator Higan aims to be very accurate by increasing the amount of times the components sync up with each other. This allows for games that had timing hacks or other quirks of timing to be playable. The cost of this however, is that Higan requires a very fast processor relative to what it’s trying to emulate.
High-level emulation

In high level emulation, the PC provides software hooks so the game can run on its hardware.
In high-level emulation, the PC provides software hooks so the game can run on its hardware.

High-level emulation (HLE) takes a different approach to simulating a system. Instead of trying to simulate the hardware, it simulates the functions of the hardware. In the mid-'90s, hardware abstraction was spreading to more computer systems, including video game consoles. This allowed for ease of programming as now developers didn’t have to invent and reinvent the wheel.

Hardware abstraction is a way of hiding the intricate details of controlling hardware. Instead, it provides a set of actions that a developer commonly uses and does all the little details automatically. An example is how storage drive interfaces came about. Originally, if a developer wanted to read data from a drive, they had to command the drive to spin up, position the read/write head, and get the timing down to read the data, pull the data, then transfer it over. With hardware abstraction, the developer commands “I want to read at this place” and the firmware on the drive takes care of the rest. An HLE takes advantage of hardware abstraction by figuring out what the command(s) are intended to do in the emulated environment, and letting the host hardware do the rest.

HLE has three primary methods of simulating functions of the hardware.

    Interpreting: The emulator executes the application’s code line by line, by mimicking what each instruction is supposed to do.
    Dynamic Recompiling: The emulator looks at chunks of the application’s processor instructions and sees if it can optimize them to run better on the host computer’s processor. This is opposed to running each instruction one by one, which usually results in lookup overhead penalties.
    Lists interception: Co-processors, like the GPU and audio chip, that have enough hardware abstraction require the main processor to send command lists. These are a series of instructions that tell the co-processor what to do. The emulator can intercept the command list and turn it into something the host computer can process on a similar co-processor. For example, command lists going to the emulated system’s GPU can be intercepted and turned into DirectX or OpenGL commands for the host’s video card to process.

An example of an HLE is the Java Virtual Machine (JVM). Java code is not actually compiled and run natively on the host machine, but instead, the host machine runs an emulator of a theoretical Java machine. Applications made for Microsoft’s .NET framework also run in this fashion. This way of running an application is commonly known as just-in-time (JIT) compiling.

The performance HLEs can provide is such that it was possible to emulate the Nintendo 64 on a Pentium II processor in 1999, three years after the console’s release. In fact, this is the most likely way the Xbox One can emulate the Xbox 360, despite running hardware that isn’t vastly superior to it.

However, it should be pointed out that the low, high, medium usages applies only to 'accuracy' of emulation, not the type of emulation. L/M/H accuracy is not the same as "Low-Level/High Level Emulation...

Low accuracy

An emulator isn't accurate when it has a large amount of visual and audio glitches and favors performance as much as possible. To work around these glitches, emulator developers typically include game-specific hacks (and prioritize popular games) to skip over problems, such as compatibility issues that can cause games to break. Many times, these emulators will be deemed incompatible with the less popular games. As Near (then known as byuu) explains in a 2011 Ars Technica article linked below, Speedy Gonzales: Los Gatos Bandidos will soft-lock towards the end due to a specific hardware edge case that isn't emulated in ZSNES or Snes9x, but is properly dealt with in his own emulator higan due to his documentation of the system. This can also become very problematic when ROM hacks abuse software errors to create otherwise impossible behaviors to achieve what they can. When a ROM hack can only be used in that one specific emulator, he explains, it becomes incompatible with real hardware (either through a flash cart or printed), and that such an issue has occurred with ZSNES before and continues to occur with Nintendo 64 ROM hacks.

Newer emulators tend to favor High-Level Emulation (HLE) as opposed to Low-Level Emulation (LLE), which results in lower accuracy. While emulators like Dolphin favor accuracy but still retain HLE for performance and have successfully used it to an advantage, these types of exceptions are uncommon and it can still hinder accuracy.

Medium accuracy

Most emulators headed by multiple developers tend to have fewer glitches but still, have many problems.

High accuracy
Emulator developers often strive for high accuracy when the system cannot effectively be cycle accurate. Their emulator replicates the components of the original system as closely as possible, and as Near explains it's that reason that more processing power is required to do so. This results in fewer audio and visual glitches and better handling of edge cases used by creative game programmers. An emulator with high accuracy may or may not be cycle-accurate and sometimes, they achieve 100% compatibility with commercially released games.

This is yet another case where 'experts' each have their own definitions and there is no single standard... It all just depends on which industry you come out of really... engineers, programmers, etc.

While there are 'experts' that agree on certain aspects, not all 'experts' use the terms the same... To simply look at one small group of 'experts' is "appeal to authority" bias.. Especially problematic when the authorities have almost no agreement, and the terms definitions change depending on the 'context' of how they use them. So its important to read the context, and not just the terminology.

As someone astutely points out:


I think a problem is there is no agreed-upon definition. A historical definition is "emulation" uses hardware support. That's not typical usage today but was typical for a long time. "Simulation" is sometimes used to mean "works like a device which is not yet built", while "emulation" is sometimes used to mean "works like a device which is no longer built." Again, that's not an agreed-upon definition, but I hear it used. Also "emulator" as a way to "work like the original", while simulator as a way to "measure something like the original". Also, notions of accuracy, where "emulator" may be either less or more accurate than a simulator. The dictionary definitions suggest "emulate" is more accurate than "simulate". Perhaps the clearest approach is to list the various (confusing and sometimes contradictory) uses, so when people use a term speakers are included to say "simulator, by which I mean..." and listeners are inclined to ask "emulator, by which you mean...?"

Appeal to authority is a common type of fallacy, or an argument based on unsound logic. When writers or speakers use appeal to authority, they are claiming that something must be true because it is believed by someone who said to be an "authority" on the subject.
I think it's necessary to use separate terms for "software based emulation" and "hardware based emulation", otherwise this discussion wouldn't have happened, and it comes up all the time. The word "based" can't be skipped either because "software emulation" sounds like it's the software that's emulated, both types of emulations are hardware emulation (they both emulate hardware not software). Or something more definitive like "MPU (microprocessor unit) based emulation" and "PLD (programmable logic device) based emulation".

This the point I've been trying to make from the start, if you don't specify the the type, which the reseller clearly didn't. Then most people assume you mean 'software based emulation'... The problem is 'software based emulation' can also be confusing as there are software emulators that also emulate at hardware level. Such as Higan for example.

Pages: [1] 2 3 ... 53