Importance of Emulation for Hardware Preservation - Part 1

Hi! This is the part 1 of my monography "IMPORTANCE OF EMULATION FOR HARDWARE PRESERVATION", which I used for getting my bachelor degree at computer engineering. This part focuses on the definition of emulation, the difference between emulation and simulation, and the importance of preserving hardware.

This is the english version of the paper, while the original, portuguese version, is available here. The monography had the orientation of Prof. Guilherme Guindani, Ph.D and was evaluated by Prof. Laercio Carpes, MSc.

Since this is a translation of the original version, there's a chance of the article having errors. Please let me know if you find any issue with the paper.

Abstract

Because a hardware is made of electronic components, it will likely fail through the time. In addition, the time will make the electronic components obsolete, which, usually, are harder to be replaced or maintained. If the source code (hardware description), for whatever reason, is not available, there's a huge risk of losing the device and its functions permanently. A solution is creating an emulator through reverse engineering, either in software or hardware, that reproduces with accuracy the original behavior of the device. It's possible, through some techniques, create accurate emulators that allows to a device be recreated even if using resources completely different from original, either at functional level, clock level or even at gate level. Videogames and devices that do specific functions are example of hardware that can get the benfits of emulation and reverse engineering.

Key words: emulator; hardware; reverse engineering; preservation.

1 INTRODUCTION

Electronic components overall have a limited lifetime. Every hardware is subject to failure in long term and without a way of preserving it digitally, there is a risk of losing the device, making it impossible to be use it again.

We won't always have the source code or the hardware description data (such as HDL) available, either because the project is closed source or either the company or company's department no longer exists. There's even the chance of the design being permanently lost for whatever reason. Because of the reasons stated previously, it might be impossible to recreate the project due of no source available and there's also the chance of the components (for example, electronic component or code dependencies such as a compiler) are no available for commercialization or were made obsolete.

A possible approach and solution is recreating the device through accurate emulation, where using reverse engineering techniques it's possible to understand the functionalities since from the very basic components to the smaller details (such as hardware behavior), being able to recreate the preserved device either in software or hardware, allowing it to be used again without losing its characteristics and behaviors that only the original hardware presented.

