When people in the gaming community speak of emulation, they are usually referring to the emulation of a hardware console or a computer system. This software allows them to play games on hardware systems which were never engineered to allow it. Imagine, playing Super Mario Kart with your friends through the Internet on your Mac OS X, Xandros, or Microsoft Windows computer. Impossible? Google the ZSNES or SNES9X project for more details.

First of all, there seems to be some confusion over the use of the terms “emulation” and “simulation” on the Internet. It seems many people (myself included) are referring to programs, such as DOSBox or ZSNES, as emulators. Usually, I abhor ignorance (unless it applies to me somehow), but thankfully it’s not simply a misused term stemming from the ignorant, adolescent population on the Internet.

Part of the confusion may come from people in the hardware industry referring to simulators as software that precisely mimics hardware, and emulators as pieces of hardware that are precisely controlled by software. Reread that last sentence since there is a distinct difference in their meaning. For people in the software industry, the terms are a little different. When a programmer attempts to duplicate hardware components through software, it’s often referred to as emulation. Simulation, on the other hand, can be used to mimic the actions of a piece of hardware or software, but the internal workings may be completely different than the original product. It may look and act like an Atari computer, but it’s not really using any of the core components of that machine. Within the realm of software, simulators can also apply to programs which simulate completely different systems such as organic or chemical interactions, economic or disaster forecasts, or the weather.

I’m going to digress for a moment and talk about a simulation used to provoke this global warming hysteria we all are experiencing today. Simulations can be as simple as simulating the periodic movement of a pendulum, or as complex as a weather system. Simulations can also involve complex interactions between other systems, and for these intricate systems to be effective at predicting or postulating outcomes, they must rely entirely on our flawless understanding of how all of these systems work. It’s funny (and sad) to read about simulators which can accurately predict the effect of human pollution on the weather system. These are probably two of the most complex environmental systems attempting to be simulated today. It’s no surprise that even the most sophisticated simulation models used today don’t work, but various environmental groups and political leaders are running with the “evidence” as if it were iron clad proof. The only way they got the simulation to output the desired result was to modify the data going into the system. Now, I’m sure we’re not all scientists here but it should be fairly obvious that manipulating data to validate your own hypothesis isn’t exactly following the scientific method. I don’t want to get off on a tangent here, it’s a good example of simulators being used today and the unexpected complexities that can arise during the development of a simulator.

Most of the time, programmer’s would not attempt to simulate an entire machine, but rather couple the simulation with emulated components. The reason is simple: it’s a lot more work to simulate an entire machine than it is to emulate one. In a simulation, none of the original software for the hardware platform can be used, which means it too must be simulated. Looking at the other side of the coin, we see that pure hardware emulation is also not very practical to implement through software. How does one emulate a hardware bus, for example? The bus is purely an electrical component and has little to do with the purpose of the overall system. Yes, hardware engineers need to implement bus systems, but programmers attempting to emulate the machine can forget about it entirely. Simulation is often used in place of arcane hardware constructs which are part of the electrical system or those pieces which simply cannot be emulated. It acts like a bridge between discrete or unrelated pieces within an emulator so that the emulator can function as a cooperative unit.

When writing an emulator for a video game console, it’s vital to get as much information about the hardware as possible. Doing so will hopefully give you the big picture, and make it easier for you to divide your work into component groups. In a simple system containing only one central processing unit, for example, you will need to emulate the operation of the chip. This includes instruction sets, registers, any available memory caches, and operands, which constitute the general make up for most microprocessors. Advanced microprocessors necessitate advanced emulation, but not all components of a microprocessor need to be emulated in order to maintain accuracy. For example, optimization features used by the chip can essentially be omitted for a perfectly functioning system, unless those pieces modify the data in a peculiar way or they contain a bug which affects the software’s presentation or operation on the original hardware.

Another component group needing particular attention would be the memory subsystem used by the console. The memory architecture used could be as simple as a linear array of addresses or as non-intuitive as paged memory or memory-mapped input/output. The solution chosen for emulating memory should probably favor reading memory over writing memory, since the former occurs a lot more frequently. Some systems, such as the Nintendo Entertainment System, allowed the clever engineers to essentially extend the available memory through the cartridge. They used bank switching within the cartridge to overcome the addressing issue normally encountered when a system attempts to extend the range of available memory than what was originally available.

I could go on and on as there are many other aspects to consider before writing an emulator, such as debugging or functions related to emulation as an application but they are outside the scope of this little write-up.

Categories: Software
No Comments »

