<< Newer Articles posted January 2005 Older >>

Console ports rant

Consoles are good for one thing: console games. As substitutes for arcade games, they are pretty lame. Granted, things have gotten better since I was a kid. Back then, I'd try to play Donkey Kong or Moon Patrol on a console, and it would be a pathetic shell of the arcade game. Nowadays, many arcade games are based on console hardware, so the ports are much closer.

When I first started getting into emulation, I started with the Atari 2600 emulator Stella. But then I discovered MAME, and realized that I pretty much didn't care one bit about any console games. I used to use the console as a substitute for the arcade. Now that I didn't have to, why would I bother with consoles?

I often see people suggest that to verify something in MAME, someone should try the SNES version or the 32X version or the PSX version. This is completely useless advice, and in fact is outright detrimental to the goal of achieving accurate arcade emulation! Please don't waste anyone's time thinking this is a good idea.

Most console ports are just that: ports. They were done by people with access to the game source code, and that code was recompiled and hacked to run on the target platform. But in order to implement the video and sound for a given console, you pretty much have to rewrite that code -- and those are the exact areas where people are often suggesting to check the console for comparison! Furthermore, gameplay is often tweaked for consoles, in order to make the game more appealing as a console game. And since console ports generally don't have DIP switches, how do you know that the console port is configured the same way as the arcade? The answer is: you don't.

Now, one could argue that if the console port was in fact emulated, then it could be used as a reference for MAME. However, this is also a bad assumption. Those console emulators are written under time pressure and tweaked to run on the lower end CPU hardware that is in consoles. Shortcuts are taken for playability's sake. And once they ship, they are never revisited if a subtle timing error is found or some other minor bug is found. You don't see console authors going back and fixing the old Taito drivers that mostly worked but weren't quite 100% accurate, do you?

In short, if you don't have a real arcade PCB with the real arcade hardware, then you really can't verify anything in MAME in a way that helps us confirm anything. End rant.

Cocktail mode

Spent some time this evening puzzling out how Sega's cocktail mode/screen flipping support works. It's different with every system. Some systems do all the work for you like magic, so you don't even have to change anything (apart from toggling a bit somewhere) when you flip the screen around to display player 2 on a cocktail cabinet. Other systems will do some of the work, but changes have to be made to account for the fact that the hardware doesn't perform a complete flip.

Sega falls into the latter category for System 16A. The most unexpected part is that the registers controlling the tilemap pages are actually stored in a different location (16 bytes earlier) than they are when the screen is not flipped. On top of that, the X scrolling coordinate is 17 pixels off. It looks like both of these problems were fixed in the 16B tilemap chip, since neither special case applies.

I also did a very interesting test with the protected Golden Axe version. I ran the code in MAME up to the point where there are problems moving your player, and logged to a file all the transactions to the compare/timer chip. Then I wrote some 68000 code to run on the real PCB and play back the communications one step at a time, displaying the results along the way. By this technique I was hoping to find some error in my implementation of the compare chip registers. But as it turns out, I'm spot on in this case. This can only mean one thing: the bug isn't due to the compare/timer chip implementation! So it's back to the drawing board to see if I can come up with a new explanation....

My evil twin

Haze now has his own blog. You might recognize the design. ;-)

September is over!

Yes, it's finally true, AOL is pulling Usenet access. Unfortunately, Usenet is pretty much a dried up corpse at the moment, so losing the AOL crowd is probably not sufficient to save it from the rampant spamming and idiocy that makes it what it is today.

I remember being particularly wedded to Usenet back in the early-mid 90's, when there were actual communities of helpful people talking about interesting topics and only moderate numbers of flame wars ensuing on the side. Pretty much every ISP had Usenet access as part of the standard package, and there were really good newsreaders around for all the platforms. Thanks to Google Groups, the content from that era isn't lost, though the interface to it sure has gotten a lot worse, especially since Google's last "upgrade". You can even track down my first Usenet post, which is kind of amusing.

As many of you know, I first got into Mac programming back in the early-mid 90's by writing JPEGView, but I also wrote another utility called uuUndo, which was a very slick uudecoder built specifically to parse multi-part newsgroup posts in random combinations and order, and extract the resulting binaries. I wrote this mainly to interface with NewsWatcher, which was an excellent Mac newsreader written by John Norstad. To test this, we would do the "All Bods" test, which was to use NewsWatcher to go to alt.binaries.pictures.erotica, and then type Cmd+A (select all) and Cmd+B (extract binaries) and just watch the two programs churn through many megabytes of porn.

It was really just for testing, honest. :-)

Compare chip minutiae

Spent some time this evening playing with the compare chip (315-5250) on my E-Swat board. This chip is present on several System 16B boards as well as on the X-board systems, and is used for doing simple 16-bit compares between values. Well, at least it looks simple at the start. For the most part, the implementation I currently have works fine, but it's not good enough to get the remaining few protected Golden Axe sets working. The symptom is that your player is stuck near the top of the screen.

Fiddling tonight revealed a few small details were wrong, but nothing to solve the overall problem. I'll next need to modify my "trojan" program to let you edit the input parameters more flexibly, so that I can try some real values from the PCB.

I also began writing some test code for System 18 that will verify the off-by-one column scroll bug that I am deducing is present on the real hardware. If it's not, then I'm completely at a loss to explain why D.D. Crew leaves a pixel of garbage behind during the scrolling on the attract mode.