Depending of the objective, available information and the hardware flexibility (that is, if it's possible to execute a custom software or procedure), different techniques can be used to make the reverse engineering of the device, where the more deeper and precise the process, the more accurate will be the emulator.

Emulators has different precision levels, which the most common being: functional level, which focuses on the most important functionalities and is usually associated with high level emulation (HLE); clock level, which focuses on emulation cycle by cycle (cycle-accurate) and is considered very accurate for dealing with operations at low level, also known as low level emulation (LLE); and gate level, also considered LLE, which has the objective of working with a behavior so close to the original that is able to interact with other hardware components through PLDs such as FPGAs.

2 Why hardware and software should be preserved

The technology is constantly evolving. Over the last decades we saw different technologies for storing, transmitting and reproducing audio and video content. From analogue components, that is subject to interference and rapid degradation, we transitioned to digital components (information is sent in digits), where the content is stored in a manner that the electric components will not cause interference and allows to a much higher audio and image quality and fidelity compared to older formats.

Figure 1 – Picture of a magnetic tape which is used, between other things, to record and reproduce audio, a very popular form in the 80s (UTMEL, 2021).

From the cassette tape, which was very popular in the 80s, we gradually evolved to newer data storage devices types. The newer technologies not just last more, the new devices has a much larger storage capabilities with lower costs, reducing the cost per megabyte. For example, while a magnetic tape can store about 660 KB (kilobytes) of data (UTMEL, 2021), a CD can store about 700 MB (megabytes) of data (Eric G, 2022), an over 1000x difference in terms of storage capacity.

Figure 2 – A picture of a CD (compact disc), that can store up to 700 MB of data (Eric G, 2022).

Together with the evolution of the data storage, there was also an evolution on the devices responsible for recording and reproducing data. For consequence, gradually most of the devices stopped supporting legacy data storage devices to favor more recent technology. It's an expected thing when there's an evolution in an order of magnitude between the storage types. Because of that, we now had the need for migrating the old formats to the newer, in a manner that is possible to reproduce the sound, video or access the old data that was originally stored in an old storage device. For such task, devices specialized in migrating data appeared, making the conversion of the audio and video signal or data to the new format. For example, devices that migrated VHS to DVD.

Attention: audio and video format. Formats that, although they have some kind of structure and encoding, when decoding they become raw data that can be encoded once again into a newer format, making it possible to migrate to the newer devices without loss or incompatibility between the media players, a process known as transcoding. TV channels, content companies and producers gradually convert their collection into a new format, so the content can stay preserved. Thanks to that, we can play movies made one century ago in a modern device without having to buy an equipment and a specific media only to reproduce an legacy content. In other words, it's possible to migrate the data from an old structure and format to a more updated format that works with our current technology, without having to rely on devices that would be likely obsolete nowadays.

The same can't be said regarding software. A software, although its format is made of data, just like image and sound, it's made of instructions, where the instructions were made specifically to the hardware architecture which was designed. Not many time ago, every software was compiled and designed for a very specific hardware architecture, using dedicated and exclusive hardware features in a manner that you can extract the maximum potential of the hardware, given the performance constraints. For example, the main Super Nintendo processor, the S-CPU chip, has a maximum clock speed of 3.58 MHz (Evan G, 2012). A software written to the Super Nintendo, just like other video games devices made for that year, must use the maximum potential and special features of the hardware for getting an acceptable performance because of the low throughput (processing power) of the processor, compared to nowadays. This was pretty much the reality of every single hardware made before 21st century.

Figure 3 – The Super Nintendo motherboard. Most of the software written to the SNES explored the maximum possible of every single chip present on this picture (Near, 2020).

A possible solution (for software that can only run under a specific hardware) would be migrating the software to a newer hardware. Essentially, would be rewriting the software from scratch, including its data structure, system calls and hardware features to the newer device.

It's not exactly uncommon, specially in games (process known as porting). It requires a considerable amount of financial investment to rewrite the whole content to the new format, requiring engineers with knowledge in both the older hardware and on the newer hardware, in a manner that it's possible to recreate the software. However, it's not just expensive and hard to do, the new software will not be 100% identical to the original because of the peculiar and unique features of each hardware, the audio, video and human interface devices (HID) will be different from the older to the newer device.

Additionally, the hardware may have hundreds or thousands of software written for it and because of the points mentioned above, only a small fraction of the software would end up indeed migrated to a newer hardware. This is a risk because a huge library of games will eventually become impossible to be played in the case the hardware required for running becomes obsolete (not possible to obtain or gets too much expensive to obtain) or stops working completely because of the limited lifetime.

Figure 4 – Picture of various video game cartridges, focused on the Super Nintendo cartridges. Dozens of games that can render unplayable in case there's no concern about preserving both the software and the hardware used for playing the games (Near, 2020).

Another problem that must be highlighted is that a lot of software (not only games) end up being completely abandoned by the company that owns the copyright rights. Regardless of the reasons, like bankruptcy, commercial disinterest, lack of expertise or even part of its strategy, a lot of software created in the past will never be migrated to a newer platform. Known as Abandonware, the term is frequently used in forums in discussions about certain software that were completely abandoned by the copyright owner or even there's absolutely no idea who owns the rights to a certain software (Bernadette J, 2015).

With all of the concerns mentioned above, it's clear that unlike audio and video content, software, specially games, are way more vulnerable to the time because of the progressive hardware degradation. It's a risk to thousands software ends up eradicated if there's no effective way of preserving the software.

Although it's not a complex problem to preserve the software's contents (data) to a digital format, only having the access to the contents is not enough for warranting that the software will be preserved, given that the data is strongly tied to the hardware that the software was designed and compiled to, therefore it's required to not only find a way to preserve the software contents, but also find an effective way to preserve the hardware used in a manner that the software can be executed once again.

As discussed previously, a hardware will eventually become obsolete and the price for keeping the hardware commercially can end up becoming not viable, creating commercial disinterest. Therefore, given the complexity of keeping a production in the long run of a hardware, the emulators are an alternative and an effective solution for resolving the software and hardware preservation problem.

3 What are emulators?

According the Koninklijke Bibliotheek (2007), emulation is the imitation of a certain computer platform or program inside another platform that was not originally designed for. An emulator allows to view documents or to execute programs on a computer decide that has no compatibility, either in hardware (such as different architecture) or software (such as an operating system).

A software is developed keeping in mind a certain architecture. We write software code using a programming language that through a compiler it generates a binary file that contains the instructions to run the software. The instructions are build using a machine language which depends of a certain architecture and processor for its correct execution.

Given that, we can notice that there is a dependency between the software (the binary contents with its instructions) and the hardware (which has a processor and a specific architecture with different components). Both must be compatible with each other to make sure the software will run correctly. In addition, there might be more resources that is required for the correct execution, such as co-processors (graphics cards, sound card, interfaces, etc.) and intermediate software (BIOS, firmware, operating systems, kernel, drivers, etc.).

We can imagine an emulator being an intermediate layer between the software that was made using a specific architecture and the hardware where the emulator is being executed. Even if the hardware, operating system or any other intermediate layer is completely different, the software will be able to run normally: the instructions are decoded and processed correctly, the system calls works as expected and the software is behaving as expected. At practice, the software will keep running like if it was running on the original environment that it was set up for, without any interference on its performance.

Figure 5 – Example of diagram where it shows a software made to the SNES (Super Nintendo) being executed on a architecture different then the SNES (Intel x86).

An emulator therefore works as a component where it allows to you run a software even if you don't have the hardware that the software was originally designed for. It's also possible to use an emulator to replace other components such as BIOS, interfaces and operating systems that might be not available and is a blocker for running the software. If everything is configured correctly (specially contracts), all specific features of the emulated software will work as expected, including features such as support for specific file format or an interactive experience, such as video-game console.

Figure 6 – Windows 2000 running on Windows XP, through emulation (Koninklijke Bibliotheek, 2007).

The emulators are therefore used to revisit a software that depends on a hardware that is not available. We can use as an example a hardware that has become obsolete and there is no more units available, a hardware that is not working correctly due of technological limitations such as a hardware that only works on a CRT TV and the user only has a more recent TV that works under another technology, we can also mention a hardware that for some reason is malfunctioning and a hardware that is no longer being produced for budget or technological restrictions. In addition, emulators can also be used during the development process of a new software, which is possible to test and validate certain software features directly from the development environment faster and easier compared to the target hardware, since emulators can be modified to intentionally change a software intermediate state, debug or apply automated testing to a certain algorithm.

When a hardware becomes obsolete, although it's still commercially viable, an emulator can be an interesting option to reduce production costs since it allows to use a simplified or cheaper architecture. The mini Super Famicom is an example of this scenario. It's a system that emulates the Super Nintendo hardware and was officially released by Nintendo in 2017.

Figure 7 – Picture of the mini Super Famicom (Super Nintendo) box, released by Nintendo in 2017 (Sam B, 2017).

The device comes with the 32-bit ARM Cortex-A7 processor that has a completely different architecture from the 16-bit Ricoh 65C816, which uses an emulator to run SNES games, already built-in on the device internal memory, allowing to you use the device without having to rely on cartridges. Therefore, emulators aren't just an option used by researches and collectors, emulators is also an interesting option for companies that want to keep using a system that (its hardware) has become obsolete and hard to produce again.

3.1 Differences between emulation and simulation

Along emulation, another term common in computing is the emulation. A simulator is a software that, through mathematical models, has the objective of approaching a behavior of a phenomenon (Eric W, 2013). An example of use is the atmosphere simulation that has the objective of understanding and predicting the atmospheric behavior given a time-span (days, weeks or months), allowing to forecast where and how a tornado, cold front or a heat wave can occur on a certain place.

It's expected a certain degree of abstraction during the simulation. Depending of the simulation objective, you can abstain from certain parameters or condition to the simulation occur as fast as possible. There's situation that is needed to simulate many days in a few seconds, which can make the process nonviable if there's too many factors and variables to take in account. We can imagine software simulation as an objective process, which we take the most important aspects and make some assumptions using mathematical models to make an experiment at laboratory level.

Simulation is not restricted to natural phenomenons. During the hardware design process, simulation is used to validate the hardware behavior, functionally-wise of a certain hardware description before proceeding to the next steps. Because hardware design is often a slow and costly process, the hardware simulation is a mechanism that helps finding out possible design flaws or undefined behavior that can affect the project development cycle. However, a successful simulation doesn't mean that the hardware description will work on the final hardware, therefore the simulation doesn't warrant that the simulation result will be the same as real result, but it allows to find failures before getting the real tests done, saving time and resources.

Although it's not a requirement, we expect emulators to behave as close as possible or exactly equal compared to the hardware. In other words, given a set of inputs, the emulator should give the same output just like the original hardware. The software being emulated shouldn't be able to notice any differences when running in an emulator or in a hardware, nor should be able to detect if it's running inside an emulator, otherwise the emulator will not be considered enough accurate to emulate the system. Of course, there's a few things to consider on how close an emulator can even behave compared to the original system that will be detailed on the next chapters, but assume that an emulator will always have the accuracy as one of its requisites.

Software simulators and software emulators are therefore different, given that simulation doesn't have the objective of getting the exact behavior of a phenomenon, since it involves a lot of complex or unknown factors that can impact the simulation result. Simulation often have to discard certain parameters to ensure that the simulation can occur in the required time-span. Emulators, on the other side, are meant to emulate computer platforms, which usually has well known parameters and behavior, and you has the accuracy as one of the requisites for making sure the software that is getting emulated can work as expected (including bugs and failures) just like on the target system, even if that requires a way more powerful computer compared to the target system.

4 Hardware preservation and its relation with software

As previously mentioned, a software, when compiled, an executable binary file is generated, where it contains instructions for running the program. The binary content is a file, that contains data, that can be stored digitally and can be replicated and copied many times. Therefore, software content itself, as a digital format, can be easily preserved using good storage practices, such as durable storage devices and regular backup procedures. However, this only applies to digitally distributed software where the consumer can download the software.

Until recently, most of the software were exclusively distributed through physical medias. Examples include: floppy disks, CDs, DVDs, cartridges, and others. Although some types of physical media are compatible with most computers (such as CDs and DVDs), in terms of preservation, the use of physical media can be a risk, since even if an emulator can faithfully reproduce a system, if the media on which the software is stored (and emulated) eventually fails, it will no longer be possible to use the software on the designated system, not even on the emulator. It's also worth noting that with the continuous improvement of technology, the types of physical media are also changing, and it is now common to find computers without disk drives, for example. Therefore, it's necessary to find ways to preserve the software digitally without relying on the physical medias.

The medias has the purpose of storing data, so using a reader or dumper (copier) that is capable of reading and validating the integrity of the data is more than enough to preserve a software on physical media. Since most of the programs are released in the thousands (or millions) of media, it's possible to read several of them, ensuring that the data is correct, since if any media has corrupted data, it's possible to detect it by comparing with the readings made with other media.

Figure 8 – The Mash Mods Retro Flash Cart, a dumper used to copy the game Stanley Cup do Super Nintendo (Evan G, 2010).

Personal note: Curiously, I have the "Standley Cup" cartridge, but for some reason it has Samurai Shodown stored instead. I wonder what happened with this cartridge to have a completely unrelated game inside it... At least I had so much fun with Samurai Shodown when I was a kid. But what if I had the only Standley Cup copy? The original contents would be gone forever...

However, there are some caveats. The first one is the versioning – since most of the physical media is read-only, that is, it can only be written once, development teams often encounter software flaws (bugs) that require them to release a new version of the software with the fixes and improvements. Because of that, it's not uncommon to find media with different versions of software. The preservation process needs to pay attention to this detail and correctly catalog all versions available on the market. The second caveat is the fact that some types of media not only store software data but also provides additional hardware, which usually are additional resources required to the software run correctly. Depending on this additional hardware, it may be necessary to adapt the emulator to be able to run the software correctly due to the additional hardware.

4.1 Physical media with additional hardware

As previously mentioned, a program can be distributed through digital media and physical media. In the case of physical media, we need to make sure that the media will be digitally preserved, due to the limited lifespan of physical media. However, there are physical media that doesn't have just the storage unit – used to store the program's content. This media may include additional hardware that is necessary to the program run correctly.

Figura 9 – Super Nintendo cartridge, which along the storage (U1, Mask ROM), it has additional memory (U2, SRAM), a RISC co-processor (U3, MARIO CHIP/Super FX), a SRAM controller (U4, 74LS139) and an IC responsible for the region lock (U5, CIC), of the Star Fox game (Near).

These additional chips can perform various functions, depending on the software included in the cartridge. For the Super Nintendo case, the chips are mainly used to add functionality that the console doesn't have, such as 3D processing capability. A good example of this is the game Star Fox, released in 1993, which features a chip based on the RISC architecture called as MARIO chip (Mathematical, Argonaut, Rotation, & Input/Output), with a 10.74 MHz clock, responsible for accelerating the game's processing and performing 3D rendering, a feature that didn't exist in the console, at least not in the way we used to see (Lucas R, 2017).

In the case of Star Fox, we can clearly see that the chip included with the cartridge, despite not storing any data, performs a critical job in the game, and without the chip, it's not possible to even boot up the title screen. Therefore, when we think about preserving software digitally, it is also essential to preserve the chip so that it's possible to execute the software later. However, since the chip does not have any code (firmware) and is an integrated circuit made with transistors, it's necessary to reverse engineer it and create a specific emulator that emulates the chip so that it will be possible to play the software in question.

Figura 10 – Picture of the Star Fox game (Lucas R, 2017).

Near (2011) mentions this unique characteristic of cartridges with additional chips and the number of possibilities that this allowed for the Super Nintendo, "literally plugging a printed circuit board (PCB) into its system", which could vary from adding co-processors (such as the Super FX), digital signal processors (DSP series or the CX4), and even clocks (RTC, the real-time clock), resources that the software can use for any purpose. Due to the presence of these additional chips, emulation has become an interesting challenge, as some of them are completely unknown, without any documentation or datasheet available.

In 2020, Near commented that the emulation of these chips has only become viable after investing thousands of dollars, either by reverse engineering the instruction set or by decapping the chips to visualize the transistors or to extract the firmware inside the chip. Therefore, it is a great challenge to deal with cartridges with specialized chips, which are not only more expensive for consumers but also more expensive to reverse engineer, as many of them are used in only a few games and have almost no documentation available.

A viable alternative, and pretty much the only available one in the early 2000s, was the high-level emulation (HLE) of these chips. Without caring about the peculiarities and the timing of these chips, emulators focused on only providing an approximate functionality of the chip so that these few games would work without visible defects for anyone playing them. However, as small details were lost, this technique often introduced bugs and failures that did not exist in the original software, being therefore emulation bugs, often bringing a negative experience for those who played through emulators and a concern for developers who wanted to develop new software through emulators, which could risk using resources that would only work correctly in the emulator or only in the original hardware.

Personal note: we're constantly under risk of accidentally creating a ROM hack or a game not for the SNES, but for a SNES emulator. We need to constantly battle against poor practices that places a risk the legacy to the Super Nintendo system and specially, Near's effort made to bsnes.

There are cases where even high-level emulation is not possible. The game 早指し二段森田将棋２ (Hayazashi Nidan Morita Shougi 2) for Super Nintendo, released only in Japan, uses a co-processor called ST018. For decades, no emulator was able to run this game because the co-processor, responsible for the game's AI (artificial intelligence), was completely unknown, without any reference or information available, performing a critical function of the game which is the decision-making process, where it was not possible to emulate at a high level without knowing exactly how the decisions or business rules were made. Thus, for a long time, a single Super Nintendo game was unplayable on an emulator.

Figure 11 – Hayazashi Nidan Morita Shougi 2 cartridge board for Super Nintendo. Highlighting the ST018 chip on the right, which was responsible for the game's AI (JohnDie).

Near found out that in 2012, after extracting the firmware with the instructions inside the co-processor, that the ST018 chip was a 32-bit ARMv3 CPU, with a speed of 21.47 MHz, and after implementing the chip in the BSNES emulator, it was possible to emulate all commercially released games for the Super Nintendo. BSNES remains the only emulator that is able to emulate all the approximately 3,500 games ever released (Near, 2020).

4.2 Software with custom peripheral

From a software viewpoint, a peripheral works like a data input, a sensor that helps the system produce outputs. In a video game, we can imagine a peripheral being a joypad, mouse, or keyboard, for example. Given that, there are software programs that use peripherals with certain peculiarities that make the experience completely different, allowing the user to have an interaction that wouldn't be possible with the use of the most common peripherals.

Figure 12 – Picture of the Super Nintendo console (Near, 2011).

Using once again the Super Nintendo as an example, the console has input for two controllers. The communication protocol between the console and the standard controller (joypad) is straightforward and a hardware routine executed 60 times per second automatically scans the buttons being currently pressed. However, four of the seven pins (Anomie, 2019) of the console's input can be accessed directly by the SNES's main processor, making it possible to use these pins freely, developing any other peripheral that uses these pins.

The most common was to use the pins to read more than 2 controllers. Using a device commercially known as the Super Multitap, some games were able to increase the maximum number of controllers possible from two to five, allowing more people to play the video game at the same time. It was initially released alongside the Super Bomberman game (Aurerio, 2012).

Personal note: And today we know that we can play up to eight players at the same time if you plug the Super Multitap on both controller ports :)

