12/17/2004: Turned in the first round of the rewritten X Board driver. Most of the games work, but the really exciting part was getting the road layer emulated correctly. Charles MacDonald spent a bunch of time running tests on his Line of Fire board in order to suss out the finer details of how it works. Hopefully a lot of this knowledge will translate as I step back in time to redo the Outrun hardware games and the Space Harrier hardware games. But first, there's still some work to be done finishing up X-board, like figuring out why Line of Fire hangs up periodically and why there are some missing sprites in Super Monaco GP.
12/11/2004: Belated happy birthday to me! (Belated because I wrote this on the 17th, in spite of the date above :-)
12/5/2004: Wow, well, I've really fallen down on the job updating my site. Sounds like something to try and pick up again once the new year comes around. In the meantime, I've been quite busy with some cool new MAME work.
First off, I finally spent the time to finish off the new debugger, and fix the first round of "must fix" problems that came with the new code. I have to say I'm really happy with how it's turned out, and I've got a big list of future improvements that will really make it awesome to use. Already the new watchpoints support has been invaluable in tracking down issues.
Second, as you may have heard, I got myself involved in the Sega System 16 rewrite. The System 16 driver has been for years one of the most hacky drivers, in part because a lot of it was written based on how bootlegs of official Sega games worked. Now that we can finally run the real original code, and now that Charles MacDonald has produced some fantastically detailed documents of the inner workings of the hardware, I decided that now was the time to do things right.
So for the last few weeks I've basically been rebuilding the drivers from scratch based on a common hardware model with no hacks, and things have been going well. So far, the pre-System 16, System 16A, System 16B, and System 18 drivers are rewritten and working better than ever. I am hoping to move on shortly to looking at the Hang On, Space Harrier, Out Run, and X/Y Board drivers, in order to give them the same sort of attention. Those will all require a lot of knowledge from OG's original Sega rewrite for understanding the road layers and how they interacted with the other parts of the game. So basically I've got my work cut out for me for a little while longer!
10/12/2004: Updated my MAME Log to indicate what I've been up to these past 8 months. 10/11/2004: Sorry for the lack of updates recently! I've been busy with a few things, some MAME-related, some not.
As far as MAME stuff goes, an interesting prototype showed up recently, which is generally considered to be one of the remaining "holy grails" for vector fans -- Rock-ola's QB-3. I started looking into adding this to the Cinematronics vector game driver when I realized that I was going to have to make changes to the CCPU core to actually get the game up and running. I went to do that and remembered what a horrible hack the existing code was, so I decided to rewrite it (and the disassembler) from scratch. Once that was done, I went back and rewrote pretty much the entire Cinematronics vector driver as well, fixing several input issues, colors in several of the games, and adding sound hooks for most of the remaining games that don't already have sample support. Right now we don't have samples for these games, but I'm working with Zonn Moore to get them for as many games as we can.
So that's pretty much been keeping me occupied. I've also done some tweaks to the classic Exidy drivers, added a few more Killer Instinct clones to please the kiddies, and have been making some minor tweaks here and there but nothing too major. Someday I hope to finish the new debugger I started a while back, but it just seems like so much work and not so much fun!
As far as non-MAME stuff goes, I've got some initial designs taking shape. A core engine based on some things I learned with my Radikal Bikers emulator (though the engine has nothing to do with emulation) is taking shape, and I've already got three ideas I'm hoping to implement on top of that code. I'll leave it at that for now, and hopefully will have the will to update a little more frequently!
9/2/2004: Uh, no, I will not go out of my way to make the emu work on Windows 98. You're lucky it works as well as it does. Get a real OS, please. If your machine is capable of running Radikal Bikers, it is more than capable of running at least Windows 2000. 9/1/2004: If you think Radikal Bikers is a cool game and wanted to see what it was like running full speed, here is a little standalone emu I whipped up. It was just a fun side project to learn Direct3D 8 and to see if some static recompilation techniques I've been thinking about would work. It's not super-polished, but it works well enough to play a few games. You need at least 2GHz and a 64MB video card to get full speed. 8/9/2004: Oops, I kind of broke the ctrlr support right before I did the final source. Here is a diff fix if you need it now. Note that this will cause the 0.85u1 diff to fail when you apply it, so keep a backup copy of inptport.c before applying. 8/6/2004: Should be a new MAME 0.85 tonight before I head out to California Extreme for the weekend. Keep your eyes peeled. 8/3/2004: Forgot to mention that you might need these as well if you are using custom controllers. 8/3/2004: Getting close to a new MAME release, but we're not there yet. Try out the cool new input port features in MAME 0.84u6. Report problems to MAME Testers. 7/20/2004: After struggling to patch up the input port system with the recent changes, I've finally come to the conclusion that it has been hacked and patched way too much over the years so I am doing a serious cleanup/reworking. While I'm at it, the .CFG files are moving to XML format. Next release should be a big barrel of laughs while the kinks get ironed out. Fun, fun, fun....! 7/9/2004: Sweet, finally the last Seattle game showed up on my doorstep yesterday. There are still some issues to figure out (you can't start a game yet), but the attract mode came up nice and quick. 6/30/2004: Sorry for the radio silence, life has been incredibly busy recently. I'm having a hard time finding the time to actually complete any of my various projects (new debugger, improvements to the MIPS3 recompiler, dynamically generated Voodoo rasterizers). I did manage to actually get in-game in Gauntlet Legends finally, so here are a few screenshots to keep you interested. 6/5/2004: As everyone has probably heard, Haze is taking a break from doing MAME releases for a couple of months. I've volunteered to step in and handle an interim release or two to make sure things keep flowing. This also makes a kind of sense since I'm working on the new debugger anyway, and doing some cleanup in the core as I am wont to do. 6/3/2004: Been a while since I last updated! I decided to take the plunge and start in on the debugger reworking I've been planning for a while. The new debugger relies on more support from the OSD layer to handle multiple windows and text-based drawing, but it allows a ton more flexibility than the old debugger. The cross-platform core is also greatly expanded in capabilities, supporting multiple breakpoints, conditional breakpoints, full-fledged watchpoints, a full expression parsing engine, and lots more. Hopefully I'll have the first pass submitted in the next few weeks, since I'm starting to close in on having enough features implemented to make it a win over the old debugger. 5/14/2004: Woo hoo, I was right! The ethernet controller was the missing link in San Francisco Rush, which is now playable (if you have a 20 GHz computer, of course). Unfortunately, there still seems to be something wrong with San Francisco Rush: The Rock, but hopefully I'll have it figured out. On the plus side, it turns out that a missing ethernet controller was also the cause of Vapor TRX not working as well, so now that is playable. By the way, a number of people were wondering why the Vapor TRX CHD is so big. Well, it turns out that the entire attract mode is pre-rendered movies, which explains a lot! 5/11/2004: Decided to take a breather from core work and got San Francisco Rush: The Rock up and running. It has the same problems as the original San Francisco Rush in that it hangs at the start of the game, but now I finally have a theory for why. The Rush games included an Ethernet controller onboard, and I'm currently suspicious that they want it to work. I've got some rudimentary basics up and running, and they are detecting that there is no cable connected, and then putting the Ethernet controller into loopback mode. Which tends to reinforce my suspicion that their networking model relies on even local data being sent/received in loopback mode. We'll see once I get everything wired up! 5/8/2004: Arrrgh. So I spent about half the week trying to rewrite the MIPS recompiler from scratch, and then remembered what an awful lot of work it was. So I went back to the existing one, which works, and decided to start applying most of the optimizations there. The final result won't be as substantially faster as I would have liked, but I hope I can get a good chunk of the speedups in. So far so good on about half of them, but the most recent one (register allocation of floating point registers and using SSE math throughout) is causing me fits like the off-kilter NFL Blitz image. The games boot now, but their geometry is seriously screwed. Wish me luck in getting things back up and running again. In other news, a San Francisco Rush: The Rock hard drive showed up the other day, and I've got it limping along a bit, but there are still some serious issues to solve before it's ready. 4/28/2004: Looks like the CPU fan on my main computer died, so until my replacement arrives, I'm stuck doing low-speed work using a borrowed fan from a lesser computer. As a result, I've decided to plunge headfirst into the MIPS recompiler rewrite. So far I have about 1/4 of the instructions rewritten, as well as the core control flow analysis. I still need to finish up the instructions, write the final register allocator, and then get it working, so I think it will be a few weeks before I have anything to show for it. I'm currently guessing it will be about 2x as efficient as the old one. I'm also restructuring it a bit so that it will be possible to add an x86-64 backend eventually. The more I do this, the more I realize just how much of a pain in the ass it is to emulate a 64-bit chip on a 32-bit chip. I could be way more efficient on the x86-64 when doing 64-bit math and logic, not to mention that having an extra 8 registers will be quite helpful as well. But the x86-64 stuff is definitely not going to happen until I have some actual hardware, so don't expect it too soon. 4/19/2004: Been making slow but steady progress on the Seattle games. I fixed the sound pitch problems in Blitz 99 and Blitz 2000, and have made some more improvements to the HLE downloading code in the DCS core. I've also spent a little time trying to get my preliminary Vegas driver back up and running. At the moment, I have Gauntlet Legends and Gauntlet: Dark Legacy up and running with sound, but they both die a terrible death when actual gameplay is encountered (either in attract mode or in the actual game). War: The Final Assault is in the same category. One thing I've discovered recently is that the CPU emulation is still the big bottleneck, even moreso than the Voodoo emulation. When the heavy-duty floating point calculations kick in, the current dynamic recompiler is pretty inefficient. I'm starting to think about bumping the compiler to a two-pass system in order to provide an optimization pass that could help out the code quality immensely. We'll see if I actually get around to it.... :) 4/11/2004: Well, the Killer Instinct madness has passed, and I'm moving back into looking at the Seattle games. A short while back one of the two hard drive images I was looking for showed up, so here's a picture of the game up and running. Unfortunately, it reboots when you try to start a game, but the attract mode runs all nice and pretty. I'm currently close to tracking down the remining Seattle hard disk, as well as a disk for San Francisco Rush: The Rock, so hopefully the collection will be complete soon. 4/4/2004: Had to take a break due to some health related issues. I'm still not 100% but I for some reason felt the need to punish myself by fixing most of the Killer Instinct bugs. I'm a bit held up on Super Rider as I'm trying to find a good frequency counter that will count up to 10MHz. I took a gamble at Fry's and picked up a cheapie that claimed to be able to go that high, but not suprisingly, it was just a figment of someone's imagination. It also turns out that Super Rider has some discrete sound components on the board. I don't know how likely it is I can trace out the circuit that generates the sound, but it's just one sound I think (the rest is a pair of standard AY-8910s). 3/21/2004: Snicker all you want at the techniques and my low-rent ROM reading equipment, but it gets the job done. One of the epoxy ROMs was 100% good, one was 50% good, and the third was pretty much garbage. There are still some weird behaviors, but the game feels half- finished, so I might actually chalk it up to quirkiness of the game. I've verified checksums across all the epoxy ROMs and am confident the data is valid at this point. 3/21/2004: Okay, so the trojan was written, I went to burn it onto a ROM and discovered to my great disappointment that my ROM burning computer had bitten the dust. Most likely a power supply problem, but I'd hated that crap computer for quite a while now. The big problem with replacing the ROM burning computer is that my ROM programmer and my GAL/PAL programmer both are ISA devices. Since nobody makes modern computers with ISA buses, I asked a coworker to help me find a local used/recycled computer shop, and picked up a loaded P2-400 with two ISA slots for $90. Assembled the new computer yesterday, burned the ROMs, and success! The trojan displays 256 bytes of data from the epoxy-protected ROMs. Which 256-byte area is selected via the DIP switch on the main board. I have 48 pictures just like this one to hand-verify, but when I'm done, we should finally have a good dump of Super Rider! 3/19/2004: Inspired by the arrival of a second Super Rider PCB last night (thanks to the guy who donated it!), I tried to actually get one of my two boards to come up in my JAMMA harness. Now, I'm not much with a soldering iron, but I did manage to wire up the GND, +5V and +12V connections, as well as the video ground, sync, and red, green, blue connections. First attempt didn't work, reporting a bad VRAM. Since VRAM was on the lower board, I swapped out that board with the lower board from the other set, flipped the switch, and got it up and running! With a working board set, I can now set about to write a trojan that will dump the missing 12k of ROM that is encased in an epoxy block from hell. In the meantime, I spent some time last night trying to figure out the color scheme, and made some good progress. The background and sprites have correct colors in this screenshot (yes, the colors are gaudy ... it's one of the appeals of the original game.) 3/18/2004: Email is working again, feel free to drop me a line. Since I get so much mail, I'm considering starting a mailbag area on the site, because otherwise I don't really get around to responding to things in a timely manner (or at all). So if there are questions you'd like to see me answer, send them to me. If there's enough of interest, I'll try to put something together. You might also have noticed that I shuffled some links on the left side of the page. Nothing really new, just some cleanup (and finally admitting that I'm never going to add a home theater section to the site — only took me, what, four years to admit it?) 3/17/2004: Seems there is a currently a configuration bug preventing my feedback form from working. I've got an email into the site admins to see if they can't straighten out the problem. In the meantime, I've been doing some internal cleanup of the discrete sound system, and have modified the way analog adjusters are handled so that they are saved in the .cfg file. Derrick also managed to figure out why Hit Me was whining, which is a relief because at 22kHz it sounded pretty annoying. 3/9/2004: Well, I thought about working on the Gaelco games' sound, but it's grosser than I had hoped, so I think I'll hold off. The games are slow enough as it is. In the meantime, I've been talking to Derrick "Mr. Discrete Sound" Renaud about the discrete sound system and how I can start getting involved. What I would really like to do is get full sound simulation in Turbo, but that will require some op-amp primitives that Derrick is working on. I did manage to get a start on it by doing the square wave beep sounds, but that's just a tiny bit of the overall mess. Derrick then suggested I try something "easier", looking at Ramtek's Hit Me. Well, it was easier than Turbo, but it had some tricks all its own. I think I've finally got it working now. Along the way I had to add a D-type flip-flop primitive, and in anticipation of Turbo, I'm adding n-channel sound support (Turbo requires 4 output channels). On the Hit Me front, while I had the schematics handy, I took some extra time to fix up some video and memory map issues in the driver. 3/2/2004: After getting Radikal Bikers working well, I decided to figure out what was up with Surf Planet. Turns out they were relying on unspecified behavior of the TMS32031 by placing a CALL statement at the end of a repeat block. They tell you several times in the docs for the CPU never to do this, but hey, I guess if it works more power to them. With that fixed and some rendering tweaks, I'm currently getting about 30-50% of full speed on my 3GHz machine. If I turn off bilinear filtering and run at half resolution, both games are playable near 100%. Of course, I don't have the sound working yet, and that will kill the speed nicely (it's a DCS-like ADSP chip, sorry!) 2/28/2004: Own't. Z buffering and perspective correction are fixed. Just in time to miss 0.78u4, but oh well. Thanks for all the offers of help, but the correct answers turned out be located here. 2/24/2004: Fixed a subtle bug in the TMS32031 core that was causing problems with Radikal Bikers. Now at least all the geometry shows up okay. I'm still at a loss to explain alpha blending, Z buffering, or perspective correction. The incomplete driver should be in u2, so if you know some 3D math, feel free to have a look and see if you can't help me figure it out! 2/21/2004: Updated my MAME Log for the last few months. 2/20/2004: I've decided to take a bit of a break from bending my mind on the 3D texture mapping to do some more core improvements (uh oh....) First thing I recently submitted is a "new" sound device: the DMA-driven DAC. This is essentially what the DCS and CAGE sound systems do. They start their chip's internal DMA controller, point it at the sample data, and let the DMA controller stream the data to the DAC(s). Since I had written this code twice (once for DCS, once for CAGE), and since the Gaelco 3D games use a similar technique, I decided to formalize the code into a new common sound device. The second core change I just submitted last night was a change to make the timer system use integers internally instead of floating point values. This has been on my to-do list for years, and I finally got the courage up to potentially break everything once again with a timer change. Fortunately, my limited testing indicates that things aren't really broken for the most part (except Hard Drivin', which always breaks anytime I change anything, and which I've already fixed). The main reason for using integers is accuracy. With floating point, the more time that accumulated, the more error we would see in the low bits. This was leading to some timing drift and other subtle errors. The new code keeps track of everything down to the nearest attosecond, which, by my calculations, only loses 1 cycle on a 96MHz CPU once every 5 minutes. And that's a case I manufactured to deliberately expose an error. 2/14/2004: Still stumped on the perspective correction, but I managed to figure out how the texture masking works so that text no longer has big blocks on the outside. Turns out some of the ROMs provide a 1bpp mask for certain textures. Also, I managed to get Surf Planet up and running. It's on the same hardware, but with a 68000 instead of a 68EC020. If you know MAME, you'll know that it's kind of a pain to do this because you can't just substitute a 68000 directly for a 68EC020 due to different data bus widths. Now if we can just dig up a Speed Up PCB and send it to Guru, I'll have all of the known Gaelco games on this hardware to play with. 2/13/2004: Updated my Atari Game Numbers list with a few fresh discoveries. 2/13/2004: Well, as long as everything is drawn straight on, it looks great. Unfortunately, the 3D hardware apparently does support perspective correction, so right now everything kind of looks like this. I've spent several hours trying to wrap my poor brain around the parameters to get at the perspective correction, but I'm pretty close to stumped for the moment. 2/11/2004: Palettes and controls are hooked up, I can coin up and start a game. I figured out how the texture data is distributed across four ROMs in little 2x2 squares, which is pretty solid evidence that there was bilinear filtering in the original game. There are still some serious issues with understanding the texture coordinates, but I'm at least confident I'm pointing to the correct texture to start with, given that I can read the text in the service mode. I have a feeling progress will slow down now until I can wrap my head around the math. 2/10/2004: I'm startlingly pleased to see something like this after only a few days work. The 3D chip gets passed 13 values (10 floating point, 3 fixed point), plus 2 additional values per vertex. This is just some connect-the-dots on the vertexes being passed, but it's encouraging to see the pipeline working. I'm still trying to deduce most of the other parameters, which probably have to do with things like texture coordinates, Z buffering, and maybe even lighting (let's hope not!) 2/7/2004: Submitted the finished Driver's Edge driver a couple of days ago. It's not 100% perfect, but I'm tired of trying to understand the hacks they put in so they could use the standard Incredible Technologies blitter chip and make it do some 3D. It appears they modified the firmware a bit so you can specify left and right slopes, and then tacked on some external hardware to implement a Z buffer. It's also interesting how they render the stripes on the road. Each chunk of road is assigned a 5-bit value in the Z buffer, and they render the stripes with a special flag that says "only draw this if the underlying pixel has the same 5-bit value that I assigned to the corresponding chunk of roadway". That was kind of hard to figure out. But the game is totally playable now, and I managed to speed it up to average about 30fps on my P4 3GHz, so it's slower than Cruisin' USA but not in the same league as, say, California Speed. Of course, it looks crappier than either, but hey. After this, I'm tinkering with a few ideas for the next thing to tackle. More news on that later.... 2/3/2004: Z buffering kind of mostly figured out. Still some flags I'm not quite sure of, but there is a background now and not just plain old sky. Unlike the previous shots, this one was done during actual play, not during an attract mode sequence. 2/3/2004: Getting better.... Figured out the faux Gouraud shading on the polygons. There are still some Z buffering issues, which should hopefully reveal the mountains in the background that are getting rendered over, and fix some other annoyances. I managed to figure out the rest of the controls, so the game is actually quite playable if you can see past the graphics flaws. 2/1/2004: Well, the polygons are rendering now, but I think there is some texturing that I just can't figure out. Also, the game (which is, in fact, Driver's Edge, as some have speculated) requires exquisite timing between the main CPU and the two TMS320C31 DSPs. Right now it runs for a few frames and then stops rendering for a few frames before picking up again, leading to a pretty jerky experience, all at the amazing speed of around 12fps on my P4 3GHz. 1/31/2004: After many years of occasional poking and prodding, I've finally managed to get some gameplay to show up! 1/27/2004: One of the biggest challenges making changes to the MAME core is the fact that there are several thousand cases that need testing to ensure that nothing broke. Tracking down problems caused by the new memory system led me to try something new. I've made a couple of small modifications to MAME so that I can use the -frames_to_run option in an automated way to run each game for 1 minute, and at the end of that minute, automatically quit and take a snapshot on the way out. I made these changes to the original MAME 0.78 (before my memory changes), and then made the same changes to the latest version of the code. Then I ran a batch file I wrote that loops through every game and does this automatically, keeping all the snapshots handy, and saving information on any crashes that happen along the way. Last night I ran all the games under MAME 0.78, and tonight I'm in the process of running all the games on my latest code. The current test also does a compare between the snapshot from 0.78 and the snapshot from the current code, to make sure all the games are behaving the same as they were before. So far, this technique has uncovered about a dozen problematic games, and has confirmed that for the most part, things are pretty stable. With luck, there will be a MAME 0.79 in the next day or two once my tests are complete (or maybe before if Haze gets impatient!) 1/21/2004: Whoa, let time slip away from me a bit there! MAME 0.78u6 is out with my latest (and last major) batch of changes. Memory mirroring, easier shared pointers, and combined read/write maps all make an appearance. So far the games I've tweaked to take advantage of the new system have much cleaner implementations. I also made a trip through all the reported bugs, and have fixed the system1.c games (imsorry, raflesia, teddybb, etc), the cvs.c games (cosmos, etc), redbaron, asylum, and tigerh. If there are any newly-introduced issues since u1, please make it a point to log bugs on MAME Testers -- I certainly don't have the time to try everything! Once things settle down, I hope to get back to the Seattle/Vegas games once again! 1/13/2004: As you might have heard, I submitted phase 2 of the memory system rewrite last night, and as a result we have MAME 0.78u4. I don't think this made any games worse than before, but it's still worth testing them all to make sure. I still have a laundry list of changes I'd like to make to the system, but the next step is to get proper clean mirroring support in so that the Sega System 24 games and several other drivers can be made clean. Wish me luck! 1/10/2004: Ha ha, you guys crack me up. 0.78u2 came out today with no new changes, probably some broken drivers, a slight speed hit, and the buzz surrounding it is higher than I've seen for a MAME release recently. Thanks for the attention, though! Actually, it would be really good for everyone to test a bunch of games with the new MAME to find out which ones I broke along the way, and then report it at MAME Testers. 1/9/2004: Whew! Phase 1 of the memory rewrite complete and submitted. There's still a bunch of stuff to do, but all the infrastructure is now in place, as well as most of the wide-scale modifications. I expect 0.78u2 to be ready soon. 1/6/2004: Happy New Year, and a clean slate to match. What have I been up to? Well, I opened my big mouth and ended up making one of those "major core changes" to MAME that takes me a few weeks to dig myself out from under. The general gist is that the memory system in MAME needs to have better support for a few common operations like mirroring, alternate address alignments (bit-, word- and dword- based addressing), and Harvard architecture CPUs like many of the TI DSPs we now support. In order to do this right, I've been going through the memory system and both simplifying it as well as adding the necessary flexibility. I've also made a bunch of naming changes for the sake of consistency. In the end, the changes require me to modify every driver in the system and make some big changes to all of MAME's CPU cores. Current status: everything is compiling and linking, and most games work. I should have most of the remaining kinks ironed out in the next few days, and we'll probably have some sort of intermediate build to get the changes into the system.