Emulation: Right or Wrong?
aka "The EmuFAQ"
copyright (c) 1999 Sam Pettus (aka "the Scribe"), all rights reserved
Questions? Comments? Praise? Flames?
Contact the Scribe!
Permission is hereby granted to reproduce this document
subject to the following terms:
All copies must not be altered in any way, including but not limited
to reformatting and conversion to alternate document formats, without the
express consent of the author. The sole exception is for necessary
formatting changes that may be
required to adapt this document to suit your particular needs; however,
the complete original text must be retained in as
close a layout to the original as possible. For any questions
in this regard, please contact the author.
No copy may be reproduced in whole or in part within a for-profit commercial
publication or Internet site without the
express consent of the author. The author recognizes the right
of said vendors to reproduce limited portions of his work
under the "fair use" clause of the appropriate sections of U.S.
copyright law and the international
Berne Copyright Convention.
Any trademark to be found within this document is the exclusive property
of its respective owner,
and is reproduced here merely for reference.
Module One: The Emulator
Part 3 - Releasing an Emulator
THE END OF AN ERA
28 January 1999 marked a significant event
in the world of videogame emulation. It was on that day that a team
of two hackers, known only by the aliases of Epsilion and RealityMan, released
- the world's first working emulator for the Nintendo 64 videogame console.
Many had tried over the previous year to devise an emulator for that system
and failed, whereas the one project that seemed to be making significant
progress (Project Unreality) was terminated due to threats of legal
action. Both Epsilion and RealityMan had been quietly working on
their own emulator during this time and decided that a new approach was
needed. Instead of starting with the console's base functions and
working upwards, they started with its high-level functions and worked
down (hence the name UltraHLE - Ultra High Level Emulator). They
also decided, in light of Nintendo's public attitude with regards to emulation,
that they would not tell anyone about their project until they felt it
was ready, and then make it available to as many people as they could in
the shortest amount of time.
The sudden and unexpected release of a working
N64 emulator caught the emulation and videogame communities completely
by surprise. A blindsided Nintendo quickly rushed to shut down the
UltraHLE website and threatened prosecution against the authors and anyone
carrying or supporting UltraHLE, but it was too late. Epsilion and
RealityMan's release tactics had ensured that UltraHLE would be spread
far and wide given the nature of the Internet, and a helpless Nintendo
could do little but watch as UltraHLE popped up on one site after another
in quick and rapid succession. N64 cart dumps had already been available
on the backwater sites for over a year, and now patrons of the "warez scene"
had something with which to play their bootleg videogames. UltraHLE
was by no means perfect, and only worked with about one-third of the "ROMs"
in existence at the time, but the fact that it worked at all what was upset
Nintendo the most.
Nintendo's next reaction was what those familiar
with its history might expect: it continued to threaten legal action
against anyone who supported UltraHLE, and filed suit against its authors
claiming that the emulator was an infringing work that promoted software
piracy. The threats were pure bluff and many sites called them on
it - those that weren't carrying any
bootleg N64 "ROMz," that is. As for the suit, it is still pending,
and the resultant legal pressures coupled with the instant popularity of
UltraHLE among the software pirates forced the premature retirement of
RealityMan from the emulation scene. Although the construction of
UltraHLE remains a closely guarded secret even to this day, Epsilion and
that it was an 100% reverse-engineered software-based emulator.
In the meantime, Nintendo's legendary intimidation tactics continue to
be employed against anybody who carries UltraHLE, but the sad truth is
that UltraHLE continues to be freely available and can be downloaded by
anybody with the will to find it. As a result, many feel that Nintendo's
ire towards the
emulation community will fall upon emulator developers as well as "ROM"
distributors from now on.
This incident caused some serious soul-searching
among the emulation community, as well as many a comment from the videogame
industry. Most were of the opinion that UltraHLE should not be supported
because it was designed to emulate a product that was very much alive and
kicking. The release of UltraHLE implied that the end-days of the
N64 were near, and nobody really believed that. On the other hand,
there were those who argued that they should not discriminate against a
legal emulator regardless of the status of the original system, and these
were the folks who continued to carry UltraHLE on their web sites while
the rest refused. The videogame community was equally split, with
many expressing admiration for the programmers and their accomplishment
and many calling for their prompt prosecution. The debate seems to
have died down after RealityMan announced his retirement from the emulation
scene, and not long after UltraHLE reappeared on just
about every single major emulation site. Those who had fought
its support before now felt justified in carrying it after Nintendo's failed
attempts to stop it; furthermore, they noted that there were several public-domain
"ROMs" available for it just as there were for other videogame emulators.
The availability of a legally downloadable software base for the emulator,
however limited and incompatible that might be, seemed enough justification
enough to many minds for supporting this remarkable program. As an
afterthought, it is ironic to note that Nintendo announced plans to release
a new videogame console (the N2000, codenamed Dolphin) not
long after the release of UltraHLE, so perhaps those who feared the console's
impending obsolesence may have been right after all.
In previous discussions, we have seen that
emulation is a valid use for a computer system; furthermore, that an unlicensed
emulator is possible once the intellectual property concerns are properly
addressed. The time has now come for the next important step:
the release of an unlicensed emulator.
In this and future discussions, I will refrain
from discussing pure hardware-based emulators, as well as the more common
varieties of hardware-software combinations. Pure hardware emulators
are almost always produced by original vendors or other companies under
license to the original vendor. Remember, the ability of the Sega
Genesis/MegaDrive to emulate a Sega Master System via VDP mode 4 was due
to Sega itself and installed as a desire to support its customer base for
the older platform. Sony is taking the same position with regards
to the announced release of its newer Playstation 2 console; they
are planning the inclusion of a special I/O chip that will permit
the playing of older Playstation titles on the new system. This is
a practice that is universally accepted within the industry; furthermore,
hardware-based emulators are quite profitable to the original vendor due
to the proprietary nature of such. It would be almost impossible
to build a pure hardware emulator without the consent of the original vendor,
and the laws are quite clear with regards to the illegality of unlicensed
clone products. Just ask all of the folks who tried to manufacture
unlicensed clones of the NES and see where it landed them.
A hardware-software combination is a different
animal altogether, and their very nature tends to blur the legal lines
somewhat. For example, Commodore's cross-licensing agreements with
various PC clone manufacturers gave them solid legal ground upon which
to base their PC Bridgeboard product for their Amiga computer systems.
The same could be said of A-Max, as its only vendor-produced requirement
was the original Macintosh BIOS which had to be obtained through legal
means, and the courts ruled that this was acceptable. Jump forward
in time to the present, where hardware-software combos have taken a new
twist - the requirement of a BIOS dump, which is nothing more than
a software image of the computer code contained within the BIOS of the
original system. Remember the A-Max bootleg? It's the same
thing, but almost a decade later. I will reserve the discussion of
the legality of this practice for another time, but will note in passing
that such emulators have become widespread. For example, Cloanto
of Italy sells a package desgined expressly for users of the WinUAE Amiga
emulator. It provides a legal copy of the AmigaDOS software, along
with a legally licensed copy of the Amiga Kickstart ROM (the system BIOS,
in other words). True hardware-software combos are becoming more
rare with each passing day due to the incredible advances in computer processing
capability, and the time will no doubt come when their existence will be
limited to providing emulation for highly specialized niche systems that
have a minimal impact at best upon the computer industry.
EMULATION AND REVERSE ENGINEERING
It goes without saying that a pure software-based
emulator should be comprised entirely of reverse-engineered code before
you release it to the world. This neatly avoids any legal claim
that the original vendor can mount against you in this regard, such as
what happened between Intel and AMD over the Am80386. The courts
have ruled time and again that reverse engineering does not void copyright
protection, as it does not replicate the original's "defining algorithims."
A program written entirely in 100% reverse-engineered code is therefore
legal, so it stands to reason that any emulator that is 100% reverse-engineered
should also be legal. This is the stance that the makers of the bleem!
Playstation emulator are pursuing as part of their defense in their current
legal dispute with Sony, and there is little doubt within the minds of
almost everybody within the computer and videogame industries that Sony
will lose that particular battle based on based on existing legal precedent.
If so, then the legality of a 100% reverse-engineered pure software-based
emulator will be established once and for all. Another example you
might consider is Steve Snake's KGen emulator for the Sega Genesis/MegaDrive,
which was also a 100% reverse-engineered product It proved to be such a
good program that Sega eventually licensed the source code from the author
for use in its commercially released Sega Smash Pack. Talk about
coming full circle!
As a final nod to the issue of of reverse
engineering, let me share something with you from a leading major industrial
organization with whom I have dealt in an indirect way for many years.
One of the chief trade organizations in the electromechanical industry
is the Institute of Electrical and Electronics Engineers (IEEE).
You normally hear about them
whenever there is a dispute about specifications for electrical or
mechanical components; they are the industry's means of regulating itself.
Here are some significant excerpts from their official policy statement
regarding the concept and practice of reverse engineering which you might
...We also believe that the high intellectual
content of a computer product and competition are enhanced when
computer products developed by one vendor
are capable of operating with computer products developed
by another vendor. This compatability
promotes the development of interoperable products by independent and
competing vendors and, therefore, promotes
enhanced value to the vendee at a competitive price....
We further believe that lawful reverse engineering
of computer programs is fundamental to the development
of programs and software-related technology....
We further believe that lawful reading, analysis, or disassembly of
machine language is a reverse engineering
technique by which an engineer can reconstruct the ideas of a computer
Accordingly, an engineer having the right to
use a copy of a computer program should be entitled, without the
authorization of the author, to observe, study,
and test the functioning of the program, in order to determine the ideas
that underlie the program, if it is accomplished
while performing any of the acts of reading, displaying, running,
transmitting, receiving, or storing the program
or other lawful acts involving the program that the engineer is entitled
We support the fair use rulings in the recent
Appellate Court decisions in the Ninth and Federal Circuit, in Sega
Enterprises vs. Accolade, 977F.2d 1510 (9th
Cir. 1992) and Nintendo vs. Atari, 975F.2d 832 (Fed Cir. 1992)
pertaining to dissasembly of computer code.
Pretty strong stuff, isn't it? And from one of the "big guns,"
too. These are the people who tell companies like Nintendo exactly
how they can build their systems in such a way as to be considered safe
for its users. The IEEE would not issue a policy statement with regards
to the legality of reverse engineering and its underlying requirements
unless they were absolutely sure of their facts. Emulator developers
should take this to heart whenever an original vendor begins making broad
claims of patent and copyright violation against them. Such claims
are frequently unfounded, and are almost always proven so when the issue
is pressed in the courts.
THE TWIN PITFALLS OF EMULATION RELEASE
Finally, the day arrives when you plan to unveil
your emulator. Whether you are a commercial company with considerable
time and resources invested in your product, or you're just an extremely
gifted hacker like the one described earlier, the time has come to make
your creation known to world. What happens next? Well, that
depends on two things: who originally vended the system you
are emulating, and how old that technology might be.
There has been a growing acceptance of emulation
within the computer and videogame industry; however, it is not yet universal.
Nintendo's attitude is well known and is embodied in their official emulation
The UltraHLE [sic] is illegal. The N64
emulator infringes Nintendo's intellectual property rights, including copyrights,
and circumvents Nintendo's anti-piracy security
While you may not agree with their stance and their contentions may
not be provable, it nevertheless highlights one extreme of the scale that
original vendors use to measure emulation. A completely different
approach is taken by Hasbro, now the owner of Nintendo's longtime competitor
Atari, who recently released all rights for the now-defunct Atari Jaguar
videogame system into the public domain:
We realize there is a passionate audience of
diehard Atari fans who want to keep the Jaguar system alive, and we don't
want to prevent them from doing that.
We will not interfere with the efforts of software developers to create
for the Jaguar system.
These are the two extremes you will have to face when deciding how the
vendor will react to the release of your unlicensed emulator. Each
company choses to respond in a different way for different systems at any
given time, so attempting to predict their behavior is not always successful.
The other item to consider is the age of the
technology you are emulating. Has the system been dead and gone for
several years, or its it just on the verge of expiring? Or perhaps,
as was the case with UltraHLE, the system you wish to emulate is still
economically viable. What then? Before you answer that question,
try looking at the issue from the vendor's perspective, and Nintendo's
emulation policy statement makes an excellent point in this regard.
Copyrights and trademarks of games are corporate
assets. If these vintage titles are available far and wide, it
undermines the value of this intellectual
property and adversely affects the right owner. In addition, the
the games involved are vintage or nostalgia
games is incorrect. In fact, there are now more and more programs
available that emulate current game systems
such as Game Boy and the Nintendo 64.
If you release an emulator for a product that it still on the market,
you are presenting yourself as a direct threat to that product's market
share. Original vendors, like most companies, try to maximize
sales in order to achieve maximum profit at minimum cost. They only
have so much time to sell that system before something new comes along
or a competitor releases a better or cheaper product; after all, most computer
systems have an fairly short shelf life due to rapidly advancing technology.
As Moore's Law puts it, processing power doubles every eighteen months.
Your emulator could cut in on their best market window - not very much,
perhaps, but enough to make a difference on the balance sheets or come
tax time. Do you think they relish this thought? Not at all.
Vendors of systems that have long since gone off the market or are on the
verge of dying anyway usually don't complain about emulation, but it's
the "live" systems that pose the biggest risk to emulate. An excellent
example of this comes from the personal computer world, where Readysoft
vended a commercial emulator for a "live" computer - in this case the Apple
Macintosh. Apple promply sued, and nobody who observed that situation
was in any doubt as to Apple's real motivations. A-Max directly threatened
Apple's revenue stream on a current product - in this case, the Macintosh
computer as it existed at the time (the Mac Classic, as it is referred
It may interest you to know that the official
IDSA policy statement with regards to emulation states the following with
regards to their intended purpose:
...most emulators that are freely available
today are merely software emulators that have no role in the creation of
properly licensed videogames and therefore
have the exclusive purpose of infringing copyrights and are unambiguously
This may be true if you are looking at the issue from a pure videogame
standpoint; however, freeware emulation covers considerably more territory
than just videogames. It is the popularity of videogames that causes
the issues they raise to be brought to the fore ahead of all others.
In addition, certain commercial videogame companies actually encourage
emulation with regard to their products (Atari, for example); thus the
IDSA cannot prove its claim of emulation being "unambiguously illegal."
One such example is well-known in the emulation community. Steve
Snake's KGen was available as a freeware product long before it became
"legitimized" by Sega with the Sega Smash Pack. As someone who aided
in its development, albeit in a small way, I can say without hesitation
that it would never have been licensed had it not proven itself in the
eyes of the emulation community first. That is what got Sega's attention,
and the rest, as they say, is history. The IDSA is in error with
their policy statement in this regard and should amend it to read "many
videogame emulators...are for the most part illegal." Not that they
will - they have to say what they say the way they say it in order to make
the strongest case possible for their beliefs - but such a change would
make them seem less pretentious.
IN DEFENSE OF EMULATION
There are three primary attacks by an original
vendor on the developer of an unlicensed emulator. It is not surprising
that each falls under the three major categories of intellectual property
Emulation permits the bypassing of any antipiracy protection measures
and other such proprietary
vendor processes internal
to the hardware and original software of the system. This represents
a direct threat to the
intellectual property rights
of the original vendor.
Emulation promotes software piracy because users are no longer requried
to buy the
and as such represents a clear and present threat to the original vendor's
profit margin. It is also a
given that users may
no longer be required to obtain the system's software in its original commercial
Since vendors traditionally
reap the most profit from software sales, this further impacts potential
It is a fact that emulators are never as good as the actual hardware.
This could contribute
to a detrimental mindset
against the original vendor, as an emulator does not accurately replicate
the experience of using
the original system.
As such, emulation poses a direct threat to both the corporate image and
quality control of the
original vendor and its
So how does an emulator author protect themselves against legal action
by the original vendor and/or its licensees? Here are some of the
primary defenses upon which an independent developer could build when being
sued over the release of an unlicensed emulator:
Reverse engineering is a legally recognized process whereby the
function of original vendor
equipment can be reproduced
without using proprietary vendor constructs and designs (IBM vs. Phoenix
1982?). As long as
an emulator successfully duplicates the workings of the actual system but
does not contain any of the
vendor's proprietary computer
code (or unlicensed custom hardware), then the emulator is a legal product
AMD, 1991). The
legality of emulation has already been established in the courts (Apple
vs. Readysoft, 1989).
Most emulator authors contend
and can prove that they used only publicly available information (press
close obsevation of the
actual system, etc.) in developing their emulator. Those who are
forced to use a vendor-specific
part or process (like a
vendor BIOS) will almost always devise a means whereby the user must legally
obtain said items
themselves in order to get
such an emulator to function properly. Once it is established
that the emulator is indeed a
then any claims of intellectual property infringement are unsubstantiated.
Nintendo and certain other
vendors like to counter this argument with one of their own: that
their so-called antipiracy
qualify as a vendor-specific process. In fact, the primary purpose
of most videogame antipiracy
systems is twofold:
first, to prevent titles developed in one market from being used in another;
second, to prevent
production of unlicensed
titles by independent developers. Unlicensed duplication is in fact
a minor issue at best. That
is why Atari had such a
hard time in the courts - its 2600 console had no such system and therefore
did not qualify for
patent protection (no unique
parts). That is why Japanese Playstation games won't work on American-vended
and vice-versa without special
modifications. That is why the first Atari conversions for the NES
did not work until they
found a way to emulate the
system's 10NES lockout codes. The preferred way to dodge the "unlicensed"
bullet is to
design your emulator in
such a way as to avoid or ignore any antipiracy systems that the system's
software might engage.
Such is difficult, but not
impossible. The best way to dodge the "market" bullet is to design
your emulator so it will work
only with those titles released
for a specific market. Unfortunately, such dodges are the exception
rather than the rule
because of the desire on
the part of many emulator authors to support all of a system's functions
and software base
regardless of purpose or
market origin. In addition, the Digital Millenium Act makes
it illegal to bypass the security
system of a computer-based
system, and it is unclear at this time whether or not any antipiracy systems
consoles would qualify as
a bonafide security system under the terms of that law. Therefore,
the legality of an
unlicensed emulator for
computer-based systems made since the passage of the Digital Millenium
Act remains unclear at
this time. In fact,
due to the long-lived nature of copyrights, such protection might be sought
retroactively for older
systems - in which case
there are few options available for defense other than market unviability
of the original.
The impact of sales of an unlicensed product vs. sales of an licensed
minimal at best (Nintendo
vs. Galoob, 1990). Emulators are usually released well into the lifetime
of a system, when
the market for such a product
is diminishiing, and are almost always a good indication that the original
become dated or is nearing
obsolescence. Also, emulation tends to support the formats used
by software pirates
because these formats
are the same used by developers who need to create "intermediate copies"
of existing titles for
development purposes (Sega
vs. Accolade, 1992). This affilation is often circumstantial, since
software pirates can get
access to the same kind
of dumping and/or duplication hardware that a legitimate developer would.
formats are usually easier
for an emulator developer to work with and support due to their software-based
While we're on the subject,
let's not forget that the legality of emulating or reverse-engineering
functions within the
original system has been established by case law (Nintendo vs. Atari,
1992), so long as they
do not contain any "unnecessary
elements" with regards to performance.
If a vendor choses to
use a delivery system that is susceptible to software piracy, then they
themselves up to same.
It is given that there will always be software piracy and that a small
portion of sales will be lost
to same. Most system
vendors accept this, adjusting the price of their product upward somewhat
in anticpation of
expected losses, and adopt
a two-pronged attack on any infringers: they modify their delivery
systems in such a way as
to discourage the manufacture
of infringing copies of their software (antipiracy systems and copy-protection
and they aggressively prosecute
any and all perceived cases of intellectual property violation. This
is why vendors of
videogame consoles using
the CD-ROM delivery format (Sony Playstation, et. al.) have been more prone
piracy than vendors who
choose a more difficult delivery process to successfully replicate, such
as ROM-based game
cartridges (Nintendo N64).
Nintendo has a unique argument
in this regard that they recently exercised against Episilon and RealityMan,
of UltraHLE. Borrowing
from their own past experiences with Atari/Tengen, they claimed that UltraHLE
product designed solely
to play infringing copies of copyrighted works developed by Nintendo and
licensees." The wording
comes straight from case law, where any unauthorized reproduction of
work is said to be "an
infringement of the copyright;" i.e. an infringing copy. (MAI
vs. Peak, 1993). The courts
have determined that the
burden of proof with regards to copyright infringement is on the vendor,
but the vendor only
has to show reasonable
grounds for such infringement - not proof beyond a shadow of a doubt.
Even so, many within
the emulation community
and the videogame industry as a whole feel that Nintendo is behaving rather
badly in this
regard and that their contentions
will not hold up in court should the case ever come to trial. To
Broussard of 3DRealms, "Nintendo
should be hiring these guys instead of suing them." It will be interesting
to see if
Nintendo's claims concerning
the function and purpose of UltraHLE are deemed to be valid once actual
They certainly believe so, and can back up their beliefs with case law,
but it will be up to the
courts to decide whether
or not belief is the same as fact.
Any negative impact against the original vendor as a result of a sub-par
can easily be remedied with
improvements to the emulator and/or beefed-up hardware/software support
on the user's
part. The user
almost always has the option to go out and buy the original system if they
are dissatisfied with the
Original vendors do not want an independent product to infringe upon their
experience," so they
will do anything they can to ensure that their customer base remains locked-in
vs Nintendo, 1988; Nintendo vs. Galoob, 1990). The courts have not
always agreed that such
monopolistic practices are
legal (New York vs. Nintendo, 1991; AVE vs. Nintendo, 1991); however, they
objection to an original
vendor opposing an unlicensed product (Nintendo vs. Atari, 1992).
This is how Nintendo
can remain so violently
opposed to emulation and get away with it - they perceive it as a viable
threat to their corporate
assets. To quote Nintendo's
opinion from their emulation policy statement, "Emulators promote piracy.
That's like asking
why doesn't Nintendo legitimize
piracy. It doesn't make any business sense. It's that simple
and not open to debate."
No, it's not that simple,
and it is indeed open to debate, as anyone who researches the issue will
discover. One should
consider Nintendo's real
motivations on the subject before passing judgement on this issue.
IN DEFENSE OF THE PROFIT MOTIVE
So why do some original vendors get so upset
about emulation? Well, look at it from their point-of-view.
Somebody wrote the code to that game you're playing on your emulator.
A mid-sized company paid them for it or the license to it, and then a big
company bought the rights to vend it. On top of that, system vendors
have their own financial arrangements when it
comes to developing and/or porting software to and from their proprietary
hardware. That software is designed to be specifically used with
the original vendor's system. With regards to that system, somebody
spent a lot of money researching and designing it. They may have
contracted others to do it for them, or they may have made it themselves.
It costs money for
research and development, intellectual property protection, promotion
and advertising, manufacturing, and so on. The only way they are
to make that money back is to sell their product at a profit - which means
they have to sell lots of units and lots of software for that system in
order to get a return on their investment. Paid ... bought ... financial
arrangements ... money ... contracted ... profit ... sell ... investment
- do you see the common theme? Now do you understand why a firm like
Nintendo screams bloody murder whenver somebody comes along and emulates
a system that has yet to even show signs of finishing its market run?
Do they get upset? You bet! In their eyes, emulation is
an infringement not only of their intellectual property rights but also
a direct threat to the profitability of their corporate assets - however
small in truth that may be. As long as said assets remain viable
as far as the markets are concerned, as long as such threats exist, and
as long as there are legal means to eliminate them, then you can expect
them to defend their sources of revenue by any means necessary.
THE FOUR GUIDING PRINCIPLES OF EMULATION RELEASE
So what's the practical upshot of everything
we have discussed? If you are going to independently develop and
then release an unlicensed emulator, then you need to keep the following
general principles in mind. Releasing an unlicensed emulator is deemed
acceptable so long as:
- it does not employ in its design
any or all parts of the actual patented or copyrighted code used in the
the actual hardware that
it is emulating.
This includes but is not limited to the BIOS,
any other on-board integrated circuts (proprietary or otherwise), and any
system-specific software designed to ensure
the operation of the actual hardware (such as its operating system).
why certain emulators require an interface
to the actual system's BIOS code - they can't include it due to copyright
restrictions. A-Max was one of the early
examples of such an emulator - you had to go out and buy the real Mac BIOS
and install in its oversized dongle before
the thing would work.
- it does not violate the patents,
copyrights, and trademarks of the original vendor and/or its licensees
the original system itself
or any accessories designed for use with it.
Here is where things get dicey for emulator
authors. If a specific piece of hardware or software within the console
been patented (or has been registered for
patent protection) then you have no legal right to duplicate it without
consent of the patentholder. That's
the old "intellectual property" argument rearing its head again.
You do have the full
legal right to reverse-engineer them and include
the reverse-engineered code within your emulator, so long as the resultant
code cannot be construed as being based upon,
derived directly from, or duplicated in any other way from the original.
Ever wonder from where all those public-domain
processor cores come that emulator authors are so fond of using?
This is the reason why. Developers reverse-engineer
those old processors and then post the reverse-engineered code as
public domain source. It saves development
time and neatly sidesteps the illegality of using dumped original code
- it does not include any materials
which would infringe upon the intellectual property rights of the original
vendor or its licensees.
In short, that means you cannot package your
emulator with any of those "ROMs" or "ROM packs" that seem to be so
popular ("ROM" is an emulation slang term
for a piece of old computer software; I will deal more on this subject
They almost always contain one or more programs
that were commercially released in an earlier life and as such are
protected by copyright. An excellent
example of such an emulator is MAME, the Multiple Arcade Machine
originally authored by Nicola Salmoria, which
is one of the most popular programs within the emulation community.
distribution agreement states up front that
anybody who distributes MAME may not include it within a package containing
any or all of the arcade "ROMs" that it supports,
nor may they include it as part of a arcade "ROM" compilation sold for
profit (like certain CD-ROMs you see offered
for sale by the "warez" sites). SNEmul is an example of an
console emulator that also conforms to this
principle. It is distributed with a public domain program in "ROM"
demonstrates this SNES emulator's abilibity
to correctly replicate the original console's Mode 7 graphics. Such
is not considered to be copyright infringement
no matter how you choose to interpret the law.
- it does not emulate a computer system
that is still economically viable.
Everybody agrees that Episilon and RealityMan
were crazy to release UltraHLE when the original N64 console was still
very much alive and kicking. To quote
Kenn Hoekstra of Raven Software, "...making an emulator to hand out free
for a system that STILL HAS A VIABLE MARKET
SHARE is just SUICIDE! The guys who did it are dumb, in my
opinion, and should be prosecuted....
How anybody can be shocked or surprised or appalled by this is beyond me...."
The only real question here is what one means
by economically viable. Does that mean that you wait
until the original
vendor announces plans for a new system, or
do you wait until slumping sales hit a certain level, or until the original
vendor announces that they will soon cease
production of the system, or (as certain vendors would have it) until such
as the original vendor deigns to grant an
expensive license for a product that they intend to sell under their own
There is currently no defined point at which
the release of an unlicensed emulator is acceptable, and perhaps it is
for the emulation community to better police
themselves in this regard.
Up to this point, we've talked about the basis
for emulation. We've talked about developing an emulator. We've
just finished talking about releasing an emulator. So what conclusion
can we draw about emulation in general? Apply Occam's Razor and draw
the obvious one. As KGen author Steve Snake recently noted in an
Internet message board posting, "Emulation is legal. It's that simple
and not open to debate."
Companies like Nintendo and Sony can no
more stop emulation than King Canute could order back the tide.
It is legal for original vendors to develop their own emulators.
It is legal for an independent developer to make their own emulator, provided
it does not violate the original vendor's intellectual property rights.
It is legal for an independent developer to release such an emulator without
the original vendor's approval, but it is not generally acceptable to do
so until such time as the system being emulated is no longer economically
viable. The only real issue involved here is the actual timing
of the release of an unlicensed emulator, and that is the one upon
which both the original vendors and the emulation community will have come
to terms sooner or later.
We have now come to the end of the various
discussions with regards to the legality of emulation. You should
now know what is involved in developing, releasing, and possibly defending
an independently developed unlicensed emulator. Now come one of the
biggest issues of all, and it represents (as the British would say) a "sticky
wicket" indeed: "How do I support an emulator?" That will comprise
our next big area of discussion.
1. Why is hardware-based emulation not considered to be a problem?
2. What particular issues do developers of emulators involving hardware-software
combinations have to consider?
3. What is the best means of development in order to produce a legal
unlicensed software-based emulator? Name two
examples of such a product from the text or provide
valid ones of your own. What does the IEEE have to say about this
4. What are two items of concern that independent developers must consider
before releasing an unlicensed emulator?
5. What are the three primary arguments that vendors use whenever they
sue the developers of an unlicensed emulator? What
charges can you derive from those arguments?
6. How can an emulator developer defend themselves against charges of
intellectual property infringement by the original
7. What is the truth behind "antipiracy security systems" in their current
form? What are some ways to deal with this issue?
Why do some emulator developers choose to ignore
the problem in their products?
8. What does the release of an emulator usually indicate with regards
to the original system? Why would this upset the original
9. Which is easier for a videogame emulator developer to work with -
program code within the original hardware or dumped
program code? Why? Under what conditions
is dumping the program code a valid practice?
10. What is the software industry's general impression with regards
to the impact of software piracy on vended software
sales? How does this affect the
choice of delivery systems for a videogame vendor? How does this
impact upon the
release of an emulator?
11. What is Nintendo's latest argument with regards to emulation and
their intellectual property rights? What is the basis for
this argument? Do you feel their
contention is valid? Why or why not?
12. What was the chief mistake committed by Epsilon and RealityMan concerning
the release of UltraHLE? When is the right
time for a developer to release an unlicensed
13. What causes certain vendors to become concerned whenever an emulator
is released for one or more of their systems?
14. What are the four main principles to remember before an independent
developer releases an unlicensed emulator?
15. Is emulation legal? Why or why not?
THOUGHTS TO PONDER
1. If it is legal to design and then release an emulator, then is it
legal to provide copies of the commercial software originally
designed for use with the system being emulated?
2. Is it legal to dump a BIOS image in order to avoid having to create
an emulator that would otherwise be a hardware-
software combination in design?
3. What is a "ROM?" Is there such a thing as a "legal ROM?"
4. Is it legal to backup computer software that was originally vended
in some form of permanent storage format, such as a
game cartridge or CD-ROM?
5. What is "fair use?" How does the concept of "fair use" apply
6. How can the Internet legally support the emulation community?
section last revised 20 January 1999