So, I downloaded my first Virtual Console game the other day and immediately backed it up to an SD card. The process worked flawlessly but it took a little while for the Wii to save the game. I thought at first it had crashed because the actual game data wasn’t particularly large (about 1 MB for the raw ROM data). After popping the card into a reader for my Mac, it turns out the code/data for the game had grown on the SD card to about 5 MBs. That’s quite an increase and I began to wonder why it had grown in size by a factor of five. There are quite a few opinions as to what constitutes the increase in size on the Internet, and the possible reasons I give you here are no different, but I tried to sift through the possibilities and come up with the three most likely reasons:

• It’s very likely the Wii uses a symmetric encryption algorithm to protect the data, since asymmetric encryption wouldn’t really add to the security of the system in an environment where both the private and public keys would need to be stored locally in system memory. If they wanted to use asymmetric encryption, they would need to move the private key to a remote server in order for the system to be effective. However, one of the design goals for Nintendo probably would have been to avoid a situation where a constantly available connection to the an Internet server was required. In any case, the encryption algorithm used may inflate the size of the data being encrypted, or they may pad to the size of the file for the algorithm to be more effective.
• In order for Nintendo and third-party developers to release self-contained Virtual Console games, it’s likely the emulation software is included with every game. Otherwise, if the emulator was part of the console’s on-board software library, and they decided to patch the on-board emulator sometime in the future, then they would need to re-test every released game with the new emulator. Ouch. Using a pre-installed emulator would also prevent developers from making game specific tweaks to the emulation environment.
• Finally, the game probably includes extra information for the console to display when your at the Wii main menu. For example, it would need a picture and maybe some music or sound effects for the game when shown on the main screen. If this information wasn’t stored within the file, then the Wii would need to decrypt the file every time you accessed the main menu. Given the strength of the encryption algorithm, it’s very likely the process is computationally expensive, and if you owned several Virtual Console games it would need to decrypt all of them before you could see the little preview window.

What do you think?

Categories: Hardware
No Comments »

I am a classic gamer at heart, and I don’t just mean the games made in the 1980s. I’m not opposed to using something better if it’s more suited for the job. Take the Atari joystick, for example. I have used it many times before, and I like the look of it next to my Atari computer or game console, but I don’t particularly like using it. It’s not terribly responsive, prone to wear-and-tear, and uncomfortable to hold. I found the Sega Master System or Sega Genesis gamepads to be vastly more enjoyable. I get the response I want and I can go for hours without those annoying hand and palm cramps.

Categories: Uncategorized
No Comments »

“Radical Express – When it totally, no doubt for sure has to be there awhile previously.” Sigh. You just can’t buy quotes like that anymore. I often wonder if there is still a market for adventure games like the Space Quest series. I’m not just talking about games with elements of adventure thrown in, I’m talking about games with intriguing environments (either dimension is fine), a detailed and enjoyable script, some decent voice acting (if need be), and that’s about it. No flash in the pants particle effects (unless you chose 3D and it happens to fit the story), no multi-player options, no level-editing tools, and a distinct lack of hands-on combat. Although a little combat can be used effectively; just look at the Monkey Island series: “Your mother is a cow!”

Given the recent trends in the market today, it wouldn’t be as large as, say, Halo 3 in North America or even Sim City V in Vietnam, but perhaps there could still be a decent market for small companies on the Wii, Xbox Live arcade, or even somewhere amongst the desktop market? After all, it is relatively painless nowadays to write games for the three major desktops: Microsoft Windows, Xandros, and Mac OS X. A three or four person company could do quite nicely.

Categories: Games
No Comments »

I was ecstatic to finally receive my XGS system in the mail. I pitied the poor programmers who would never experience the thrill of writing software for small devices. Now that I’ve had my XGS system for a couple of weeks now, I find the device rather difficult to program. Not because the programming is too hard, although it is quite a challenge. Unfortunately, It’s difficult to write software for all the wrong reasons: bundled software and documentation.

The Integrated Development Environment (IDE) which is bundled with the system routinely has problems connecting with the XGS Micro Edition (ME) through Windows. Windows says the parallel port is mapped to LPT1 (0x3F8), but XGS thinks it’s on LPT2 (0x2F8). I have to fiddle with the port scanning every time I go to use the IDE. The software has no syntax highlighting, which makes writing assembly code so much easier on the eyes. C’mon guys, syntax highlighting is a basic requirement for any programming editor used today. Writing assembly code is tedious enough without the added frustration of dealing with problems that arise from bleary eyed programmers. Finally, you are unable to debug your code using the XGS ME console and the IDE which shipped with the product. Debugging is possible with an SX Key Programmer (purchased separately), but what I don’t understand is why they didn’t build this feature into the XGS ME when it was designed. Let’s not forget that the device already has an SX programmer built-in , but it just doesn’t have the features of a full SX Key Programmer. The only thing worse than a missing syntax highlighter is a missing debugger. It’s been a long time since I had to trace through a program using a piece of paper and a pencil and I can’t say that I’ve missed it. Bottom line: Writing assembly code is tedious (learning the internals of the system and interacting with it is the interesting part), writing assembly code with no syntax highlighting is even more so, and trying to locate a problem in your software with no debugger available is akin to finding a needle in a haystack (ie: no fun). I will probably end up using an editor such as VIM to write the code and the SX Key Programmer software to compile and debug – it’s just a shame they can’t be the same tool.

