The ‘Almost’ Crowd

There are a couple of drivers I’ve been working on lately which are *almost* right, but at the same time still have a long way to go.

Starting with Black Touch ’96. BT96 is a Korean Beat ’em Up and a driver I started a long time ago. The video system is a bit funky, so so was the focus of my attention. Essentially there are sprites, and tilemaps, but the confusing thing is that the sprites aren’t really sprites at all, infact they just appear to be 4 additional tilemaps with positional strips, however they must be rendered as 4 distinct layers in order to get the priority correct (in terms of list order the background sprites end up sandwiched between two of areas containing character objects) There’s also RAM for another 4 potential layers, but it never seems to be used beyond the initial RAM clear / initialization (and I’m guessing it doesn’t work on real hardware)

I think this video setup, along with some shoddy programming caused issues for the developers of the game, it seems to have a number of bugs, including one where if you attack the enemy with your kick attacks at the top of the playfield you can cause them to fall into, and start walking through the background, complete with momentary priority glitches because the rest of the code really isn’t sure what’s going on. There are also various bogus ram writes to unmapped areas, I’m assuming these are just bad / buggy code, maybe they should end up going to a RAM mirror, but that isn’t clear. Amusingly the Seibu games act in a similar way with bad protection emulation (incorrect collision boxes and movement calculation code causing enemies to walk off-screen) but these tasks aren’t handled by any kind of protection in this game.

Anyway, before the last ‘u’ update I made some improvements to the sprite system incorporating the new findings and also improved the tile layer which is equally deceptive. Tile RAM is written as 16-bit, but the upper 8-bits really don’t seem to matter, the upper bits of the tile number are instead controlled via a bank register, I’ve added support for that, fixing (I hope) the text on the story screens.

The sound is handled by a PIC ‘MCU’, which thankfully we have a dump of because it was one of the old games which actually got decapped, and for which the MCU serves a useful purpose. The bad news is I’m entirely unfamiliar with the PIC series, and haven’t managed to hook it up, I did put in a request to the rest of the devs but haven’t heard as much as a peep back over it, so I’m guessing there are no devs familiar with it either.

So why isn’t it working? Well the major remaining issue is that the timer doesn’t decrease, I wonder if the PIC is involved in this as well as sound, but it could probably do with some tracing of the 68k code to find out if there isn’t a more simple explanation. Obviously the sound could do with hooking up too. You can play it, I’ve played through a few levels (and you even get a Bikini girl between each level like so many Korean titles..) but without the timer I can’t really consider it to be working.

As a game, it’s terrible, the screenshots below make it look better than it is.

The second game I’ve been looking at, albeit indirectly is Tecmo’s World Cup 94.

I say indirectly because I’m in the middle of doing some work to all the Video System drivers, as I believe I mentioned in the 3-on-3 Dunk Madness post below. I’ve identified 3 main Video System sprite systems, 2 of which are used on a wide variety of games. Like many early things in MAME which haven’t been touched for a while every game had it’s own implementation of the sprite chip based around what that game, and only the game needed, needless to say most of these implementations were incomplete.

By unifying the code I’ve not only managed to fix the problems with 3-on-3 Dunk Madness player sprites (still some tilemap priority bugs I need to fix there however) but also Tecmo World Cup ’94 has seen benefits from this in two ways.

First of all the players now correctly get rendered in the attract mode, previously the code was actually ignoring half the Sprite RAM because Grand Striker (the game the driver was originally done for) doesn’t use it and we were masking too many bits of the index. The code was also using the wrong sprite enable bit, which was leading to random stray shadows and injured players getting stuck on the screen, that’s also been fixed. Furthermore because the zooming code for sprites has been unified with the other implementations which are apparently more accurate, you no longer get sprites breaking up when they zoom to full-size. There are still some flickering sprites when you score and at the end of matches, but that might be an original game issue.

What’s wrong here? Protection. We currently have a protection simulation, but it’s imperfect. The game always thinks it’s the first match, the attract sequences probably aren’t in the right order (it displays ‘INSERT COIN’ over the high-score table erasing some parts of the text tilemap, which looks glitchy) and I’m not sure the ‘EVENT’ handling logic in the game works because it seems to do nothing if you compare it with the NeoGeo Tecmo World Cup ’96 released 2 years layer.

The protection is annoying because the original hardware MCU performs some kind of checksum on the main code, which means you can’t modify it, however, a ROM banking trick similar to what was used on DDP2 might get around this issue, by manually controlling the upper address pin on a double sized ROM it might be possible to get our own code running, and at least explore the jump addresses returned by the device during attract / gameplay and determine if the protection glitches we have are due to wrong jump addresses or something more (on V-Goal Soccer, which is the same hardware, it appears to control various counters directly instead)

There’s also the issue of the zooming tilemap. Tecmo World Cup ’94 makes light use of it, but you can still tell the implementation is wrong (things don’t align correctly in the various zoom states). Grand Striker and VGoal Soccer make more extensive use of it, and with those you can really tell how bad it is, and no matter how many times I’ve looked at it I can’t make any real sense of it, it feels like something must be non-linear at some point in the algorithm and even if I adapt the code to get the ‘Zoom into Stadium’ part of VGoal Soccer looking better the game is still broken. (I’d love some original videos of V-Goal Soccer for that sequence, but it never seems to show up) Due to these things I’ll probably demote Grand Striker to non-working too, the pitch has never been right, and what I thought at the time would be a quick fix from Imperfect Graphics to ‘fine’ turned out to not be a quick fix at all, essentially meaning the game has never worked.

Anyway, I just wanted to highlight that work does happen in MAME even if it doesn’t directly lead to more games being tagged as working in the immediate future; every little bit of progress does however bring us closer to ‘working’ and sometimes, as demonstrated here *real* refactoring and merging of old code can sometimes help.

In other news Luca, as expected got Sparkman going which means all the dumped SunA games now work.