For of all, let me begin by saying the GP2X can be many things to many people. You may wish to use it for watching video using their DivX or MPEG4 player, or listen to music using the installed Ogg or MP3 player software, or even set up a web server using the installed version of Apache. However, I would suspect that most people purchased the device because it’s a cool new tech-toy or because they actually want to play games on it. The extra applications can be useful, but if you really wanted to listen to music on the go, why not get a device that is build specifically for this purpose, like an iPod or a clone? The PSP is also better at playing video, so why not just purchase one of those instead? I also don’t want to forget about the Linux crowd, since this is one of the reasons a co-worker of mine purchased the device, at least officially. He admitted to me later on that he really wanted to play Galaga and Space Invaders, though.

Of real interest to me, however, is the ease in which third-party software can be written for the device. As an example, there are a myriad of hardware emulators available for the GP2X. I’m not going to list all of them here, because you can just as easily visit Wikipedia and read about them. There is probably at least a partially functional emulator for whatever platform you’ve got in mind, and theirin lies the problem. Due to the sheer number of amateur programmers who produce free, semi-functional software, finding a program that actually works well is time consuming. One site which helps alleviate this problem is the GP2X Archive. The site is essentially a repository for Gamepark software which includes available titles for the GP32 platform as well as the GP2X. The repository isn’t what makes the site truly helpful, although having a central location for Gamepark related software does make things easier. It’s the various comments left by users and authors for a large number of projects hosted on the site. Not all of them are useful, and many of the comments could use a pass or two from a spelling/grammer filter, but I’m not complaining.

Before you can begin playing your favourite game, you need to find out which platform the game you have in mind actually runs on. If you don’t know that, then you need to do a bit of research first. I have spoken with people many times and most of them have similar reactions when I tell them about the GP2X: “Cool! Can you fire up Ms. Pac-Man?” The question I ask them in return is usually “Sure. Which one?” They usually look at me with a confused expression and ask “What do you mean?” The problem is they have an image in their mind, a game they had played from a long time ago. They haven’t considered that I don’t know what image they are seeing, since many games from the by-gone era of arcade games often ran on several different hardware platforms. Each of those games, although similar in title, usually played quite differently from one machine to the next. An excellent example of this is Pac-Man, which was a brilliant game on an arcade machine but wasn’t very much fun on the Atari 2600.

Once you have the name of the hardware platform in hand, you should visit the GP2X Archive or use the Google search engine to find an emulator that meets your needs. Many of the emulators available are less than perfect, but there are a few diamonds in the rough. One such emulator is the GnGeo2x for the NeoGeo home entertainment console. It takes a fair amount of tweaking and configuration to get it working just right, and the right machine ROMS for your locale (I’m not talking about the games) are very difficult to find. Once you have it up and running, playing NeoGeo software on-the-go has never been easier.

The GP2X is a cool gadget for many reasons (not just the ones I listed above). It’s a completely open platform, and that means possibilities for aspiring programmers who want to work their magic on a portable hardware platform. Sure, there are other portable devices, such as platforms which support Windows CE, and… umm… cell phones. The first choice is too expensive and the other is too boring. Who wants to write software for a cell phone as a hobby? There are far too many cell phones on the market to make that forray very interesting. Not to mention the fact that most cell phones were never designed to play games in the first place.

Categories: GP2X, Hardware
No Comments »

The first Atari 8-bit computers to arrive on the scene in 1979 were codenamed Candy and Colleen, referring to the Atari 400 and 800 respectively. The latter was rumored to be named after an attractive female staff member (she undoubtedly had curly brown hair and lovely chocolate eyes, just like my wife). The Atari 400 was marketed as a gaming system, while its more expensive cousin was seen as a personal computer. The Atari 400 featured a membrance keyboard, which was eventually replaced by a proper keyboard starting with the Atari 800. Much of the “guts” for the 8-bit computer line came from Cyan, the engineering team responsible for the Atari 2600. In a couple of years, they produced three processors for the new computer models: CTIA, POKEY, and ANTIC.

CTIA is an acronyn for Color Television Interface Adapter and was the successor to the TIA chip used in the Atari 2600. It was reponsible for translating the information produced by the ANTIC chip into signals the television could understand. In later machines, Atari replaced the CTIA chip with the GTIA chip which had much more functionality. In addition to the DAC (digital-to-analog converter), the GTIA controls sprites, collision detection, priority control and color-luminance (brightness) to all objects including display lists from the ANTIC processor. Along with all that extra functionality, some GTIA versions made for the European market were buggy due to a PAL processing error.

The ANTIC processor was reponsible for interpreting display lists, which were instructions on how each scan line was to be displayed, line locations, interrupts, scrolling, and indicating where to find resources such as graphics or character sets.