Figure 13 – The Super Multitap accessory, developed by Hudson Soft (Aurerio, 2012).

To emulate the multitap, the challenge was to understand how the accessory worked. Since it's a relatively simple peripheral, the reverse engineering process was focused on understanding the multitap protocol, which was essentially a controller (joypad) multiplexer, and reproducing the same behavior in the emulator, where a high-level emulation is enough for this particular case. Virtually all Super Nintendo emulators support multitap, and to activate it, simply add more controllers, and the accessory is activated transparently (for the most cases).

As one can imagine, with the degree of freedom that the control pins offer, several other games were released that came with their own peripherals, often difficult to acquire due to the small number of units available. Among the various peripherals released, one in particular stands out due to the challenge of using it nowadays: The Super Scope, released by Nintendo in 1992 for various games.

Figure 14 – Picture of the Super Scope, a peripheral that simulates a "bazooka" for the Super Nintendo (Evan G, 2016).

The Super Scope came with the objective of enabling an immersive experience in first or third-person shooter games. Being one of the first wireless video game accessory, the Super Scope doesn't connect directly to the Super Nintendo. A receiver is connected to the console's second port, which communicates wirelessly with the Super Scope. The peripheral, not being powered by the console itself, requires six batteries to work (Evan G, 2016).

Functionally speaking, the Super Scope, being held by the user, captures the coordinates of the screen where the user is aiming at on the TV and sends the coordinates to the console along with the information if the trigger button is being pressed at that moment or not. The software then receives this information directly from the Super Nintendo's registers and performs the actions according to the received information (input).

