Emulation: between physical reality and empiricism

PREFACE

In this space we will explore the emulation world, it will be a journey through the time and to appreciate its details we will use the technical documentation available at the time of the emulated systems. We will discuss this topic with the purpose to encourage people to deepen the systems knowledge that today aren’t very present on the market or that aren’t available to the public or although available they aren’t available for use because they are kept in museums or public/private exhibitions other forms.

The emulation is a fairly controversial subject in copyright terms, until twenty years ago the emulators developers were subject to legal actions in an “almost” systematic way for copyright infringement. Over the years the emulation perception of has changed, the rights owners continue be to but some exceptions are defined according to the Countries in such a way as not to damage the rights holders economic interests and at the same time distribute and use emulators that have the value of keeping alive the cultural heritage of systems that are destined to disappear or no longer operate.

The change in the copyright rights perception in general has led to the Internet Archive creation, a no-profit organization located in the United States officially approved and born with the aim of preserving all digital contents and giving free access for educational purposes to researchers, historians, scholars, students and the public in general. Rights holders at any time can request partial or total contents removal present in the archive. Moreover since the 90s the Bitsavers collective was involved in the documentation and materials related to computers scanning and in saving software from rapidly obsolescent media. Designed as a permanent and freely accessible collection of manuals, technical specifications and knowledge of trademarks and computer related materials the collection now hosts thousands of documents containing millions of pages. These two information sources together with others will accompany us during this journey.

EMULATE OR SIMULATE, THIS IS THE PROBLEM.

In the network there are software mentioned as emulators and/or simulators, but

  • what are the simulation and the emulation ?
  • What is the difference between the two and from what perspective?
  • Is the simulation or the emulation better ?

Without the claim to give axiomatic answers we start from the natural meaning of simulating as “pretend to” and emulate as “imitate something” and we try to adapt them to electronics starting from simple systems and then extending the concept to more complex systems.

To try to answer our questions we can start from the console technological evolution. The first generation (1972-1976) has as its ancestor the Magnavox Odyssey console (Fig.1) designed by Ralph Baer who for the first time he transforms the TV into an interactive device.

Emulazione e Console

Fig.1 – Magnavox Odyssey console, 1972. “Smithsonian National Museum of American History”
Fig.2 – Schematics (Extract from) “Magnavox Odyssey series Service Manuals & Game Manuals”

Let’s start thinking about how to develop a software that is the most faithful to the console functioning: as you can see in the small extract from the console schematics (Fig.2) and in general as for all the consoles of its generation is build with discrete components such as resistors, capacitors, diodes, transistors, inductors and any integrated circuits (ICs) that contains the above mentioned miniaturized circuit elements. All these components are characterized by nominal physical properties and real circuit properties that are dependent from the production process and are known by the manufacturers. By means of this information, whether it’s accessible, it would be possible to develop software that simulates the behaviour of all the circuital components and their connections. A concrete example is the electronic modeling simulator pSpice.
Another solution is to observe the games console functioning and empirically create a software that behaves in the same way without knowing the console technical details or more accurately that emulates the circuits behavior or part of them.

Lets see the advantages and disadvantages of these two approaches to the problem:

  • Simulation: this would be a great solution if it weren’t for the fact that it needs a huge computing speed to simulate all the console electrical components and achieve a real time behavior as the console. The maximum limit to the console faithfulness is the system modeling software and the information about the electrical components real properties.

  • Emulation: what you can emulate is at most what you can observe. Only by recording all the possible game events from which to extrapolate the working rules it’s possible to create a software that reproduces the console behaviour. More simple the game and its rules are and more easy is to achieve a faithful console emulation. A more accurate emulation could be obtained from the analog/digital circuits study, but it’s a very complicated work and the emulation is heavier from the computational viewpoint. A simple game doesn’t match necessarily a console hardware simplicity and the game analysis difficulty is related to the fact that the on the screen elements and the game logic are “spread” in the hardware and vary according to how the electronic circuits are activated in the game: for example in Fig.1 there is either the variable resistor R51 which is used to change the “ball speed” (BALL SPEED) which varies with the resistance value, or the variable resistor R55 which determines the “wall on the left” position (LEFT WALL). From these two very simple “static” details it’s already clear how difficult it’s to create a console faithful emulation that derives from the game observation and/or from the console hardware characteristics study.

