By using this site, you agree to our Privacy Policy and our Terms of Use. Close

Forums - Nintendo Discussion - Nintendo files patent for Game Boy emulation on mobile phones, PDA's, PC and more

 

What will this lead to?

Demos for phones that wil... 25 25.00%
 
Nintendo's putting their... 42 42.00%
 
Nothing will come out of this. 32 32.00%
 
Total:99

Stolen from GAF

On June 23, 2014, Nintendo Co., Ltd. filed in the US a patent application for "Hand-held Video Game Platform Emulation". It was published today, on November 27, via the USPTO. Inventor is Patrick J. Link who has worked on several other patents dealing namely with emulation and security. Now, what must be mentioned is that this is a divisional application, which is a continuation of a a pending application, by the USPTO described as follows :

A later application for an independent or distinct invention, carved out of a pending application and disclosing and claiming only subject matter disclosed in the earlier or parent application, is known as a divisional application or “division.”

A similar story emerged in 2012 where many outlets wrote about it, for example Engadget. This new application is a continuation of that patent application, though with some claims changed and with less references. So it is not entirely new, but it is filed this year and not in 2003 as happened with the previous application. Anyway, let's start by talking a look at the abstract, note that this stems from 1999-2003 so the text may appear quite arcane. Interesting parts in bold.

Abstract

A software emulator for emulating a handheld video game platform such as GAME BOY.RTM., GAME BOY COLOR.RTM. and/or GAME BOY ADVANCE.RTM. on a low-capability target platform (e.g., a seat-back display for airline or train use, a personal digital assistant, a cell phone) uses a number of features and optimizations to provide high quality graphics and sound that nearly duplicates the game playing experience on the native platform. Some exemplary features include use of bit BLITing, graphics character reformatting, modeling of a native platform liquid crystal display controller using a sequential state machine, and selective skipping of frame display updates if the game play falls behind what would occur on the native platform.

Claims

1-16. (canceled) 

17. A method of adapting an emulator, the method comprising: executing, on a processor, an emulator capable of running a plurality different binary applications; recognizing, by the processor, an identity of a binary application based on an inspection of the binary application; automatically adapting, by the processor, a behavior of the emulator to the binary application based on the recognized identity of the binary application; and generating, by the processor, an audio visual presentation using the adapted behavior of the emulator.

It appears most of the claims in 1-16 have been consolidated into 17. I'm not sure when these claims where canceled, I see nothing too informative via the Patent Application Information Retrieval (PAIR) system of the USPTO.

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001]Description

This application is a divisional application of application Ser. No. 09/723,322 filed Nov. 28, 2000 (Docket No. 723-950), now U.S. Pat. No. ______. This application is related to copending commonly-assigned application Ser. No. 09/722,410 filed Nov. 28, 2000 entitled PORTABLE VIDEO GAME SYSTEM (Docket No. 723-951), which is a continuation-in-part of application Ser. No. 09/627,440, filed Jul. 28, 2000. This application is also related to copending commonly-assigned application Ser. No. 09/321,201 of Okada et al filed May 27, 1999 entitled "Portable Color Display Game Machine and Storage Medium for The Same". Priority is also claimed from provisional application No. 60/233,622 filed Sep. 18, 2000 under attorney docket no. 723-932 entitled "Method and Apparatus for Emulating a Portable Game Machine." Each of these related applications is incorporated herein by reference.

FIELD 

[0002] This invention relates to systems, methods, techniques, data structures, and other features for running software applications including but not limited to video games on platforms different from the ones the software is intended or designed to run on. 

BACKGROUND AND SUMMARY 

[0003] Nintendo's GAME BOY.RTM. hand-held video game platforms have been extraordinarily successful. Nintendo released the first GAME BOY.RTM. in the late 1980s. Since then, this product and its successors (GAME BOY COLOR.RTM. and GAME BOY ADVANCE.RTM.) have captured the imaginations of millions of video game players throughout the world. 

