Emulation:  Right or Wrong?
aka "The EmuFAQ"


copyright (c) 1999 Sam Pettus (aka "the Scribe"), all rights reserved

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 the U.S. Copyright Act and the Berne Convention for the Protection of Literary and Artistic Works.

Any trademark or other such indica to be found within this document is the exclusive property of its respective owner, and is reproduced here merely for the sake of reference.

Module One:  The Emulator
Part 3 - Releasing an Emulator

OverClocked #10, "Spare Time" © 2000 David Lloyd

I still feel that most emulators ... are perfectly legal.  It kinda falls into that "legal to own, illegal to use" category that seem to cover game copying devices and cable descramblers.

Jeff Gerstmann, review editor, VideoGames.com

     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 UltraHLE - 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.  Nintendo was well aware of the rising interest in emulating its popular videogame systems, what with working NES and SNES emulators already available, and they had strongly supported the IDSA sweep against illegal Internet ROM sites during the spring and summer of 1998. They kept abreast of the growing possibility of N64 emulation and were the ones behind the shutdown of Project Unreality, the most promising N64 emulation project of 1998.  They threatened legal action if that project produced a working N64 emulator, so the authors of Project Unreality abandoned their efforts at that time.  Both Epsilion and RealityMan were already quietly conducting a parallel effort to develop a working N64 emulator, but they decided to try a different approach than that of the Project Unreality team.  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.  What was even more insulting was that UltraHLE promised full compatibility with The Legend of Zelda: The Ocarina of Time (aka Zelda 64), the first N64 entry in the long-running and popular RPG series by Nintendo and its biggest seller of the 1998 Christmas shopping season.  The release of a working N64 emulator promising full compatibility with their newest hit title was just too much to take, so it should not have surprised the emuscene when Nintendo reacted like it did.  The blindsided videogame giant 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.  Zelda 64 was the most sought-after "ROM" of the lot, and it took little effort for dedicated Internet users to eventually track it down. UltraHLE was by no means perfect, and only worked with about one-third of the "ROMs" in existence at the time, but it worked with Zelda 64 and Super Mario 64 (the console's flagship title), and that was enough for most folks.
     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 threatened to file suit against its authors claiming that the emulator was an infringing work that promoted software piracy.  The threats were considered to be pure bluff by the emulation community and many sites called them on it - those that weren't carrying any bootleg N64 "ROMz," that is.  As for the lawsuit threat against the UltraHLE authors, it is still looming as of this date, and the resultant legal pressures coupled with the instant popularity of UltraHLE among the software pirates forced the temporary "retirement" of RealityMan for a period of several months.  In the meantime, Nintendo continued to flail away at the illegal N64 "ROM" sites whenever it found them, but it was of little use.  At least two more sites would spring up for every one Nintendo managed to shut down, often hosted by unscrupulous ISPs and frequently in countries where Nintendo's famous legal resources were of little avail.  Nintendo continues to maintain to this day that UltraHLE violated the patents and copyrights that it held on the N64 internals and microcode, including the system's anti-piracy security system.  While the construction of UltraHLE remains a closely guarded secret even to this day, both Epsilion and RealityMan contend that it was an 100% reverse engineered software-based emulator; furthermore, the anti-piracy feature was not an issue because they did not emulate it (which would have been illegal).  In the meantime, though, Nintendo's legendary intimidation tactics continue to be employed against anybody who carries UltraHLE and the requisite "ROMs," but the sad truth is that UltraHLE continues to be freely available and can be downloaded by anybody with the will to find it.
     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 supposedly 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 while others called 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, later renamed as the Dolphin) not long after the release of UltraHLE, so perhaps those who feared the N64's impending obsolescence 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 firmware emulators, as well as the more common varieties of hardware-software combinations.  Firmware 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 have included a PlayStation emulation mode that permits playing of many (but not all) older titles on the newer system.  This is a practice that is universally accepted within the industry; furthermore, firmware emulators are quite profitable to the original vendor due to the proprietary nature of such.  It would be almost impossible to build a firmware emulator without the consent of the original vendor, aside from the ubiqutous cart adapters, 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 the many unlicensed clones of the NES console during its lifetime and see where it landed them.
     A combination emulator 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 use of the original Macintosh BIOS in its special hardware adapter - the Mac BIOS was the only truly proprietary part of the system - and this practice was eventually deemed acceptable.  Jump forward in time to the present, where combo emulators have taken a new twist.  The modern variety frequently require the use 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 called Amiga Forever designed expressly for users of the WinUAE Amiga emulator.  Along with the emulator and other extras, 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.


     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 Am386 (Intel vs. AMD, 1991).  The courts have ruled time and again that reverse engineering does not void copyright protection, as it does not replicate the original's "defining algorithms."  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.  The best way to do this is what is known as the "clean room" technique, in which reverse engineered code is developed on the basis of observing the actual operation of the original system and then coming up with an independently developed means of duplicating its various processes.  The legality of the "clean room" technique was validated in the famous legal dispute over the cloning of the IBM PC BIOS (IBM vs. Compaq, 1982).  The "clean room" technique is also the chief reason why Sony was unable to prevent the bleem! PlayStation emulator from going to market (Sony v. Bleem LLC, 1999), as the company had ample documentation to prove that "clean room" techniques were used in every aspect of bleem!'s design.  This has established beyond the shadow of a doubt that the legality of the "clean room" technique also applies to emulator development.  Another example you might consider is Steve Snake's KGen emulator for the Sega Genesis/MegaDrive, which was also a "clean room" 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 find interesting:

     ...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 compatibility 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 program.
     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 to do.
     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 disassembly 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.  These facts were recently codified into law by the Digital Millenium Copyright Act, which I shall hereafter often abbreviate as the DMCA.  Emulator developers should take this to heart whenever an original vendor begins making broad claims of copyright violation against them for the use of reverse engineered code.  Such claims are frequently unfounded, and are almost always proven so when the issue is pressed in the courts.


     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 FAQ:

The UltraHLE [sic] is illegal.  The N64 emulator infringes Nintendo's intellectual property rights, including copyrights, and circumvents Nintendo's anti-piracy security system.
While you may not agree with their stance and not all of their contentions may 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 software 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 chooses 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 assumption that 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 is still on the market, you are presenting yourself as a direct threat to that product's market share.  That fact, in retrospect, seems to be why Nintendo reacted as violently as it did to the appearance of UltraHLE.  Epsilion and RealityMan boldly bragged about their emulator's ability to handle Zelda 64, along with other hit N64 cartridges at the time. UltraHLE directly threatened Nintendo's revenue stream on those titles, and that of the newly released Zelda 64 most of all.
     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 product before something new comes along or a competitor releases a better or cheaper product.  On top of that, most computer-related products 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 the original system vendor's 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 is the "live" systems that pose the biggest risk to emulate.  An excellent example of this comes from the personal computer world of the 1980s, during which time Apple Computer went after anybody and everybody who tried to market clones of their computers in any form, shape or fashion.  Products such as the Franklin ACE 1000 clone of the Apple II and Readysoft's A-Max emulator for the Amiga threatened those projected profits.  The same holds true today, with Apple back up to its old tricks again - not to mention Nintendo running to ground the makers of every off-brand unlicensed derivative based on one or more of its proprietary product lines anytime one pops up.  The corporate mindset that lies behind prosecuting those who make and distribute unlicensed products works equally well against those who make and distribute unlicensed emulators.
     So why do these 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 whenever 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 to conduct research and development, arrange intellectual property protection, design promotion and advertising, tool up for 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 whenever 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.
     After reviewing what few cases have been brought to bear in the courts concerning computer system emulation, it seems that there are three primary attacks used by an original vendor against these so-called "infringing products."  It is not surprising that each falls under the three major categories of intellectual property protection: It should be noted that these are all valid charges, and vendors with this mindset can bring an amazing array of facts and case law precedent to back up their claims.  Here are some examples for you to ponder. So, with the litigious nature of certain proprietary-minded vendors in mind, there is an obvious question that needs to be asked. Is it possible to develop and then release an unauthorized, noninfringing emulator of a proprietary computer system?  The answer is YES, but there are some qualifications that must be met first in order for such an emulator to be considered a legal product.


     It has taken me a lot of time, careful research, and a good deal of deliberation in order to come up with a generalized seven-point test that both the vendors and the emuscene can use to determine the legitimacy of any emulator that comes down the pike.  I call it the A-Max test, so named after the emulator that established the possibility of unauthorized legitimacy in the first place.  It works equally well for any product being emulated, from hand-held electronics to sophisticated computer and videogame systems.  I will first present the test itself, then I will explain it, and then finish up with some examples of how it can be used to determine emulator legitimacy.

  1. The original system's microcode is not duplicated.
  2. The original system's firmware is preserved.
  3. The original system's operating system is not violated.
  4. The original system's security measures are not circumvented.
  5. The original system's delivery format is not discarded.
  6. The original system's trademarks are not compromised.
  7. The original system's economic viability is maintained.