Internally, however, the Super Scope is quite complex. The peripheral has a sensor that is sensitive to the photons emitted by the CRT TV. During the rasterization process of the screen, the Super Nintendo graphics chip continuously tracks the scanning position of the TV, point by point, and according to the position, the SNES chip sends which color the pixel position will be displayed on the TV. This process is done for all the horizontal dots of the TV and repeated again until all the TV lines (scanlines) are finished, about 60 times per second. During the refresh process, where all the dots are invalidated, the Super Scope starts tracking the drawing process until it detects the exact moment the pixel is drawn on the screen. When the pixel is drawn, the accessory triggers a latch in one of the controller pins, which sends a command to the graphics chip requesting the coordinates at the instant the drawing is being made.

Figure 15 – Yoshi's Safari, released for the Super Nintendo, uses the Super Scope as the main controller (Evan G, 2016).

In addition to the technical complexity, the method does not work perfectly because it depends on the brightness of the photons from the CRT television, and due to physical characteristics of the TV, the Super Scope has difficulty in identifying red pixels and depending on the TV model, the accessory often takes an incorrect position on the screen. To make it worse, because it works with the characteristics of the CRT television, the Super Scope is not compatible with other types of television.

Personal note: I was shocked when I learned that the Super Scope only works with CRT TVs. It might sound obvious at the beginning since it relies on reading the photons from the CRT, but if you think in the long term, there's a serious risk of CRT TVs simply disappearing, making all these SNES games unplayable with the original Super Scope.

