Birth of a New Box
Category: MAME'd Marble Madness :: Cabinet News & Updates
I've added this new page to begin covering the development of my second cabinet. The basics are described on the news page.
When I left off, my corny new cheap case had arrived from NewEgg and I was about to build the machine. Quite a bit has happened since then, so I'll hit the highlights (such as they are) here.
I downloaded the ISO images for Fedora Core 2 Test 2 and burned the four CDs. That release had a few minor issues with booting properly from the CDs on certain Athlon systems, but I tracked down some workarounds. After that, I was having some odd lockups during the install process but eventually determined I had a bad stick of RAM. After a few hours of diddling around and thoroughly annoying myself, I was relieved to get the box built.
The new system on my workbench getting exhaustive RAM tests.
(click to enlarge)
This system is running the 2.6 series linux kernels which are new. I'm quite impressed with the improvements over the 2.4 series I've been using so heavily for a couple of years. I built a custom kernel on it pretty quickly (which is a vastly improved process in 2.6.x), so the box is now running the latest 2.6.5 release.
After getting the kernel in place, I downloaded the source for the latest AdvanceMAME 0.81.1 and did an initial build. Because there are so many variables, the easiest approach is to get things functioning on the attached SVGA monitor before tackling the 15 kHz stuff. I ran into some odd problems right off the bat.
I was getting various lockups and segfaults. After some testing on and off over a couple of days, I discovered that AdvanceMAME 0.81.1 did not like to be linked against the FreeType2 2.1.7 libraries that are part of Fedora. This initially seemed to be the least likely possible cause, so I naturally I tried a zillion other unrelated things beforehand such as removal of the pthread options, etc. (Note to self: strip the compilation down to the bare bones FIRST and build up from there next time.) A more detailed description of these discussions are covered in these mailing list posts.
For those that might find it useful, my final build is based on these compile-time options:
./configure --prefix=/usr --disable-oss --disable-mevent --disable-jevent --disable-kevent --disable-sdl
I also have posted copies of my kernel message ring at boot time (dmesg) along with the various rc files and logs generated thus far in testing. These can give you some insight into the particular config of this hardware to date.
Along the way, I purchased an inexpensive Creative SoundBlaster 16 PCI card when I thought there might be some performance issues with the motherboard VIA 8233 hardware. In the end, Andrea Mazzoleni has assured me the log entries are scarier than they look. I've not decided thus far whether to keep the new card or take it back. I'll probably hang on to it since I suspect it is better in the long run.
One of the significant differences in this system is my desire to use the framebuffer drivers in the kernel over the aging svgalib code that I rely on heavily for my other machine. I am using a Matrox G400 AGP card and making use of the framebuffer drivers has a few advantages including the ability to generate a very usable linux console at 15 kHz. This means I will be able to see the OS on the arcade monitor, albeit a fairly low resolution view with some chunky fonts. At boot time and when doing tweaks, though, this is a huge advantage. My other system is not built to generate anything but game and menu video at 15 kHz and is not usable during boot time or within Linux itself. I have to hook up a normal monitor in those cases (which is why I keep it on the network for most behind-the-scenes adjustments).
Speaking of 15 kHz video... I have done some initial testing with good success. I took a few minutes the other night to plop the case down next to my existing machine and hook up the arcade monitor. The console works well and a few key games I tested look quite nice in their full horizontal glory. The main problem, though, is my monitor is mounted vertically, so it hurts my neck to try to look at it for very long.
To really test this, though, I will need to make monitor adjustments around this hardware and I don't wish to fiddle with the monitor that is tweaked for my existing vertical system.
I have covered a lot of ground very quickly compared to my last project. Much of this is due to previous experience, but quite a lot of it is due to improvements in the AdvanceMAME and Linux environments.
First off, the framebuffer drivers for the Matrox G400 appear to be very solid and flexible. One of my biggest headaches on the first project was getting a stable combination of the video hardware and some very precise svgalib magic. There were also instabilities at that time that had to be cleared up with patches I was not initially aware of. This had me chasing ghosts for days. For comparison, see the issues covered in the video config information from the first cabinet.
I'm trying to stay a little ahead of my immediate needs so I don't hit too much of a standstill as this progresses. Last week I ordered key parts from Ultimarc. This includes the interfacing hardware in the form of one OptiPAC and one I-PAC. This time I am going to go the USB route (vs. serial and PS/2). In anticipation of settling on this method, I bought spare USB cables in this order to use on my other system when I begin backporting my improvements to the first cabinet. You can read about how I used them before in the interfacing section. The parts arrived today.
I also ordered another new (refurbed) Wells-Gardner K7200A monitor. This one is a horizontal mount as opposed to the universal mount I used last time. I hope it gets here this week so I can start major video testing.