Let's take a moment to see just what each of these points involve.
The original system's microcode is not duplicated.
    In other words, the emulator was created completely from scratch using lawful reverse engineering techniques (IBM v. Compaq, 1982; AMD v. Intel, 1991; Sony v. Bleem LLC, 1999; Sony v. Connectix, 2000).  It only emulates a select range of system functions that are absolutely necessary to achieve desired results and nothing more (Nintendo v. Atari, 1992).  This is almost always the first infringement that an offended original system vendor will claim.
    The original system's firmware is preserved.
    In other words, the emulator does not employ any proprietary microcode of any kind from within any part of the system hardware unless said code is licensed from the original vendor (Apple v. Franklin, 1983; Intel v. AMD, 1991; Sony v. Connectix, 2000).  If it requires some portion of proprietary microcode in order to achieve desired results, then said system code must be either licensed or retained within its original "package."  If the "package" approach is employed, then provision must be made for the emulator to interface with that "package" in its original, unaltered form (the A-Max affair of 1989; Nintendo v. Atari, 1992).
    The original system's operating system is not violated.
    In other words, the emulator may not be distributed with any portion of unlicensed vendor operating system code, whether that be in software form external to the system or embedded within its hardware (Apple v. Franklin, 1983; Sony v. Connectix, 2000).  This includes the original system BIOS, any patentable custom chipset unique to the original system, and any support programs designed to facilitate the proper operation of the original system, more commonly referred to as a software-based operating system.  For example, all of the early CP/M emulators included licensed copies of the actual CP/M operating system by Digital Research.  In another example, Cloanto's Amiga Forever is a commercial Amiga emulation package designed around the public domain emulator WinUAE that includes licensed copies of both the Amiga Kickstart BIOS and the AmigaDOS operating system.  Any emulator that is distributed with unauthorized copies of operating system code regardless of its origin (hardware or software) can be considered an infringing product.
    The original system's security measures are not circumvented.
    In other words, the emulator does not bypass, alter, or otherwise modify any technological measures incorporated into the original system, its supporting accessories, or its designed delivery format in such a manner that affects controlled access to the original program base.  The wording is taken almost directly from the DMCA (17 USC 1201) and applies to any embedded security systems contained either within the original system itself or as part of the delivery format for its program base.  Some authorities have contended that the DMCA effectively overrides the duplication of copy protected software for backup purposes as previously deemed permissible by case law (Vault v. Quaid, 1987; referring to 17 USC 117).  It is the opinion of most authorities that the DMCA complements the Vault decision rather than compromising it; to wit, you have the right to back up copy-protected software so long as you back up the copy protection scheme with it, and that is entirely in keeping with the Vault decision.  All the DMCA would do would be to make it illegal to "crack" such a scheme, as well as then removing that copy protection scheme from the program in question, thereby facilitating easier duplication and distribution.  This item will eventually pose a real problem for future emulator authors as vendors strive to design future systems in such a way so that emulating an embedded security system may become a necessity, which would place the legality of such an emulator at risk under the terms of the DMCA.
    The original system's delivery format is not discarded.
    In other words, the emulator must make some provision for using original copies of system software contained within their original delivery format unless its development team has obtained the proper authorization to do otherwise.  Many emulators are designed from the onset to handle one or more special program formats normally employed by developers; however, any publicly released version of that emulator (commercial or public domain) must make provision for the original program delivery format.  It does not matter one whit whether or not such a delivery format is still in use, because the courts have interpreted the ultimate right of adaptation (i.e. derivation) under copyright law, which belongs to the copyright owner, to include the intended or original delivery format (Mirage Editions v. Alberquerque ART, 1988).  This is the big problem with most "classic" videogame emulators and some "classic" computer emulators in that they do not include any provision for loading original system programs from their original delivery format.  So-called "transfer programs" or specialized hardware that converts original software to a special format are not permissible unless so authorized, and this is another problem with these kinds of emulators (Sega v. MAPHIA, 1994; Sega v. Sabella, 1995; Nintendo v. Computer & Entertainment, 1996; Nintendo v. Bung, 1999).  I note in passing that a potential "personal use" argument for derivative formats has been raised under the terms of the Betamax decision (Sony v. Universal, 1984); however, it has yet to be acknowledged by the courts.
    The original system's trademarks are not compromised.
    In other words, the emulator does not contain any code or data to generate any kind of registered trademark in any form in and of itself without proper authorization, nor does it contain any code or data to effect any unauthorized alteration or modification of any kind of a permanent nature to any registered trademark that might be generated by a program running on that emulator.  The practical upshot of this is that your emulator cannot generate any trademark displays that were generated by the original system hardware in and of itself (Sega v. Accolade, 1992); and while it is legal to generate the display of any embedded trademark contained within a program designed for use on that system, you may not do anything that would change or possibly block the permanence of said trademark (Playboy v. Frena, 1993).  Generating an embedded trademark is considered innocent infringement (Sega v. Accolade, 1992), but doing anything beyond displaying that trademark is in direct violation of the Landham Act, as the Sega and Frena cases clearly demonstrated.  Temporary alteration of a generated trademarked image is permissable under certain circumstances; however, permanent alteration is not (Galoob v. Nintendo, 1992)
    The original system's economic viability is maintained.
    In other words, the emulator does not constitute a significant threat to the current or potential market impact of the original system (Sony v. Connectix, 2000).  The concept of economic viability is a rather hazy one and is usually the second thing that an offended vendor claims with regards to a possibly infringing emulator.  It involves the notion that a given product with one or more unique selling points has only so much time on a free market to exercise its capability to bring its vendor a profit.  Once that capability vanishes, then the product is no longer profitable (Harper & Row v. Nation Enterprises, 1985).  There is no clearly defined point at which a given vendor's product economic viability disappears, and it would be foolish to try and come up with a "one-size-fits-all" approach.  This part of the A-Max test must be determined on a case-by-case basis as necessity dictates and in regards to both the particular system being emulated and the amount of time it has already spent on the market.  It can be and has been successfully argued that the older and less technologically advanced a given system has become, the more likely it is to be emulated since sufficient time has passed for any willing third party to duplicate its functions (Kewanee Oil v. Bicron, 1974).  This is probably the best guide by which to judge economic viability.