Figure 16 – Yoshi's Safari, unlike most Mario games (and its own title screen), has more neutral and washed colors to make it easier to Super Scope detect the pixels (Evan G, 2016).

This is a case where hardware preservation plays an important role. Such accessory is unlikely to be used nowadays if the person doesn't have all required setup and often the use of an emulator will simplify the experience by emulating the accessory at high level, allowing the user to simply use another type of accessory that informs the coordinates. It won't be exactly the same gaming experience, but it will undoubtedly work even better compared to the original hardware. And without emulation, there's a risk that all these games becoming unusable without the accessory properly being emulated.

Note to the reader

This is the part 1 of the monography. The part 2 will focus on methods and challenges of the emulation and reverse engineering. The bibliography below refers to the whole monography. Please also note that the bibliography format is under the standard used for Brazil, which may look odd for non-Brazilian readers.

The bibliography format used is: <Author name> <Article title in bold> [Location or book reference, if available] <URL of the resource> <Access date>.

BIBLIOGRAPHY

Andreas L. Discovering New Paths Playing Old Games. Bibliotheksdienst, vol. 54, no. 5, 2020, pp. 313-344. Available at: <https://www.degruyter.com/document/doi/10.1515/bd-2020-0044/html>. Acesso em: 27 nov. 2022.