POKEY was responsible for reading the keyboard, generating sound and serial communications. It also provided timers, a random number generator (for sound noise as well as random numbers), and maskable interrupts. POKEY has four semi-independent audio channels, each with its own noise, frequency and volume control. Each 8-bit channel had its own audio control register which selected the noise content and volume. For higher sound resolution, two of the audio channels can be combined for more accurate sound.

The XL versions contained simplified circuitry to help cut down costs and space requirements. The XL versions were also engineered to comply with the new FCC regulations at the time. One particularly interesting feature, called the PBI (Parallel Bus Interface), allowed for unprecedented access to the computer hardware by an outside peripheral. The PBI is a 50-pin port which provides an unbuffered, direct connection to the system bus lines (address, data, control) running at the same speed as the 6502 CPU. Only the 600XL and 800XL computers had such an interface. The XE systems of the day (65 XE, 130 XE, 800 XE, XEGS) came with the Enhanced Cartridge Interface (ECI), instead.

If you don’t have the space or simply do not want the original hardware in your home, there are a few good Atari emulators out there. Atari800Win is an excellent hardware emulator for Microsoft Windows, and is my preferred choice for this platform. Another great emualtor is the open-source project called atari800. Due to the nature of this opensource initiative, it will probably become the leader in Atari 8-bit emulation unless something goes wrong, which is not uncommon for such projects. Obviously the more people who fiddle with the timings and compatibility, the more a project will progress toward the overall goal of 100% compatibility. Whichever version you choose, both have the source code available in case neither supports your favourite platform. One such platform could be the Gamepark handheld device. atari800 was ported to the device some time ago in 2003-2004, but the author has since dropped the project.

If software development is more to your liking, then you may appreciate programs such as CC65. CC65 is a cross-compiler/assembler suite for a variety of destination platforms such as Atari 8-bit and Commodore 64. This cross-compiler will create binary files that are compatible with the desired microprocessor. Compilers are usually complex tools at the best of times, but don’t let that stop you! If you don’t want to program in assembly language, then CC65 will let you write your software using the “C” programming language. “C” is considered a higher level language by many people, but these people obviously haven’t dealt with nested pre-processor macros before. For the more hardcore amoung you, there is always the option of using a native Atari assembler to write your software. You may even be able to use BASIC – don’t underestimate its power! I’ve written several programs using BASIC and the results never fail to impress… myself.

Categories: Atari 8-bit, Hardware, Retro
1 Comment »

Playing games through emulators or virtualization software is one thing, playing them on a real box, powered by real hardware is quite another. The tactile sensation, the whir of the power supply, and the smell of electro-static dust crud slowly wafting through the ventilation is enough to send chills down my spine. Seriously, I can’t stand it.

Besides all of those tangible qualities, there is also the very real compatibility of the games to consider. They may not run perfectly in your emulated environment. On my primary machine, for example, DOSBox does not run any of my computationally expensive games very well such as Wolfenstein, DOOM, Hexen, etc – basically, any 3D FPS game. VMWare may also not produce the sound very accurately (assuming I can even find a way to get audio to work in FreeDOS on the machine I am using). I also found it enjoyable building the machine and locating the parts for it. My local used hardware store was a great help as well as raiding my own closets for any spare pieces lying around. This little venture also helped to ferret out any unneeded parts for charitable donations.

As a bench mark, I used Ultima VII: Black Gate and Serpent Isle, since those two games had very demanding audio and memory requirements. The games also required a decent processing speed, mouse support, and a modern video card supporting VGA graphics modes. When I say “very demanding,” I mean when compared to the technology of the day. If you were to use a machine made using today’s technology, it would simply be too fast. Many games wouldn’t operate correctly and it would be next to impossible to find MS-DOS compatible drivers.

Hardware

The two most important pieces of hardware to consider would be your motherboard and your sound card. You may have noticed I neglected to mention processor and video card. If you pick a motherboard from the same era as Ultima VII, it most likely won’t have a CPU socket (although my RetroBox does and provides a Socket 7 interface) so you would typically be stuck with the on-board processor. The video card is less important, although I would make sure it has a reasonably high number of video modes, and optionally, high-quality video output that suites your taste and matches the capabilities of your monitor. You should also try and get a PCI video card since a 16-bit ISA bus can be a bottle neck for Pentium processors during the early to mid 1990s. The last video card I used in this machine was a Trident Super VGA card. I loved that card, but when I upgraded to a new card sporting a PCI interface the difference in speed was very obvious.

Should you choose to build a machine yourself, I have provided a list of components I used to build mine. You will probably want to alter the list to suit availability and personal preference, but if you choose to build it to my specifications, I can guarantee you the machine will run Ultima VII perfectly:

• GMB-486SPS 80486 PCI Green Motherboard
• Intel P133 Microprocessor
• Sound Blaster 16 ISA Sound Card
• Matrox G400 PCI Video Card
• Yamaha 4x4x16 CD-ROM Drive
• Generic PCI Network Interface Card
• Microsoft Compatible Mouse
• 40 GB Hard Drive
• 3 1/2″ Floppy Drive
• 250W Power Supply

The size of the hard drive is somewhat arbitrary. Forty GBs is a lot of space for a DOS installation. I could install every game in my collection including Windows 3.1, compilers, word processors, and anything else I could find around the house and it still wouldn’t fill half the hard drive, which is why I partitioned the drive and installed Windows 95 as well. I did this more for network connectivity, so that I could copy files back and forth easily (although I will probably forgo the Windows installation and use an Ethernet packet driver and SSH/SCP to move files around). Just remember that hard drives available today will probably not be compatible with older motherboards. The BIOS or your operating system may not recognize your disk or refuse to utilize most of the space.

Remember, you should probably work out an effective way for you to get files from your home network to your RetroBox. It could be more difficult to find a motherboard capable of interfacing with USB devices, and even if you did find one, you would need to install Windows with USB support.

TIP: Some earlier versions of Windows 95 did not support USB devices, so be careful if you’re purchasing a copy on eBay. Another alternative to Windows would be to install FreeDOS – it has USB support, although I am not sure if it would recognize the hardware on all motherboards. The OS is built for old and new machines, so I’m guessing luck is on your side.

Software

I use a number of light weight drivers and utilities to make my RetroBox compatible with Ultima VII. The CD-ROM, mouse, and sound card all require drivers. I wanted a light weight driver and device extension software for my Yamaha drive so I chose to go with the generic CD-ROM driver provided by Mitsumi called MTMCDAI.SYS and extension software called SHSUCDX.EXE written by Jason Hood and John McCoy. For the sound card I use the standard Sound Blaster drivers and related software. For the mouse, I chose something a lot smaller than the typical Microsoft compatible mouse driver. The mouse driver is called CuteMouse; it’s open source and optimized for size. It’s only 6 KBs compared to the Microsoft driver which is 56 KBs – a huge savings!

However, the best piece of software I found was a program called UMBPCI. It only works for specific CPUs, but if you have an Intel P2, P3, Celeron, or Xeon, then they are all compatible since they are all L2 cacheable. Processors which do not work are 486/SX/DX/DX2/Dx4/SLC, 386/SX/DX, 286/SX, or 8086. If you own one of those processors then you may want to try HIRAM.EXE which works in a similar way to UMBPCI. So, what does UMBPCI actually do? Here’s a concise explanation taken from the documentation (it has been edited for clarity):

UMBPCI.SYS extends Microsoft’s HIMEM.SYS by supplying the ‘Request XMS-UMB’ function. Microsoft’s EMM386.EXE does the same thing, when loaded with the ‘NOEMS,’ ‘HIGHSCAN,’ or ‘RAM’ parameters in CONFIG.SYS.

Microsoft EMM386.EXE creates UMBs from the computer’s physical XMS (eXtended Memory Specifications) by virtually remapping XMS to the upper memory area using the Memory Management Unit (MMU) of 386 and higher CPUs. It needs an additional 150 KBs of XMS, 4 KBs of low memory and 7 KBs of UMA (Upper Memory Area) when loaded. It also switches the CPU into protectedmode, which tends to be slower, because it’s necessary to use the MMU. UMBPCI.SYS leaves the CPU in real mode, for better compatibility and faster performance.

Basically what this boils down to is the ability to load all of your drivers and software to a region other than conventional memory. This makes games like Ultima VII, which is a complete memory hog, very happy indeed.

For some games, I also use a utility called PENTSLOW.COM which slows down a Pentium class CPU by disabling branch prediction, v-pipeline, and internal cache. This produces a more even gradient for speed changes, unlike some software driven tools (essentially TSR programs which simply loop) that produce choppy or ineffective speed reductions. I also down-clock my CPU in the BIOS from 133 MHz to 100 MHz which helps Ultima VII cope with the faster processor. You may also wish to use a disk management tool like SMARTDRV.EXE which can help improve the performance of disk intensive software.

For your benefit, I have made all of my batch files, configuration files, drivers and software available to you. Let me know how your RetroBox works out!

Categories: Hardware
No Comments »

I’m very excited. I just received the new game development kit from Nurve Networks which includes the Hydra game console, development book, RAM expansion module (extra), storage expansion module (extra), SX-Key programmer (extra), keyboard, mouse, experimenter board, and software. A friend of mine asked why I enjoyed using the kit despite the obvious limitations when compared to development kits and hardware available today. I rambled something out since I was on my way to a meeting, but after further consideration I find it a hard question to answer.