Now that we understand what the A-Max test entails, let's see how it can be applied.  I shall use four different emulators as examples:  Readysoft's A-Max (as it defines the test), the original release of Epsilon and RealityMan's UltraHLE, Cloanto's Amiga Forever (the commercial release of Bernard Schmidt's WinUAE), and finally Vision Thing's improved PSX emulator PSEmu Pro.
A-Max test item
 A-Max  (all vers.)
UltraHLE 1.0.0
Amiga Forever
PSEmu Pro
The original system's microcode is not duplicated
The original system's firmware is
The original system's operating system is not violated
The original system's security measures are not circumvented
The original system's delivery format is not discarded
The original system's trademarks are not compromised
The original system's economic viability is maintained
(1)Uses original system BIOS ROMs in a legal fashion (actual chips in special adapter)
(2)  Licensing involved to clear legal hurdles
I know that this analysis is going to have a lot of UltraHLE and PSEmu Pro users up in arms, to say the least, so let's see just why they failed the A-Max test. I challenge you to apply the A-Max test to your emulation project under development, or try it on your favorite emulator by another party for a different system.  You may be surprised by the results.
     One final reminder before we leave this subject.  Even if a given emulator fails the A-Max test, it is still the the responsibility of the vendor to actively claim perceived intellectual property infringement.  They are required to do so by law within a set period of time from the date of the perceived infringement, depending on the manner and type of infringement involved.  If they do not claim infringement during this time, then they lose the right to do so in the future (35 USC 286, 17 USC 507, 15 USC 1065). This right lasts as long as their intellectual property protections are in place, and they have been known to wait until what seems to them like an appropriate time to strike.  For example, Sony knew about the two commercial PSX emulators under development, but they waited until just before they were to hit the market to file their lawsuits.  This is something you need to keep in the back of your mind should a vendor initially fail to object to the release of your emulator.


     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."
     Commercial vendors can no more stop emulation than King Canute could order back the tide.  Vendors with closed minds have little chance of stemming the production and subsequent release of emulators for their systems for very long, if ever at all.  Other companies have tried to do so in the past with their systems and failed.  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, provided that it can negotiate the legal hurdles in its path.  Once those obstacles are overcome, then an independently developed unauthorized emulator has every right to be released to the general public.
     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 comes 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 development practice?

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 vendor?

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 vendor?

9.   Which is easier for a emulator developer to work with - program code within the original delivery format or an alternate format?  Why?

10. How does software piracy affect the choice of delivery systems for a given vendor?  How does this impact upon the release of an emulator?

11. 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 emulator?  Why?

13. What causes certain vendors to become concerned whenever an emulator is released for one or more of their systems?

14. Describe the hurdles that an emulator must jump in order to be considered a legal, noninfringing product.  Why do some succeed and others do not?

15. Do you think that it is possible to release a legal third-party emulator?  Why or why not?


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 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.   Can you define the concept of fair use?  How does the concept of fair use apply to emulation?

6.   How can the Internet legally support the emulation community?

The EmuFAQ (c) 1999 Sam Pettus - section last revised 10 March 2000