Anomie. Schematics, Ports, and Pinouts. Available at: <https://wiki.superfamicom.org/schematics-ports-and-pinouts>. Acesso em: 3 dez. 2022.

Aurerio. Plug and Blast: Super Multitap. Available at: <https://www.nintendoblast.com.br/2012/04/plug-and-blast-super-multitap.html>. Acesso em: 3 dez. 2022.

Bernadette J. How Abandonware Works. Available at: <https://computer.howstuffworks.com/abandonware.htm>. Acesso em: 1 dez. 2022.

Eric G. From Floppies to Solid State: The Evolution of PC Storage Media. Available at: <https://www.pcmag.com/news/the-evolution-of-pc-storage-media>. Acesso em: 30 nov. 2022.

Eric W. Computer Simulations in Science. The Stanford Encyclopedia of Philosophy. Available at: <https://plato.stanford.edu/archives/sum2013/entries/simulations-science/>. Acesso em: 27 nov. 2022.

Evan G. Mash Mods SNES Retro Flash Programmer/Retro Flash Cart. Canadá. Available at: <https://snescentral.com/article.php?id=0993>. Acesso em: 1 dez. 2022.

Evan G. SNES Chip List. Available at: <https://snescentral.com/chiplisting.php>. Acesso em: 1 dez. 2022.