The next hurdle is documentation. The physical form of the book entitled Programming the SX-Microcontroller doesn’t come with the system but is provided as an eBook. To be fair, the web site does tell you it’s an eBook copy, which is fine but the copyright on the electronic document doesn’t allow you to print it. I don’t know about you, but I hate reading large books while sitting at my computer desk. It’s uncomfortable, and difficult to browse and reference while trying to write software. Most portable eReaders are not particularly usable, and the ones that do a decent job are too expensive. Assuming it’s a pleasure to read the documents bundled on the CD with an eReader, I just don’t want to spend several hundred dollars to comfortably read a book I already own. Since most of the books provided are out of print now, there should have been an accompanying license which allows you to make your own copy. Even LaMothe’s book, The Black Art of Video Game Console Design, doesn’t go into enough useful detail on the intricacies of XGS ME programming. I found this a little odd since it is featured prominently on the front and back cover of the book.

Finally, I would really like to know what’s going on over at XGameStation web site. For the past couple of months, the site has routinely been down. In fact the down time is so regular, it’s almost like the web site is being hosted on an employee’s machine within Nerve Networks, and that machine gets shut off every night after six. It’s frustrating to try and get at the example software or browse the forum when I’m trying to get a piece of code working, which is usually during the evening since I don’t have the luxury of working on the XGS during the day.

Categories: Hardware
No Comments »

The Photshop artisans over at somthingawful.com have done it again. Today’s Photshop Phriday theme is the Transformers and some pretty ordinary things have been miraculously transformed into robots. Speaking of which, now would be a good time to remind everyone that the Transformers movie is slated to open on July 4, 2007. I’ve seen one of the previews and I just loved it when an ordinary jet plane (Starscream, I think) suddenly transforms and grabs onto a nearby bridge all in the blink of an eye. It’s a real shame real-life can’t be as exciting.

Categories: Toys
No Comments »

The first game I’ll introduce for Mac OSX is called the Doom Legacy project. It is available for other platforms, but I find the implementation for the Mac is superb. I have the 19″ iMac computer and it looks absolutely amazing. It’s also a blast to play with mouse look and fast monsters enabled. It’s like playing Ultimate Doom all over, except this time, the game stopped off at the local store for bad asses and purchased a can of whoop ass.

The new engine can use the resources from Ultimate Doom, Doom, or Doom II. They have added a variety of subtle enhancements which aren’t too over the top. The rendering engine uses OpenGL which looks very nice on modern machines. I cranked the game’s resolution to 1680×1050 and I never looked back.

Expect more information about this game in the future.

Categories: Games, Mac OSX
No Comments »

I’m replaying Space Quest I: The Sarien Encounter and it amazes me that the game has held up for so long. After thinking about it for a bit, and rewriting this entry more than once, I’ve come to the conclusion that it doesn’t matter what technology the game uses, whether or not your board game pieces are made out of pewter, or if the game comes with a secret decoder ring. What matters most is the game itself or more specifically:

Is the game fun to play today? And remember that meaning changes every 24 hours.

This may seem like something obvious, but so many companies miss the boat. I see compilation CDs with several games available for play, but I shake my head when only half of them are fun to play now. They may have been fun a few years ago, when the technology or technique was new at the time, but many just don’t cut the mustard. I see polls for Golden Eye (N64), citing that it should be released for the Wii. Why? Have you played the game recently? I absolutely loved it when it was released. The multi-player games were quick and exhilarating. I played that game with my brother-in-law until my eyes were bloodshot. If you play it now with some friends, you may find it just doesn’t have any appeal. The single player mode is marginally better; the missions are still challenging but it lacks a certain panache. After an hour of game play, you’ll probably be checking your watch or thinking about how much you’d rather be helping Roger Wilco defeat The Sariens once again.

Categories: Games
No Comments »

