Resurrected Entertainment

Archive for the 'Hardware' category

How to fry Bacon on your Lap

June 28, 2009

Here I am in an air conditioned house on a Sunday morning playing a nice game of Contra III on my Macbook Pro and I’m sweating. Why? Because my Macbook Pro runs only slightly cooler than the surface of the sun. Ok, that’s an exageration, since the sun only run at 9800 degrees Fahrenheit, so my apologies to any astronmony group members out there who might have been offended.

I would love to know is if the new Macbook models (2009) run any cooler than the original Macbook Pro models sporting the Core 2 Duo 1.X GHz processors? Also, since I don’t have the money to drop on a new Macbook right now, I would love to hear more information about a store which allows trade-ins of used Mac hardware in Canada. Any ideas?

Development Hell, Part II

July 4, 2008

Ok, so after creating a proper boot disk on a Mac computer, which would have been a pain in the neck if I didn’t have Windows XP installed in VMWare Fusion, and moving the BIOS reflashing software and image onto the diskette, I slapped the diskette into the floppy drive and fired up the machine. Nothing happens as the system refused to boot using the diskette. The 3 1/2″ drive was the “B:” drive and, of course, this particular BIOS doesn’t recognize the “B:” drive as a candidate drive in the boot sequence. Normally, I would have just used the “Swap Drives” option in the BIOS, but if you’ve read the last post, you’ll know my BIOS seems to have a bad case of Alzheimer’s. With my back against the wall, I knew the only option was to tear my carefully installed ribbon cables apart, and after the customary floppy drive error due to misaligned cable, I was ready to begin the process again. Knowing I was nearing my goal, I hurriedly rebooted and began flashing the EPROM with all haste. After following a few poorly worded prompts and trying to digest the jumbled documentation, the process was complete at last. Content with the success of the operation, I rebooted the machine and waited for the uncorrupted BIOS to work its magic. Exhausted and more than a little frustrated at having to reconfigure the BIOS for the twentieth time, I was treated to a marvelous sight:

“CMOS Checksum error – Defaults loaded.”

Development Hell, Part I

July 3, 2008

The Heart of the Beast I want to build some software I received the other day, and I’ve been trying to resurrect one of my older boxes as a development machine after it failed to boot. First it seemed to be a power supply issue as one of the hard drives was failing to spin up correctly. After changing to a different supply and more power, it still refused to work correctly. I began to suspect the hard drive, so I imaged the disk using Mac OS X via the dd command, which was horribly slow but did make a successful backup. Once the backup was transferred to the new drive, again a very slow process, I shoved it in and turned on the juice. Sadly, it still didn’t boot. By now, my wife is chiding me saying I should just toss it and use something more modern. I immediately reversed my polarity and deflected those negative comments back at the beast (of course, I mean this in the best possible way, like a cute little beasty-weasty for example). Refusing to give up I focused on the new error glowing steadily on the monitor.

“CMOS Checksum error – Defaults loaded”

Usually this is caused by a dying battery. Rolling up my sleeves, I went and bought a replacement, cleared the CMOS, saved a new configuration using Award’s snazzy 1997 BIOS interface and… presto! Nothing changed. I tried this a couple of times with no luck. Before I reset the CMOS, I noticed something odd. It seems the jumper was set in the clear position for a while. I’m not sure for how long exactly, but the last time I exumed the motherboard from the old chassis I seem to remember the jumper falling off. With my attention focused on something else, I guess I just slid the jumper back on without checking the configuration. I’m wondering if that eventually lead to a small corruption in the original copy of the BIOS. Will a simple reflashing solve the problem, or will it lead us down a different path? Stay tuned for another exciting episode!

Portable Computer Console

March 9, 2008

AcerPower 1000Computers like the Atari 800, Commodore 64, or Amiga 500 share a special place on my gaming mantle. The specialized sound and video hardware can make all the difference when experiencing old and new games alike. However, there are times when they really begin to show their age. Of course, being old is never a problem here, but it is when you’re trying to mesh the old with the new. Take the Atari 2600 console, for example. I just recently installed a nice little hardware upgrade which provides the console with the technology to output a composite or s-video signal. The composite signal looks good on a normal television; the colours are clear and sharp and the signal is strong and healthy. When I  plug the cable into my high-definition television, suddenly things start to go very wrong.This doesn’t necessairily mean it’s the console’s fault or a poorly installed hardware mod. In this case, it’s probably something the television is doing. Most high-definition televisions have electronics which pre-process the video signal before it is sent to the display. These processes, or filters, can help clean up the signal or enhance it to make it look good on your high-definition screen. The hardware is normally tuned to your specific display, so the number and quality of the filters can vary from television to television. One of the downsides to this technology can be increased blurring, shifting, or muted color when you’re trying to view a low-definition signal, or a signal that the hardware deems to be unclean or poorly formed. The filters kick in to help fix the problem but it really only serves to exacerbate the situation. Some of the filters seem to designed for higher resolutions, and only serve to degrade the visual quality of the lower-definition signal coming from your console.