Evan G. Star Fox. Available at: <https://snescentral.com/article.php?id=0636>. Acesso em: 3 dez. 2022.

Evan G. State of SNES Emulation - 2010. Available at: <https://snescentral.com/article.php?id=0995>. Acesso em: 30 nov. 2022.

Evan G. Super NES Technical Specifications. Available at: <https://snescentral.com/article.php?id=0088>. Acesso em: 1 dez. 2022.

Evan G. Super Scope. Available at: <https://snescentral.com/article.php?id=0017>. Acesso em: 3 dez. 2022.

Jeffrey H. Emulation for Digital Preservation in Practice: The Results. The National Library of the Netherlands, Holanda. Available at: < http://www.ijdc.net/article/view/50>. Acesso em: 27 nov. 2022.

John E. The internal workings of video game consoles: The GameBoy. Mälardalen University, Suécia. Available at: <https://www.diva-portal.org/smash/get/diva2:433485/FULLTEXT01.pdf>. Acesso em: 27 nov. 2022.

John McMaster. s-ppu1-5c77-01. Available at: <http://www.siliconpr0n.org/map/nintendo/s-ppu1-5c77-01/>. Acesso em: 4 dez. 2022.

John McMaster. s-ppu2-5c78-01. Available at: <http://www.siliconpr0n.org/map/nintendo/s-ppu2-5c78-01/>. Acesso em: 4 dez. 2022.