With the cheap microcontrollers availability was born the consoles second generation (1976-1984). This new generation is marked by the new electronic component called microcontroller which upsets and simplifies the console hardware structure: the game elements and logic are no longer “spread” in the console electronic board discrete components but are concentrated in an integrated circuit as firmware ie programmable instructions executed by the microcontroller. This frees the game programmer from the console physical complexity and then finally they can start designing totally different games, both as objects on the screen and as game logic without modifying the console hardware. Through gradual transformations associated to the microcontrollers progress, the consoles start showing more similar characteristics to the present ones moving to the software functionalities that were previously hardware oriented. Magnavox uses the 8048 intel microcontroller for the new Magnavox Odyssey2 console (sold in Europe as Philips Videopac). For the player it doesn’t change much but for the consoles it’s a turnpoint: now a console has the Eniac computing power, the first general purpose computer in the history from 1946. The Eniac takes up hundreds of cubic metres, weighs a few tons and uses 18,000 thermoionic valves that absorb 150 kW to perform a sum in 200 microseconds. All this computing power is concentrated into the Intel 8048 into 7 cubic centimeters, weighs 30 grams and uses 5000 transistors that absorb 1.5 W to perform a sum at the same time. I would say that it is one of the first microcontrollers to be awarded with the title of “green” device with a reduced power consumption of 100000 times!

Let’s see what are this revolution consequences in simulation/emulation matter:

  • Simulation: the simulation developing idea is moving further away, the board electronic parts are reduced but a this period microcontroller already includes about 5000 transistors. To have a real difficulty in the console simulation overview for those who have experience in designing using microcontrollers you just need to read the Intel 8048 technical specifications (Chapter 6): to obtain a console realtime simulation is necessary that all the timings required by the technical specifications are satisfied otherwise the simulation simply doesn’t work, it’s a problem of both circuit modeling and circuit elements number and technological details copyrighted but the first problem part it’s already sufficient to make the enterprise unsuitable.

  • Emulation: while the previous console generation circuits can be analyzed by an oscilloscope and emulated more or less accurately now it’s no longer possible as everything is embedded in the silicon, but the microcontrollers add a new element: the firmware which is a instructions sequence executed by the microcontroller, roughly speaking it’s the microcontroller software. Each microcontroller is provided with a manual publicly released by the manufacturer where among the information required for the microcontroller use there are all the supported instructions: how they are identified, what they do, and their exact execution time. Now you have all the information about how the firmware works and the developing difficulty of an extremely accurate emulator is greatly simplified: unlike the consoles of first generation isn’t longer necessary to analyze the hardware to extract the information needed to emulate a game, you can even ignore, the relevant factor is to emulate accurately the firmware instructions execution. To emulate a game you therefore need to have the firmware, but it’s copyright protected and owned by the producer. The firmware commonly referred to as “ROM” is really the extracted code from the physical ROM (Read Only Memory) chip.

We can say that hardware simulation would be the best solution in theory, but it’s strongly limited by technicalities and copyright reasons put on technological solutions. Incidentally, no IC manufacturer is interested in creating a public simulator whose reverse engineering would reveal the technical solutions adopted. Instead the emulation gives excellent results, it’s usually free, open source and at high educational value.

Although the emulation world seems to be monopolized by the well-knowns, really there are still wide unexplored and less explored possibilities of high-level emulation for the 70/80s systems even of global popularity. For this advanced emulation two developers have published their results: Alessandro Scotti and “Adam”. The system emulation between the 50s and 70s it’s dealt by university centers that have at their disposal the systems, the technical documentation and the use skills. These systems with unfriendly interfaces already have innovative content that you would never have imagined and that when you discover them the current game systems will seem to you the wheel reinvention.

TICKLE

Tickle Logo

Fig.1 – Tickle Emulator v0.94
Fig.2 – Unknown Space Invaders bug revealed (Shot 1)
Fig.3 – Unknown Space Invaders bug revealed (Shot 2)