I’m a huge experimenter. I love the possibilities new hardware and software bring to the table. It doesn’t need to be fancy, it just needs to do something interesting or expose possibilities in order to capture my imagination. I’m not expecting to produce commercial quality games with the Hydra development kit, and despite what the documentation and marketing hype implies, it will not show an aspiring programmer how to produce games on today’s hardware consoles. The technology, development methodologies, and tools are so different, you could spend years writing software for the Hydra game console and be completely lost when asked to write software for an XBox 360.

So why does the kit exist at all? I don’t know what the sales numbers are for Nurve Networks, but if this kit existed when I was a teenager, I would have given or done anything to get my hands on it. That’s right, anything! I would have taken on an extra paper route to earn enough money to buy it. I would have done every house chore my parents could dream up, if only they would consider buying one for my birthday. Even today, I have a genuine technical interest in the device, and something at a more fundamental level which drives my desire to learn and create.

I’m a professional programmer by day. I can afford expensive and powerful development platforms, but I do not tend to use them in my spare time. The reason may be similar to why an artist chooses to use acrylic paints on a cloth canvas instead of water based paints on a paper canvas. It’s more than just a personal preference; it’s an attraction to the art itself. There is a certain intimacy with the hardware which is impossible to achieve using high-level production tools. Sure, the compiler may allow you to graft in a few lines of assembly code, but it’s not necessary most of time and can produce problems later, which is why most companies frown at the practice of introducing assembly code into software for no good reason.

The art of programming can be enjoyed by any skilled software developer using almost any tool or language. That in itself can provide great satisfaction to the designer if everything works out, but the synthesis of hardware and software can produce a masterpiece not often experienced by programmers today, and I suppose the elation which follows is what attracts me to development kits like the Hydra.

Categories: Hardware
No Comments »

A friend of mine wrote an article a few days ago suggesting that emulation may meet its end in the not-so-distant future because the computing power necessary to emulate the new hardware used by today’s consoles would be too vast. I agree with him completely, but I still have reservations about this statement for a couple of reasons.

First, until recently, consoles were always lagging behind computers in terms of pure processing power. Programmers and hardware engineers have always been able to do more with less on static systems like the Nintendo 64 or Turbo Grafx 16. The consoles had specialized hardware in them which could accelerate common operations used by games. Thus, the console stayed with exactly the same hardware during the lifetime of the product but often continued to look good in the eyes of the consumer because of these extra hardware features. Computer hardware, on the other hand, continued to get better but because of complex operating systems like Microsoft Windows, the computer games often had to play catch-up. For example, during the late 1980’s and and 1990’s, a side-by-side comparison would have been difficult at the best of times because the consoles often ran completely different games from the kind played by computer enthusiasts. Not to mention, the computer often had to contend with many more software layers than a barebones console. It was and still is today, impossible for a computer to run a game without some overhead from the operating system, hardware drivers, other applications, etc. In stark contrast, consoles usually had a bare metal operating system with a spartan software architecture; essentially nothing more than a boot loader and perhaps a small firmware BIOS.

In a bizarre twist of evolutionary electronics, consoles are becoming more and more like computers, complete with powerful operating systems (albeit dumbed down and with minimal functionality exposed). Admittedly, these machines do have powerful hardware, but then again, so do modern computers. Another twist is that the software running on these consoles (ie: the games) is becoming more and more compatible with the software used by modern day computers. With multi-core processors, hyper-complex acclerator cards, and virtualized hardware environments, computers running emulation software could map a number of hardware features used by today’s consoles more easily than ever before.

So what’s stopping emulation from taking off? There are a few big, perhaps insurmountable, issues to contend with before we start playing Xbox 360 games on a Mac. First, the games are so much larger, and the software needed to make them work is equally large, which means if you want to run those games on systems which weren’t designed to run them in the first place, you’ll need to handle the hardware issues as well as the software requirements. For example, on an Xbox 360 there are Microsoft libraries which handle such mundane things like drawing menus and windows, handling kernel events, DirectX libraries for input control and graphics acceleration, etc., will all need to be available on the target platform. So, you had better start coding now, and maybe with a bit of luck, you’ll finish before you’re dead. The second big issue is security. It’s complex. It’s big. And depending on the system, it could be distributed throughout the software and hardware in a tangled mess designed to keep people like you from writing software like ZSNES.

Bottom line: if you want to play PS3 or Xbox 360 games while you can still hold the controller, then you had better fork out the cash for a new or used system because those clever teenagers who wrote the early generation of emulation software, won’t be able to make a dent in the new console market.

Categories: Games, Hardware
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 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 »