I was playing Rayman Raving Rabbids the other day and I found it to be a lot of fun. The idea for the game is simple, you progress through the game by making your way through a long chain of mini-games. The game has more of a story to it than Wario Ware: Smooth Moves, but the action is much less intense, which may make it more enjoyable for younger players or adults who find Smooth Moves a little too extreme.

You start the game as a prisoner who has been locked away in a cell under a stadium. You’re hated by crazed, extremely volatile, and rudely demonstrative rabbits. The rabbits absolutely despise you and relish watching you hurt yourself through a series of gladiator style games. As you finish each level, however, their attitudes slowly change. They eventually start cheering for you with banners and noise makers. Hearts fall from the stands and a fan club soon starts gathering outside your door. It’s enjoyable to watch their mood change over the course of the game, and you start to develop a sick satisfaction with punishing your furry friends in the mini-games. After all, these rabbits once cried out for your head to be removed with a rusty chainsaw (I’m guessing here because you can’t really understand what they’re saying).

Despite the ease in which I was progressing through the levels, the dancing mini-game makes the game worthwhile. In this mini-game, you find yourself on stage with bunnies steadily entering the stage to your left and right. In order for the each bunny to leave the stage without incident, a spotlight must be turned on at exactly the right moment. You control the spotlight and if you time it correctly, and the bunny is on the designated spot, then he disappears happily; otherwise, the game warns you to find your groove. Too many mistakes will lead to the power being cut off and the mini-game abruptly ends. The beauty of this scenario is the beat used to control the bunnies stepping onto the stage. There are a number of recognizable songs and licensed songs from artists like Cyndi Lauper or the Misirlou song (also played in Pulp Fiction).

Categories: Games
No Comments »

It’s a tomb, and a hefty one at that. Weighing in at just over 900 pages, the book introduces you to a wide range of topics. Everything from the parts needed to wire-wrap your own prototype board to the intricacies of writing a simple video driver for the XGS Micro Edition console. This pretty much hits the nail on the head when identifying a real problem with the book. It introduces some high-level concepts and components of a simple video game system, but it fails to discuss the design of the XGS system in-depth or any other console for that matter. Let’s face it, electronics is a difficult subject for the most part, just like software development or juggling chainsaws; one book isn’t going to transform you into a hardware engineer even with a suitable “turns-ratio.” However, the book failed to satisfy my technical lust for video game console design and for the details of programming the XGS system.

It skims the surface of many topics, like skipping rocks on a lake. Only the book fails to make a splash at the end. What do I have at the end of the book? Well, several hours of reading and almost $90 (CAN) later, I don’t know how to design a video game system and I don’t know how to program the XGS. So, what did the book teach me? I must confess that I didn’t grasp everything the author was trying to explain during the first reading. In fact, I had to read several sections over, and despite those reiterations, I felt like he was trying to close several topics far too quickly before I could wrap my head around it. After reading a chapter, it wasn’t uncommon to feel like you had fallen asleep for most of the math class and you are now being asked to explain why X + Y = 1. Within the same chapter, the topics jump around from high-level overviews like embedded computer organization to low-level debates on the best way to arrange address lines when introducing RAM to an embedded computer system. There is very little middle-of-the-road material presented to help bridge the gap.

I understand the book probably had a very real limit on the number of pages which could have been published, but why bother condensing it into one text, when a short series of books would have suited the topic much better? Since the majority of the book discussed topics which weren’t necessary for a general understanding of the XGS, then why not write a systems programming book for the console, and a couple of supplemental books discussing electronic theory and practical designs of a console with experiments. I realize it would have taken longer to write such a series, but it also would have been infinitely more useful. Despite the books shortcomings, however, I am hesitant to give it poor marks because there are so few books of this kind available. The book did introduce several new topics which I will investigate in more detail later. The chapter on SSI/MSI blocks and the NTSC/PAL video signal was particularly interesting.

So, what would I have liked to see instead? I would have preferred a much more detailed analysis of the XGS Micro Edition console. Every sub-system should have been explained in detail with additional emphasis on the parts used to build it – not a broad treaty on parts which never made it into the design or were never even considered. The sections discussing analog circuit design could have been omitted and the digital sections expanded, since analog circuit analysis is not particularly relevant to the video game consoles, and the little information that is provided is not enough to be useful. Any additional or optional design decisions could have been provided in an Appendix with a section devoted to recommended reading. Last but not least, the book should have contained much more information on the SX52 microcontroller and how the details of the software system should work. The examples provided in the book are next to useless since there is no introduction to programming for the system. It goes straight from Frequency Divider Circuit Design (section 11.5) to Joystick Design and Programming (section 11.6).

I will probably be referring back to specific sections within the book from time to time, but I can’t see myself reusing most of it.

Categories: Books
No Comments »