Alessandro Scotti is a developer who has focused his attention on discrete components emulation. Not just developed these emulators but also provided the source code and documented the path he followed for the development thus creating an excellent tutorial: to develop an emulator it’s important to know how to interpret the schematics, be able to identify the logic blocks and their function, know how to work with circuits equipped with operational amplifiers, to know the C++ language and have a good intuition helps a lot in this project.
Out of curiosity I launched the emulator “Tickle Rebound” (he runs in “attract” mode”) that emulates the “Rebound” electronics a volleyball game similar to the historic Pong. Unlike the original 700 MHz Athlon despite using an AMD Phoenom II X6 @2.8GHz this game is still extremely slow. It could be recompiled for the new CPUs but the project to date is closed.
Another cup of tea, but not the only, of this talented developer is the Space Invaders (1978) sound emulation. In this case the game is equipped with an Intel 8080 at 2 Mhz and the sound system is analog/digital. All the most famous emulators use the sampled sounds from the original game, instead Tickle emulates the hardware that generates them and doesn’t need the sampled sounds. The emulation speed is not limited in any way. This emulating analog/digital electronics advanced way that seems so perfectly deterministic really isn’t such and it was necessary to find reasoned empirical solutions. Everything is very well detailed in the interesting reading section “Space Invaders sound emulation”.
The Tickle version that perfectly emulates all Space Invaders sounds is the 0.94 dated 2011. This version was available without source code for a while and although this version isn’t present on the official website anymore you can find it in some websites focusing on emulation.
A short personal anecdote: in 1980 playing Space Invaders at the bar I tried to let alone one of the largest aliens and I was amazed to discover that this running left a “trail” (Fig.2) and then falling down ended the game for “invasion” (Fig.3). It’s superfluous to say that I felt very disappointed! After 38 years by the Tickle emulator I tried to repeat that game sequence and I can say that the emulation is perfect with the exact bug replica.

D.I.C.E.

DICE Logo

Fig.1 – D.I.C.E Emulator v0.9
Fig.2 – Rebound
Fig.3 – PONG

D.I.C.E. (Discrete Integrated Circuit Emulator) is an electronic systems without CPU emulator containing just the discrete components. The author of this emulator is “Adam” and is uncertain if he is a talented developer or a developer group. This emulator sometimes can also be slow but there are games where the speed is excellent and the sounds are emulated. D.I.C.E. emulates the legendary PONG without problems and as Tickle it supports the game Rebound, in this case with my Phenom II he runs at 60 fps without problems. The emulator is freeware, open source and the sources are available to the public. Unfortunately isn’t provided a tutorial or in-depth development documents. The latest version is the 0.9 and dates back 4 years.

In my opinion I think that in the light of today CPUs the emulation instead of integrating more and more systems or the same game variants into the emulators could follow the path indicated by these two emulators also aiming at a better emulation quality in an attempt to preserve more faithfully the original systems especially with respect to older systems that sometimes seem to be the most forgotten. For those who have enjoyed the 70/80s age systems the emulation takes a connotation that extends beyond historical preservation, it’s a way to remember the time spent with friends, the challenges at home, the queues in game room or in the bar, the disputes, the game records in which also the addition of a handful of colors on the screen wowed the people out of the measure. As the replicant Roy Batty says in Blade Runner “… and all those moments will be lost in time, like tears in rain” … luckily there are emulators that help us remember !

eNJoy aND STay TuNeD WiTH uS!

Raffaele “MOS” Sanapo

This is an article for educational purposes and the information is provided “as is as”. The links to content on third party websites are provided for information purposes. There is no control over and no responsibility is assumed for the content or third-party websites that are linked. All product names, schematics, logos and trademarks are the property of their respective owners. The use of these doesn’t imply the approval thereof.

Raffaele Sanapo

“We don't stop playing because we grow old; we grow old because we stop playing.” (George Bernard Shaw)

Share
Share

Utilizzando il sito, accetti l'utilizzo dei cookie da parte nostra. maggiori informazioni

Questo sito utilizza i cookie per fornire la migliore esperienza di navigazione possibile. Continuando a utilizzare questo sito senza modificare le impostazioni dei cookie, cliccando su "Accetta" o continuando la navigazione permetti il loro utilizzo.

Chiudi