MAME: Giving up - sort of...

After putting way too much effort into the EPIA 5000, I've decided to give up and try a different hardware approach. I happened to find an old Dell P4 in the dumpster at my apartment building. It uses RamBus RDRAM and only has 512MB. Upgrading RamBus RAM to 1GB costs somewheres around $1000. I'd have tossed it myself!

Digging through the AdvanceMAME documents, I saw several comments about video and sound card compatibility. While AdvanceCD and AdvanceMAME for Linux work quite well with the video and sound hardware in the EPIA 5000, I just happen to already have a Matrox G400 sitting idle in a box. I bought this card originally because it was _THE_ card for multiple monitors in Xfree86 (pre-2.0). But since I've been mired in Windows for the part part of the last decade, the card's gone unappreciated. Fortunately I didn't through it away! It turns out that the Matrox G400 is also _THE_ card for AdvanceMAME. According to the docs, it'll even drive a 15Khz arcade monitor like the ArcadeVGA adapter.

I could stick the Matrox G400 into the EPIA 5000. It does have one PCI slot. But I'm also fighting sound card issues. The EPIA 5000 has DOS support but for some reason, it's not working on mine. So I jumped on eBay and ordered a true-blue SoundBlaster PCI128 card that is well-supported in all flavors of AdvanceMAME and MAME in general.

Assuming there's room in the cocktail cabinet, I'll be sticking the entire Dell into the box with the Matrox G400 and SoundBlaster. Since I'm putting more hardware in there than I originally intended, I may add a jukebox function.

More MAME

AdvanceCD had one big problem - it couldn't save settings between runs. I tried AdvanceMAME for DOS and had decent success but I still prefer original MAME. I ended up regressing back to MAME 0.86b. For some reason, later releases were very, very slow to start (about 45 seconds vs. 5 seconds for 0.86b).

I also tried out a dozen or so front-ends. I decided on another classic: MAME Cocktail Frontend by Mike Billings. There are flashier front-ends out there, but this one works the best with my combination of hardware and software.

Next, to get the games setup!

MAME and the Via EPIA 5000

I've begun working in earnest on my MAME Cocktail Table. The first step: getting a minimal OS and MAME install that supports the video and audio built into the Via EPIA 5000. I got this motherboard for the first pass at my Balloon Aerial Photography project and ended up shelving it.

The Via EPIA 5000 is the perfect board for a MAME machine running classic arcade games. The 533Mhz CPU is too slow for most advanced games but I'm only interested in Pac-Man, Galaga, Donkey Kong... You know - the real classics of arcade. Coupled with an IDE Compact Flash Adapter, you get very low power draw and no moving parts. The motherboard board also has two USB 1.1 ports and supports booting from USB-Floppy and USB-ZIP but not USB-Hard Drive.

I've been experimenting with different operating systems. The main MAME reference build is developed for Win32 and DirectX 8 but there are compilations for Linux and older compilations for DOS.

I started with DOS and got a nice boot working with DOS 7.1. Even though Via provides DOS-based drivers for the sound card, I couldn't seem to get sound to work in MAMED (MAME for DOS).

When I used this motherboard for BAP, I actually used Windows ME. I know it's the bastard step-child of DOS-based Windows, but it's well-supported by VIA. I set this up and got working except that the reference compilation of MAME ran really, really slow.

Then I checked into AdvanceMame and the AdvanceCD. AdvanceCD builds a Linux boot partition (FAT) with AdvanceMenu and AdvaneMAME for Linux already setup. The AdvanceCD build even includes MAKEBOOTFAT and can format a USB stick as USB-ZIP. Using the simple MAKEUSB.BAT resulted in a USB stick that the Via EPIA 5000 would boot and automatically start up AdvanceMenu. The AdvanceMAME handled the video and audio almost perfectly. In fact, the only drawback is AdvanceMAME includes many low-level video tweaks that smooth out the old low-res games on newer high-res monitors. I want this to look more like the original! I also need to figure out how to get AdvanceMENU to work in portrait-mode for the cocktail table.

One drawback of the USB stick is that the controller is only USB 1.1 and the boot process is really slow. I dug up an old 48MB CompactFlash card and used MAKEPART.BAT. Using this with the IDE Compact Flash Adapter sped up the boot-time immensely.

Jango

Recently I managed to get all of my CDs ripped to MP3 and reasonably organized into about 100GB of disk space (I probably should go back and re-rip to OGG Vorbis). I've always been a fan of album rock and prog rock, so I'm not to hot on shuffles. I also have pretty diverse taste, so a shuffle could give me Metallica followed by Brahms. Generally, I've been displeased by the end results and almost prefer the idea of sticking a CD into the CD player.

Then I found Jango. Kind of like Pandora but a little more customized, Jango let's me build "stations" based on artists and interjects occasional songs that it thinks are similar. So I get all the goodness of a fixed group of artists with the occasional randomness of a new artists but no commericals! Unfortunately, it's still ruins the concept of album rock and many of my favorite artists aren't available.

On the positive side, it lets me further explore eliminating the things that I keep that I mistakenly think "define me". I recently routed through my bookshelf and removed all those books that I kept because I felt that, if someone were to browse my bookshelf, they'd get some clues as to who I was. Of course, I realized that person might just think "this guy has too many books"!

Fuzzball for President

Languages getting in the way of communication...

I'm back at the computational geometry stuff. This time, I want to find the minimum bounding rectangle (MBR) of a given convex hull. I've found a few spots that discuss the pseudo code (using rotating calipers) and then I went looking for source. Like so many times before, the algorithm I want in every example of source code I've found is obscured either by user interface code or simply complexities of the language for dealing with non-standard types. Urgh!!!

However, since the rotating calipers approach can be used for both finding the MBR and determining the intersection of two hulls in linear time, it'll definitely be worth my while to figure out my own implementation (which will be sufficiently obscured by the details of my own non-standard types ;P).

GeoWanking

From the Geowanking listserv discussion of Google's MapMaker:

Too often post modern theory replaces good solid empirical research.

Many of the Geowankers are contributors to OpenStreepMap, which has a similar goal of expanding mapped areas through CrowdSourcing. The debate stems from ownership of the resulting map data. OpenStreetMap serves up the data as raw features licensed under CreativeCommons whereas Google only allows access through their Google Maps API under their own license.

C++ STL::Vector iteration

So I've got this mess of code that relies heavily on STL vectors. I'm currently using the .at(n) method to iterate through the vectors. I've stuck with .at(n) because I frequently start iterating at the second or third element and sometimes iterate backwards. Using .at(n) provides a little more consistency to my loops, relying on my for() parameters to specify the ordering of the loop. Should I be using the explicit vector iterator? Is it faster? It's claimed here that both methods are O(1).

I just ran my code under the GlowCode profiler and it claims that a sizable amount of my execution time is spent in .at(n).