John. How to Write a Basic Verilog Testbench. Available at: <https://fpgatutorial.com/how-to-write-a-basic-verilog-testbench/>. Acesso em: 3 dez. 2022.

Koninklijke Bibliotheek. What is emulation? Available at: < https://web.archive.org/web/20110908070810/http://www.kb.nl:80/hrd/dd/dd_projecten/projecten_emulatiewatis-en.html>. Acesso em: 27 nov. 2022

Lucas R. Star Fox (SNES) e o Super FX. Available at: <https://jogoveio.com.br/starfox/>. Acesso em: 3 dez. 2022.

Near. 2011-02-28 - Why Accuracy Matters. Available at: <https://helmet.kafuka.org/accuracy/>. Acesso em: 3 dez. 2022.

Near. Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator. Available at: <https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/>. Acesso em: 1 dez. 2022.

Near. How SNES emulators got a few pixels from complete perfection. Available at: <https://arstechnica.com/gaming/2021/06/how-snes-emulators-got-a-few-pixels-from-complete-perfection/>. Acesso em: 1 dez. 2022.

Near. SHVC-1C0N5S-01. Available at: <https://snescentral.com/pcbboards.php?chip=SHVC-1C0N5S-01>. Acesso em: 1 dez. 2022.

Neil P. The 6502/65C02/65C816 Instruction Set Decoded. Available at: <https://llx.com/Neil/a2/opcodes.html>. Acesso em: 2 dez. 2022.

Sam B. Nintendo announces mini Super Famicom for Japan. Available at: <https://www.theverge.com/2017/6/26/15878004/nintendo-super-famicom-mini-japan-price-release>. Acesso em: 2 dez. 2022.

Stewart Granger. Emulation as a Digital Preservation Strategy. University of Leeds, Reino Unido. Available at: <http://www.dlib.org/dlib/october00/granger/10granger.html>. Acesso em: 27 nov. 2022.

UTMEL. The Evolution History of Storage Devices. Available at: <https://www.utmel.com/blog/categories/memory%20chip/the-evolution-history-of-storage-devices>. Acesso em: 2 dez. 2022.