Another medal game with a Tekken theme is now emulated. Thanks to ShouTime, with help from the DU and a few MAMEWorld folks.
It's Tekken Battle Scratch (鉄拳バトルスクラッチ), the '98 sequel to Tekken Card World, which was featured here a few months back.
This is a video of the actual Namco cabinet and game play:
This time the control panel does sport a joystick, but don't get excited. Alas, there is no actual fighting action in this coin pusher as well. Have some MAME screenshots:
I believe this is the only other game in this series.
Thanks to ShouTime, Jan Stuhler, pablopelos, Smitdogg and The Dumping Union
Few will remember the Dark Horse bootleg I worked on in 2005.
Anyway, that horse betting game was based on an original title by Seta, pictured below:
Jockey Club II (ジョッキークラブ II)
Back then the original hadn't surfaced yet, but a couple of years later Gerald (COY) provided dumps of the original roms.
An additional dump was also provided by ANY in 2014 (none were Visco licensed as the flyer would imply, by the way,
unlike the original Jockey Club in seta.cpp).
At any rate, they never really were devoted enough attention to transition to a working state. I guess the fact that the bootleg worked
took away some of the challenge, too.
0. Hardware
The dumps came from two types of PCBs and several software revisions, sign that the game had good commercial success.
The older hardware PCB was based on the ST-0020 Seta custom for graphics, which I emulated
around the same time for Mobil Suit Gundam Final Shooting.
Plus an ST-0016 for sound (Z80 cpu + sound + video, Dox's work). The other ASICs are ST-0013 (exact function unknown)
and ST-0017, which may be related to I/O. The older PCB should look similar to this sample:
Older PCB: ST-0020 (under the heatsink) + ST-0016
The newer PCB instead used an ST-0032 chip, an updated version of the ST-0020 that includes sound capabilities,
thus doing without the ST-0016 and reducing the cost.
The ST-0020/ST-0032 provides some nice zooming sprites, which the Gundam game above uses extensively (see gdfs in ssv.cpp).
This game not so much, zooming isn't actually used i.e. the horses are pre-rendered at each size in the graphics, as Dark Horse shows.
1. EEPROM
Up to now you were greeted with an ID Error message when running either of the two existing sets on the older hardware
(jclub2o, jclub2ob) and with Broken Configuration on the new hardware (jclub2). What those messages actually mean though,
by looking at the code, is that the software is not happy with the data found in the EEPROM.
The latter chip in fact holds programmable non-volatile data such as the game configuration.
But, as a form of protection, it must also contain an ID string supported by the software for it to boot.
Now, we do have dumps of the EEPROMs from both PCB revisions from two specific game versions. But for newer hardware sets,
most will not boot since the dumped ID is from a later game version. For the older PCB, though, I found there was another problem,
a subtle difference between the Seiko S29290 EEPROM chip used and a standard 93C46-compatible serial EEPROM.
So the 1st thing I did was to add support for this variant with the help of the datasheet, which fixed the EEPROM check
in the self test screen.
2. Software Revisions
Thus the 2nd step was to split the existing sets properly, by hardware and software revisions. As I said the ID is tied
to the software version so an earlier revision won't be able to boot with an EEPROM from a newer game version.
It turns out we have roms for 10 (!) versions of the game, including a prototype (Release Candidate):
Older hardware:
v1.00 ('94)
v1.01 ('95)
v1.10X ('96)
v1.12X ('96)
v2.03X RC ('97)
Newer hardware:
v2.00 ('96)
v2.01X ('96)
v2.04 ('97)
v2.05 ('97)
v2.20X ('98)
Versions ending with an X were supplied by Seta as smaller upgrade ROMs. The board has an empty socket near the main program for this
purpose. The program jumps to the updated code at boot when it finds the magic "JC2X" string at offset 0x3fc in their ROM.
3. Sound
I tackled the ST-0020 + ST-0016 hardware first, since both the video and sound chip are already emulated. Past the Broken ID message lied..
a Sound Down error.
3rd step was thus hooking up the ST-0016. Easy, as I could lift the communication with the sound CPU
(latches and a status register) and its rom banking from another driver.
I only had to adapt the handlers for a 32-bit bus (jclub2 uses a 68EC020).
4. Backgrounds
This got me in-game but there actually were no backgrounds... here the bootleg, which runs on a more traditional
sprites + tilemap arrangement (or does it? I have to revisit that assumption), provides an handy reference of what should be going on
when things are working properly.
So the 4th step was to have a second look at the ST-0020 as it probably could produce some scrolling layers. The other possibility being
they came from the ST-0016 which has sprites as well... a possibility quickly debunked as its video registers were untouched.
In the end I found the ST-0020 is capable of handling 4 tilemaps, yet curiously the Gundam game does not use any of them
(all registers are set to 0) and resorts to a separate tilemap chip (the ST-0009, probably).
The slightly more tedious work was to attain correct colors as they're handled differently than in the bootleg:
Priorities need some further work, so all the games have been marked with imperfect graphics for now.
5. I/O
The 5th step was finalizing all the inputs and outputs, which were already partly worked out and mapped differently than in the bootleg
(the latter is in fact based on some newer game version, allegedly v4.00). These games use two keyboards with 39 keys each,
two hoppers (which needed adding), three sensors per coin slot, three coils per player, battery sensing (added),
4 internal revolving keys, service doors etc.
To help me out debugging this part I created layout files (for the original game and for the bootleg) that provide clickable
on-screen keyboard(s) and internal inputs. I used this video of the controls as reference:
(I think these are cheaper generic replacements. The Sigma cabinet at the top of this post has proper keyboards)
Anyway you can see the keyboards and internal keys state, rendered by MAME under the emulated screen, below.
They allow a much more user friendly control:
2 Keyboards, Wide Monitor
1 Keyboard, Normal Monitor
6. Writing the IDs
The 6th step was investigating if it was possible to generate valid EEPROM data for all the software revisions.
Otherwise only few sets would have worked with the available EEPROM dumps. This was already noted in the driver comments.
Basically through key combinations (not officially documented, I imagine) it's possible to trigger a Write ID message
that rewrites valid data in the EEPROM, at least for the earlier versions. Additionally there's a key combination for an ID
that enables to change the type of monitor connected.
So I went back to the ST-0020 and added some minimal support for switching resolution, and updated the layout
files to let the user select what monitor aspect ratio to use (5:3 - wide, 7:5 - normal).
7. Vender Codes
Unfortunately producing a valid EEPROM becomes more difficult in the newer versions. By at least v1.10 they introduced
the concept of Vender Codes, a secret code to input after the key combination at boot to unlock writing the ID.
The 7th step was thus analyzing the code for inputting and verifying these vender codes for each of the 10 sets,
in order to generate valid default EEPROM files. Fortunately these codes can be found in the roms with minimal effort
(the code to handle them is just shifted around in the rom).
Each code is a string of up to 8 hexadecimal digits that can be input pressing the start button + one of the numerical keys
i.e. 1 through 8. Key "7-8" for hex digit A. Start + any other key for hex digit 9. Any other key, without start, for hex digit F.
I found each code is actually tied to a configuration identifier, so they produce different settings and features
(probably to comply with the target market legal regulations? these are gambling games after all). For instance some codes unlock
more options in the operator menu, such as the aspect ratio of the monitor and betting limits. Some hide the Jockey Club II title
from the attract screen (for whatever reason) and so on. I tried to pick the code providing the highest configurability and the best features.
Vender Code accepted, AEW features
A = no title screen E = extended configuration W = wide monitor (fixed)
8. Newer Hardware
Finally I moved on to the newer hardware, based on the ST-0032. Basic support was already present: this chip wants the graphics ram
bytes swapped and the sprite list shuffled around compared to its earlier counterpart.
As 8th step I implemented the rest of the differences e.g. color handling, video registers in different places,
different sprite list stride and end-marker, tilemap offsets etc. thus bringing the later games on par with the earlier releases.
But they have no sound at the moment, I haven't worked on that part.
So, there you go, in closing, some shots from the most recent version we have.
Next to the version number is the ID and (encoded) the configuration identifier and vender code:
Let me get back to the recent post about the Galaxy Games cartridges, because we have a nice update!
About a week ago programmer Keith M. Kolmos (@KeithMKolmos)
managed to locate, among his archived data, the development files for the only remaining undumped cartridge, StarPak 4.
Thus, while no production StarPak 4 cartridge has been spotted to date, we do now have all the data needed
to emulate these elusive games. That includes the PIC program used for protection, which might have been impossible to extract from the real hardware anyway. Kudos to Keith for sharing.
The development cartridge had eight 8Mbit EEPROMs, so we got 8 binary image files, plus an hex file for the PIC.
For production, the game data was copied into two 32Mbit FLASH parts.
The PIC code appears functionally identical to that from cartridge #3, but the bytes returned during the initial handshaking were changed.
Here's the selection of games in StarPak 4:
Prominent among the lot is the remake of Stern's Berzerk, which greets the player with (samples of) the well known synthesized speech:
Neon Nightmare is a cute test for your coordination skills as you try, as a humble moth, to avoid getting zapped in a maze of neon lights:
Orbit is a color-matching game set in space. Moons have to be skillfully inserted into the orbits of the circling planet with the right tint:
Some nice rendered graphics in Deep Sea. Your submarine and its torpedoes against a fleet of enemy ships:
Another classic board game, Reversi (aka Othello), is presented with an Egyptian flavour in Scarab:
Orbit Freefall is a variation of the previous planets game with some additional twists:
We got to the last two games. As you can see there are major issues. Most of the moving graphics are garbled.
It's probably the emulation at fault rather than the data, but I couldn't spot an obvious cause yet (e.g. in the blitter logs).
Anyway the titles are:
Star Tiger, a spaceships battle with Asteroids-like controls (thrust and fire):
Finally Battle Checkers, features tanks in place of the usual round pieces, and a short-tempered sergeant to keep you on your toes:
ShouTime is on a dumping spree and so we got a Tekken-themed coin pusher today!
It's a Namco medal game similar to Pac-Slot and Tobikose! Jumpman.
It uses super deformed Tekken characters in the same vein as Super Puzzle Fighter or Pocket Fighter.
The title is Tekken Card World (鉄拳カードワールド) and like the other games it runs on cave.cpp hardware (Namco EMG4 or N-44EM PCB):
As you'd expect from a medal game, not much skill is required (read: none at all) to play this game.
Anyway, below are some images of the cabinet, borrowed from here:
There are videos of the real game in action on the net, like this one:
The Galaxy Games system by CES (Creative Electronics & Software) is a cartridge based PCB in a two-player
cocktail cab, with trackballs and buttons as inputs. It offers a series of mini-games targeted at the casual player (think bartops:
you can see a video of the thing in action here).
The base system includes a number of games in the BIOS while the cartridges — up to 4 can be fitted at the same time — can add plenty more.
I emulated this system and the base games several years back.
The StarPak 2 cartridge was added shortly after, but required an hack to run.
The hardware uses a blitter, implemented in a Xilinx FPGA, which was also featured in Midway's Touch Master series of games
(thus, the CES guys were clearly behind those titles too).
It's pretty rare to see these titles auctioned, i.e. only one such PCB (with StarPak 2) and one cab had been seen for sale in the last 10 years.
Yet BrianT spotted one that also came with two carts: StarPak 2, already dumped, and StarPak 3,
which was not!
The BIOS roms were also an undumped revision (v1.80 as opposed to the previously dumped v1.90).
So the The Dumping Union moved in to acquire the lot and, with the help of several
fellow MAMErs, they got it.
Coolmod dumped and documented it (with the help of Ken), here are some pictures:
Now, looking at the photos of the cartridges, you can see they contain the game code/graphics/data on SMT flash chips (center), a serial EEPROM to store the game audits/options
(tiny 8-legged chip at the bottom right) and a PIC cpu (the larger chip on the right side, different models between the carts) that is basically used for protection.
It performs an needlessly complicated handshaking with the main cpu to acknowledge it's fitted in one of the 4 slots
and that it's authentic.
In our previous StarPak 2 sample, the PIC program was not readable (protected), so in order to get to the game
I had to bypass this handshaking by patching the BIOS code. But this time we were lucky and the PIC hadn't been protected,
so we could read the program correctly.
Alas, the same could not be said for the other cartridge, the PIC in StarPak 3 was protected. Worse, this cart contained bigger roms,
thus requiring some ROM banking to be performed by the PIC itself. The BIOS knows nothing about this feature which is internal
and specific to the cart: it's all done by the game code when read in RAM by the main cpu (a 68000) and executed. It talks to the PIC to switch the higher part
of the roms in.
I started by writing a simulation of the handshaking algorithm, so that we could try and simulate the StarPak 3 banking properly,
sound and graphics would be wrong in some of its games otherwise.
The BIOS initially sends a 1-byte command (FF hex) to see if the slot is populated and by which cart.
It expects a 32-byte response from the PIC, starting with "CES1997" and followed by some bytes from the flash chips
at some fixed addresses (one byte is the cart ID).
The main cpu can read from the flash too, so it checks that the response matches the contents of the cart.
Throughout the game the PIC is challenged with sequences of 32-byte commands (not starting with FF). The bytes are random
and conceal a 4-byte key at variable offsets (depending on the value of the bytes preceding the key).
The PIC has to compute the correct 1-byte response, a hash based on the key and, optionally, on the sum of the command bytes.
If this challenge/response dance fails at any time, the games from the cartridge abruptly vanish from the menu.
And this is when something great happened... we were able to get the help of Keith M. Kolmos (@KeithMKolmos), lead programmer
on this software. He could gather from his archive the PIC code for all of the StarPak cartridges (including the yet undumped #1 and #4).
Now MAME could emulate the carts without hacks or simulations, so I ditched the old code and wrote some more to emulate and abstract
the carts as proper devices with communication (i.e. parallel-to-serial and back), switching and banking. I hooked up the PIC code and...
it didn't work!
Turns out there was a bug in the PIC core emulation related to the flags handling, which was preventing the correct answer
from the cart to the main cpu. Having just written a simulation of the handshaking in C++ it was easy to spot.
With the new code in place, even though the driver has taken a bit of a speed hit, StarPak 3 works correctly.
It features a grand total of 8 new mini-games:
It includes a licensed rendition of Atari's Centipede (by the way, here's the programmer's site):
Astro Blast is instead a Space Invaders clone with rendered alien ships:
A Mine Sweeper clone, Sweeper (same programmer as Centipede):
Word Sleuth is a word cross puzzle:
A puzzle game involving numbers, played against the computer or another player, called Ker Chunk:
Great Wall is a Mahjong solitaire with the option of using symbols instead of the traditional tiles:
You must play as batter and then pitcher in the baseball game Diamond Derby:
Finally Pull! is a skeet shooting simulation:
Thanks to Keith M. Kolmos, Rod_Wod, Sean Sutton, Soren Skou Nielsen, Russell Howard, Francis Ramirez, Tourniquet, BrianT, coolmod, Smitdogg and The Dumping Union
