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 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...

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.

There simply are no 'standards' in the terminology... Read more than one book, source, expert, and they each give different or overlapping definitions. Sometimes using similar terms to mean very different processes. That is that they give more than one definition/usage for the same term/word.


A purist will object to modern FPGA approaches, usually for more than one reason. But there can be practical advantages to an FPGA solution, and it’s also possible to blend it with a more traditional approach.

FPGA is not the same as emulation
FPGA vs retro hardware
An FPGA can be reprogrammed to implement vintage computer chip designs on new hardware, giving you old chips without the reliability and scarcity issues.

The first thing to get out of the way is the question of FGPA vs emulation. FPGA adherents stress they aren’t the same thing. The difference may or may not be enough for a purist. But there’s enough difference that an FPGA approach is good enough for a class of hobbyists who aren’t happy with the results of emulation.


I've been hearing people talk about "one to one" (ie 1:1) or "not emulation" when talking about FPGAs.  What do they mean when they says this?

Now, what might people mean when they say "not emulation" ?

CPU emulators, such as what one may find in MAME, take a few shortcuts in order to achieve decent performance.  They do not emulate the clock of the CPU, but instead are designed to execute a variable number of cycles in one shot as quickly as the host machine (ie a modern x64 computer) can execute.  The code that is driving this execution is then responsible to regulate the overall speed of the system so that it does not run too quickly.

For example, let's say we are emulating a 1 MHz Z80 cpu.  The cpu management code may tell a z80 emulator to execute 1000 cycles which would take 1 ms on original hardware.  The z80 emulator would then go execute these 1000 cycles as fast as possible and report back how many cycles were actually emulated (it might be more than 1000 because some instructions take more than 1 cycle).  The cpu management code would then have to stall until the 1 ms period has completed before executing the next chunk of cycles.

This creates an unauthentic experience because it means that instead of instructions being executed at a steady slower cadence, they are executed in quick bursts with delays in between.  This is usually not noticeable by a human playing the emulated game because it's just 1 ms, but several problems can arise depending on the other architecture of the original hardware.

On a game like Dragon's Lair where there is just one CPU and a steady clock that never varies, the above method of emulation is "good enough."  A human is not really going to notice any meaningful difference in accuracy.

But what of the game has multiple CPUs such as a dedicated sound CPU?  Now the emulator has to execute a smaller slice of cycles on the first CPU, then switch to the second CPU and execute another smaller slice of cycles.  If there are interactions between these two CPUs (and there usually will be), the slice of cycles that gets executed needs to be small enough so that there is no unnatural lag in the interactions which hurts performance of the overall system.  And even if each CPU takes turns executing just 1 cycle, the potential for an inaccurate interaction between the two emulated CPUs still exists since the emulator does not take into account the clock.

Now, what if the original hardware fiddles with the CPUs clock, or the clock is not constant for some reason?  The Williams games are notorious for doing this.  On a lot of the Williams games, like Joust, their custom DMA chip will actually halt the CPU while the DMA operation is running.  On Star Rider, the CPU's clock gets halted every field for unknown reasons (that's on my TODO list to figure out why).  Last time I checked, this behavior was not emulated very well in MAME (it may have improved since I last checked) and certainly Daphne is not equipped to handle this type of scenario.  However, an FPGA would be able to handle it just fine.

Now, does this mean that emulators like MAME and Daphne can't be improved to take into account a variable clock?  Not at all.  As modern computers get faster, it will become more feasible for emulators to become more accurate without hurting performance.  I believe that aside from the problems associated with running on a modern operating system (with many processes and threads all competing for the CPU's time), there is no reason why software-based emulators cannot achieve 100% accuracy as their architectures are improved.  However, I do not believe that that day is here... yet.

I hope that gives people a better idea of what I consider the difference to be between FPGA solutions and emulation solutions.


"FPGA implementations are emulation, too" isn't really an accurate statement, since they're not emulation, they're hardware clones (that is, re-making hardware in hardware is inherently different from re-making it in software). However, what I think byuu is getting at is 100% true: just because it's a hardware implementation doesn't mean it's accurate to the original hardware. Case in point: the various poor-quality NES, MD and SNES hardware clone systems that have been around forever. Those ASICs were made using the same techniques and HDL as an FPGA implementation would be, except they suck because the Chinese knockoff artists just slapped them together with little attention to quality.

The emulation/retrogaming scene associates FPGAs with extremely high accuracy because the only FPGA-based products released for us have been very high quality (RetroUSB's AVS and Analogue's Nt Mini), but the only reason these products are better than the shitty ASIC clones is that the authors worked hard on them and prioritized making a great product.

tl;dr: FPGAs aren't made of magic accuracy powder.

(If anyone is interested in an ELI5 analogy: you can think of it in terms of a physical object. That is, for any given object, I could make a 3D model in Blender, or I could make a copy of the object out of clay. Neither is an inherently more "accurate" representation of the original, and how close the output of either is to the original depends more on the creator's attention to detail than on the format itself.)

I don't know much about FPGAs, but if I understand it correctly they are chips with programmable behaviour, right?

Not really. The way to think of an FPGA is a giant matrix of logic gates, a giant matrix of wires linking them together, and programmable switches to connect the wires to the gates, and all of those connections are fixed once they're set. (At least until the entire unit is reprogrammed).

Its literally creating hardware -- you're defining what wires run where, and to what logic gates. You can create a turing-complete CPU core in a FPGA, but you don't have to. Every distinct grouping of electronics you define run literally simultaneously. Given early games were written with discrete electronics and multiple coprocessors. With emulation, you're creating interpreters and simulations of the hardware that run sequentially -- to the best ability of the CPU mimicking simultaneous operation. With an FPGA, you're literally running them simultaneously.

The primary difference is you don't do anything procedural in an FPGA. You don't program them. You just use a Hardware Definition Language to define what the electronics look like.

So, as an example, if you loaded a 6502 core into an FPGA to emulate an early Atari, you're not emulating a 6502, you're literally creating a 6502 clone in hardware. You're not saying "okay, if the opcode is this, then go do this, then go do that, then increment the program counter", you're saying "I need a set of logic gates that connect to these other gates, triggered on the clock, and based on those gates, I'll enable this other circuit".

Its completely different, but the FPGA languages, at a casual glance, can make them seem more similar than they actually are.

Under one definition of various terms, this moves us back towards "clone chips" which FPGA is also a subset of, being a programmable clone chip, vs one that is locked in one state.
Hardware vs Emulation
Clones can play games in two ways: through hardware or emulation. Hardware clones, like all official consoles, will work better than emulation-based consoles, so if the official console can play the game, the clone should too. However, even hardware clones are often not completely compatible with all games; many recent clones, particularly Famiclones and Mega Drive clones, incorporate the entire system into a single chip. This is smaller, cheaper to produce and uses less power than a traditional clone, but is less compatible.

Emulation-based consoles are not as reliable; furthermore, like in computer emulators, the game might not properly work, if at all (e.g. Somari's ending). However, emulation-based clones are comparatively rare, especially of the Famicom, as NOAC technology is so widespread - they appear to be most common for the GBA and Mega Drive. Many emulation-based Mega Drive consoles are produced by AtGames under official license from Sega, but are still generally considered clones as they do not use Sega's original hardware designs and suffer from compatibility and emulation quality issues.

Pages: [1] 2 3 ... 53