[0004] A wide number of different software applications (including but not limited to video games) have been designed to run on these platforms. People throughout the world enjoy these applications every day. One can see them being used on subways, at sports arenas, after school, and in a number of other contexts. See FIG. 1A. 

[0005] Nintendo's GAME BOY.RTM., GAME BOY COLOR.RTM. and GAME BOY ADVANCE.RTM. are examples of platforms having specialized hardware that is optimized for low cost, excellent performance and good graphics. These devices are not really general purpose computers; rather, they are special-purpose devices with specialized capabilities particularly adapted to video game play. These special capabilities provide low cost and exciting video game play action with good graphics and sound. 

[0006] While GAME BOY.RTM. platforms are inexpensive and have long battery life, there may be situations in which it would be desirable to play or use applications developed for GAME BOY.RTM. on other platforms. For example, an airline, train or other vehicle passenger might want to play video games during a long journey. As shown in FIG. 1B, airlines are installing seat-back computer displays into the backs of airline seats. Such seat-back displays may provide a low cost personal computer including a processor, random access memory, liquid crystal display and input device(s). Similar displays could be installed in other vehicles (e.g., trains, ships, vans, cars, etc.) or in other contexts (e.g., at walk-up kiosks, within hotel rooms, etc.). It would be desirable under certain circumstances to allow users to execute all sorts of different applications including GAME BOY.RTM. video games and other applications using the general-purpose computer capabilities of such seat-back or similar display devices

[0007] Personal computers have also proliferated throughout the world and are now available at relatively low cost. A trend has shifted some entertainment from the home television set to the home personal computer, where children and adults can view interesting web pages and play downloaded video games and other applications. In some circumstances, it may be desirable to allow users to play GAME BOY.RTM. video games on their home personal computers (see FIG. 1C)