Wouldn’t it be nice to have crisp, clean, beautiful colours shown on your high-definition television? Of course it would, and there are options available to you. One option is to support the services which provide these games to you on your high-definition console. The Nintendo Wii and Microsoft’s Xbox 360 both provide on-line shops for you to buy these titles. However, when compared to the sheer number of classic games available, the companies simply do not have the money, desire, or the ability to offer anything more than the most popular titles for the most popular consoles. Sometimes I like to play games which will never be discussed in the forums, and I would bet one of my cats that these titles will never see the light of day through these services. It’s not a case of simply choosing one over the other; I support these services whenever I see a title I would enjoy playing, but the release cycles are too few to satisfy my gaming needs.

The solution for me was the personal computer and hardware emulation. I had specific requirements for the physical size, number of available ports, and driver compatibility. Those were the three biggies. I could ramble on about the time I spent searching and testing different machines, but I won’t bore you with that. No, you’re reading this blog for results. The machine I chose to go with is the AcerPower 1000 computer. It’s smaller than your average DvD player, performs well using under low power consumption, and runs very quietly. It also  has oodles of USB ports for lot’s of expansion possibilities. I needed the machine to support at least two joysticks (along with the USB keyboard and mouse), and I wanted those ports easily accessible. The AcerPower has four high-speed ports right in the front of the machine which was perfect for my needs. It also has 3D support using an nVidia GeForce 6150 chipset and full environmental audio; I tested the graphics chipset with the Ion Storm’s  Deus Ex and it ran very well at 1024×768. So long as the software can support one of your television’s video modes, everything should work out alright.

Wii Hardware Hacks

February 7, 2008

Johnny Chung Lee has come up with one heck of a hardware hack for the Wii. In fact, it’s the first hardware creation I’ve seen which actually looks fun to use. If I were one of the boys at Nintendo I would be trying to work out a deal with Mr. Lee over the design rights, or even offer him a job within my company. I can see so many possibilities with such an invention. Anybody remember a little thing called Virtual Reality? I have visions of Lawnmower Man all over again, only this time Jeff Fahey isn’t cutting lawns with his shirt off.

SX-Key Programmer and the XGS

September 17, 2007

SX-Key Programmer from ParallaxI tried to use the SX-Key over the weekend to upload binaries and run or debug them via the SX-Key IDE. Unfortunately, there seems to be a timing problem when I run the programs. If I assemble and upload the binary using the XGS ME software, the program works just fine. I’m going to compare the generated files when I get home tonight. Hopefully, I will find a difference between them which could account for the difference in operation; otherwise, if the porgrams are the same, it would imply a defect in the hardware, which is a lot more troublesome to diagnose (at least for me since I am not a hardware engineer).

I posted my problem to the XGS forum and received a few pointers from the designer, André LaMothe. As per his recommendation, I have reseated the oscillators to no avail. I’ll have to keep the coffee pot hot tonight.

Update: I did not realize the SX-Key “Run” command simply assembles, uploads, and sets the clock. You must still switch the XGS into run mode and reset the system. This is different from the “Debug” command which does everything the run command does, but it uses its own clock instead of the clock found on the XGS which allows the program to run without switching the XGS into run mode.

GP2X from Gamepark

September 12, 2007

GP2X HandheldFor 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.

Atari 8-bit Computers

Atari 800 XLThe 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.

Building a RetroBox

July 7, 2007

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.


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.


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.

UMBPCI.SYS creates UMBs (Upper Memory Blocks) using the existing system memory intended to be used as Shadow RAM, but disabled by default, only in the C800-EFFF range, not using the address range B000-B7FF. That particular memory area is normally used for monochrome video (used by older graphics adapters), not for BIOS (ROM) extensions, therefore X86 chipsets cannot enable shadow RAM within this region. UMBPCI.SYS enables this memory and disables its write protection.

UMBPCI.SYS takes only 240 Bs of conventional RAM (224 Bs code + 16 Bs environment), while providing up to 629 KBs of free conventional memory, provided you’re loading all the devices/drivers/TSRs to use high memory!

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!

The Hydra Development Kit

July 5, 2007

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.