[0008] A wide variety of so-called personal digital assistants (PDA's) have become available in recent years. Such devices now comprise an entire miniature computer within a package small enough to fit into your pocket. Mobile cellular telephones are also becoming increasingly computationally-intensive and have better displays so they can access the World Wide Web and perform a variety of downloaded applications. In some circumstances, it may be desirable to enable people to play GAME BOY.RTM. video games and other GAME BOY.RTM. applications on a personal digital assistant, cellular telephone or other such device (see FIG. 1D)

[0009] The special-purpose sound and graphics circuitry provided by the GAME BOY.RTM. platforms is not generally found in the various other platforms shown in FIGS. 1B, 1C and 1D. Providing these missing capabilities is one of the challenges to running a GAME BOY.RTM. video game (or other GAME BOY.RTM. application) on these other target platforms. 

[0010] Another challenge relates to instruction set compatibility. Nintendo's GAME BOY.RTM. is based on an older, relatively inexpensive microprocessor (the Zilog Z80) that is no longer being used in most modern general purpose computer systems such as personal computers, seat-back displays and personal digital assistants. The Z80 instruction set (the language in which all GAME BOY.RTM. games and other GAME BOY.RTM. applications are written in) is not directly understood by the more modern Intel microprocessors (e.g., the 8086, 80286, 80386, Pentium and other processors in the Intel family) that are now widely used and found in most personal computers, seat-back displays, personal digital assistants, and the like. While it is possible to "port" certain GAME BOY.RTM. games or other applications to different microprocessor families (e.g., by cross-compiling the source code to a different target microprocessor), there may be an advantage in certain contexts to being able to play or execute the same binary images stored in GAME BOY.RTM. cartridges on target platforms other than GAME BOY.RTM.. 

[0011] One way to provide a cross-platform capability is to provide a GAME BOY.RTM. software emulator on the target platform. Generally, a software emulator is a computer program that executes on a desired target platform (e.g., a seat-back display device, a personal computer or a personal digital assistant shown in FIGS. 1B-1D) and uses software to supply native platform capabilities that are missing from the target platform. For example, a software emulator may perform some or all of GAME BOY.RTM.'s specialized graphics functions in software, and may interface with whatever graphics resources are available on the target platform to display resulting images. A software emulator may translate or interpret Z80 instructions so the microprocessor of the target platform can perform the functions that GAME BOY.RTM. would perform if presented with the same instructions. The software emulator may include software code that emulates hardware capabilities within the GAME BOY.RTM. circuitry (e.g., audio and/or graphics processing) and/or translate associated GAME BOY.RTM. application requests into requests that can be handled by the hardware resources available on the target platform. For example, the target platform may include a graphics adapter and associated display that is incompatible with GAME BOY.RTM.'s graphics hardware but which can perform some of the basic graphics functions required to display GAME BOY.RTM. graphics on a display. 

[0012] A number of GAME BOY.RTM. emulators have been written for a variety of different platforms ranging from personal digital assistants to personal computers. However, further improvements are possible and desirable. 

[0013] One area of needed improvement relates to obtaining acceptable speed performance and high quality sound and graphics on a low-capability platform. A low-capability platform (e.g., a seat-back display or a personal digital assistant) may not have enough processing power to readily provide acceptable speed performance. Unless the software emulator is carefully designed and carefully optimized, it will not be able to maintain real time speed performance when running on a slower or less highly capable processor. Slow-downs in game performance are generally unacceptable if the average user can notice them since they immediately affect and degrade the fun and excitement of the game playing experience. 

[0014] Performance problems are exacerbated by the penchant of some video game developers to squeeze the last bit of performance out of the GAME BOY.RTM. platform. Performance tricks and optimizations within a GAME BOY.RTM. application may place additional demands on any emulator running the application. Some prior art emulators provide acceptable results when running certain games but unacceptable results (or do not work at all) for other games. An ideal emulator provides acceptable results across a wide range of different games and other applications such that the emulator can run virtually any game or other application developed for the original platform. 

[0015] Another challenge to designing a good software emulator relates to maintaining excellent image and sound quality. Ideally, the software emulator running on the target platform should be able to produce graphic displays that are at least the same quality as those that would be seen on the native platform. Additionally, the color rendition and other aspects of the image should be nearly if not exactly the same. Sounds (e.g., music and speech) from the emulator should have at least the same quality as would be heard on the original platform. All of these capabilities should be relatively closely matched even on platforms with radically different sound and graphics hardware capabilities. 

[0016] One prior attempt to develop a video game platform emulator is disclosed in U.S. Pat. No. 6,115,054 to Giles. That patent describes a general purpose computer based video game platform software emulator including an execution skipping feature that evaluates the ability of the general purpose computer to generate video frames fully synchronized with the target platform computer system. If the evaluation determines that the emulator is falling behind the target system, the emulator executes only a first subset of the graphics commands while skipping execution of a second subset of graphics commands so as to partially render the frame. For example, the patent discloses fully executing certain graphics commands while partially executing others (e.g., clipped drawing commands) to provide a partial rendering of the frame. One disadvantage to the approach described in the Giles patent is that partial rendering of a frame can lead to uncertain imaging results that will degrade the quality of the image being produced by the emulator. 

[0017] The present invention solves these and other problems by providing a unique software emulator capable of providing acceptable speed performance and good image and sound quality on even a low-capability target platform such as a seat back display for example. 

[0018] The preferred embodiment software emulator provided by this invention maintains high-quality graphics and sound in real time across a wide variety of video games and other applications--and nearly duplicates the graphics and sound that would be experienced by a user of the GAME BOY.RTM., GAME BOY COLOR.RTM. and/or GAME BOY ADVANCE.RTM. platform running the same game or other application. The preferred embodiment emulator achieves this through a unique combination of features and optimizations including, for example: [0019] use of a virtual liquid crystal display controller (state machine) to maintain real time synchronization with events as they would occur on the native platform, [0020] use of a hardware-assisted bit BLIT memory transfer operation to efficiently transfer graphics information into video memory, [0021] pre-computed translation table for translating native platform graphics character formats into formats more compatible with standard graphics adapters, [0022] emulation of native platform color palette information to provide compatibility with games and other applications that change color palettes within a frame, [0023] emulation of major registers and other hardware-based memory structures within the native platform in RAM under software control, [0024] use of a jump table able to efficiently parse incoming binary instruction formats, [0025] use of a unique page table to control memory access by remapping memory access instructions into different memory locations and/or function calls, [0026] availability of a ROM protection function to eliminate ROM overwriting during emulated operations, [0027] responsive to video game compatibility modes and registration data, [0028] models native platform using state machine defining search, transfer, horizontal blank and vertical blank states, [0029] cycle counter to determine when a modeled state has expired and transition to a new state is desired, [0030] selective frame display update skipping while maintaining execution of all instructions to maintain state information while minimizing game play slowdowns, [0031] optional NOP loop look ahead feature to avoid wasting processing time in NOP loops, [0032] redundant emulated RAM and ROM storage to optimize execution efficiency, [0033] separate page tables for read and write operations, [0034] modeling of native microprocessor registers as a union of byte, word and long register formats, [0035] modeling native instruction CPU flags to allow efficient updating after operations are performed by target platform microprocessor, [0036] mapping emulated program counter into target platform microprocessor general purpose register, [0037] reads and writes via index register go through pointer tables to increase execution efficiency, [0038] adaptable input controller emulator to provide user inputs from a variety of different user input devices, [0039] emulated object attribute memory, and [0040] use of screen memory buffers larger than screen size to increase paging efficiency by eliminating clipping calculations and using the hardware BitBlt to transfer a subset of the memory buffer to displayed video memory.

Imagery (I've taken the libery of including fewer than usual, most of them are just block diagrams describing modes and methods anyway)


[0042] FIG. 1A shows someone playing a Nintendo GAME BOY.RTM. portable video game platform;






[0043] FIGS. 1B-1D show various different target platforms that could be used to emulate the FIG. 1 GAME BOY.RTM.;


[0044] FIG. 2 is a block diagram of an example software emulator architecture;

Sourcehttp://appft.uspto.gov/netacgi/nph-P...RS=AN/Nintendo

I won't include the detailed description as it just describes a bunch of modes and instructions for emulation on various platforms. But if you are interested in that, it's of course readily available at the link.

Does this mean that we will see a Game Boy emulator, an official one anyway, on iPhone soon? Not necessarily. As always, a patent application does not confirm a product or service, it is simply an idea that may or may not be used. For the original applications filed over a decade ago, we have yet to see anything. But it at least seems like Nintendo has interest in this, be it for legal reasons or for actually exploring a new market. There you have it anyway.

MohammadBadir said:

"Hope you enjoyed the demo! If you'd like to play Nintendo classics without virulent, sickeningly botched controls, you can download on the Virtual Console, only available on Nintendo systems. B)"



Around the Network

I just jizzed in my pants.



Gameboy games coming to iPhones most likely but I thought Iwata said...



"Hope you enjoyed the demo! If you'd like to play Nintendo classics without virulent, sickeningly botched controls, you can download on the Virtual Console, only available on Nintendo systems. B)"



Just covering their bases by patenting everything. Standard lawyer work .



Around the Network

Knowing Nintendo they'll probably make a Japanese exclusive smart phone and have their own app store on the thing ala Apple.



I honestly HOPE it's nothing more than demo's......



Maybe they decided they wanted money?

If anything it could benefit their future handheld by getting people to fall in love with their franchises and quality gaming, obviously the new stuff will only be available on their platform.

With the 3DS doing really well but falling quite short of most handhelds that have come before, I think Nintendo must be planning on responding to the mobile market in some way or another. If doing this secured them tons worth of revenue, maybe they would take more adventures chances with their actual consoles?



Holy scat of an ant-eater! Is this the beginning of the end or the beginning of the beginning is what I want to know!



                  

PC Specs: CPU: 7800X3D || GPU: Strix 4090 || RAM: 32GB DDR5 6000 || Main SSD: WD 2TB SN850

I have an idea how to ensure nintendo domination for eternity. Just patent the very concept of video games and forbid everyone from making them. Wii U instantly saved, next Mario Whatever sales 30 millions at launch.