The new batch of dumped IGS games made me look again at emulating the IGS031 custom ASIC.
It's the graphics processor used by several titles from the late nineties (currently scattered in the igs_m68.c, igs_m027.c and tarzan.c drivers, as non-working).
I started with Mahjong Man Guan Da Heng, decrypting the program rom, and noting a striking similarity with an igs017.cpp game I emulated before. Then everything fell into place.
So here are WIP screenshots of Mahjong Man Guan Da Heng (1997):
On the wake of the above progress, I started improving Mahjong Super Da Man Guan II (1997):
Remaining issues on these titles is some protection I haven't really had the time to investigate yet.
That's all I could do for the moment. The remaining sets on the mentioned drivers are either still encrypted (gfx & program), protected by an ARM CPU, or incomplete dumps (i.e. the Tarzan and Super Tarzan sets).
On other IGS news, I've also decrypted and added a clone set to igs_blit.cpp (IGS011 based games). It's the japanese version of Long Hu Bang, called Mahjong Ryukobou (1995):
Thanks to Guru, Dyq, Bnathan, Pierpaolo Prazzoli and The Dumping Union.
Here are several screen shots of 4 Mahjong (or Hanafuda) games by Dynax, thanks to a recently dumped batch of boards.
Let's start off with Mahjong Seiryu Densetsu (1996, licensed to Face):
Then Mahjong Daimyojin (2002, licensed to Techno-Top / Techno-Planning, it features digitized graphics in addition to the usual hand drawn ones):
On to another Mahjong, Mahjong Gekisha (1989):
Lastly, an Hanafuda game, Hana Jingi (1990). It's a clone of Hana Oriduru with added gambling:
(a partial dump was already in MAME, but it needed a dump of the program ROMs).
All games are running on blitter-based Dynax hardware, either ddenlovr.cpp (the newer ones)
or dynax.cpp.
Funny how these titles were programmed in Japan, made it to China, where they were much played back then (in fact, they were bought from there), to be finally dumped in Australia (and emulated in Italy ).
Thanks to Guru, Dyq, Bnathan and Yasuhiro Ogawa.
Some WIP screenshots of the water-ski simulator Skimaxx. This game, manufactured by ICE in 1996, featured a dedicated cabinet with an hydraulic board to stand on:
Yes... it's another Kyle Hodgetts special .
For the emulation, I built upon the current driver by Phil Bennett, adding graphics, inputs and sound:
the PCBs use 2 x 68EC030 @ 40MHz and a TMS34010 @ 50MHz, a CPU with dedicated instructions for pixel-level processing and graphics primitives.
Since MAME lacks a proper 68030 core, the driver uses two 68020s instead.
Not a big deal, since the '030 only adds the MMU (not present in the EC model anyway) and split data and instruction caches over the '020.
The first 68k drives the game logic and builds up the display lists for the other CPUs. The TMS draws the text overlay, while the second 68k draws everything else
with the help of a blitter.
The blitter is an FPGA (programmed at boot by the 68k) that does rotation and zooming, but one line at a time. Thus it requires the CPU to do
most of the work, including walking the high-color screen buffer pixel by pixel!
The stereo sound is driven by 4 x M6295 (sample players) that output digitized music and speech.
Thanks to Phil Bennett, R. Belmont and Mark Frisbie.
One of the cartridges for the Galaxy Games platform (tmaster.cpp, see last year's post) has surfaced.
It's StarPak 2, developed by Creative Electronics & Software (CES).
It adds 7 new games to those already contained in the BIOS, and includes Namco licensed versions of Pac-Man and Ms. Pac-Man that feature simultaneous 2-player action:
A few things had to be fixed in the driver before the games would run, such as carts banking and multiple EEPROMs (each cart saves the high-scores to its own NVRAM).
The latter was a breeze now that MAME supports the device concept and since EEPROMs were converted to proper devices.
Graphically, a "pen replacement" mode for the blitter is now implemented. This was of paramount importance, since it's used to draw each Pac-Man ghost with its proper color .
The cartridge contains a PIC 12C508 CPU that is used to handshake the motherboard and let it see that one of the 4 slots is populated.
Due to limitations in MAME to handle user configurable cartridges, I had to create a new game with BIOS + StarPak 2 hardwired to the first cartrige slot.
Then, since the PIC is not emulated, I patched the BIOS to force the acknowledgement of the games presence.
Thanks to SoftwareThis.
This version of Mahjong Vegas runs on royalmah.cpp hardware.
But, unlike the previously dumped version, it does not use the internal ROM hidden in the TLCS-90 CPU, so it actually works in MAME..
.. after fixing the very, very broken routine that processes the interrupts in the CPU core, that is (my bad).
Thanks to Uki.
Namco's Funcube is a series of touch-screen driven redemption games.
Multiple cabinets can be locally linked, and each chapter in the series (five in total IFAICT), contains three mini games that challenge players on good memory, fast reactions and cards playing skills.
These are some WIP shots from the only two games there's a dump for, Funcube 2:
and then Funcube 4:
The games have no sound ATM, and are not playable due to missing touch-screen inputs.
Yet, it was pretty surprising getting this far, considering that this system (apparently code-named EVA3A) uses, as main CPU, an unemulated Motorola XCF5206.
Luckily it turns out its ColdFire core is an almost binary compatible 680x0 derivative. So I'm using a 68040, patching out a few unemulated instructions, and hacking in the internal peripherals support (timers, serial).
Then there is a PIC12C508 MCU, whose code is not dumped, that may be involved in the minimal protection that I've bypassed.
In typical Namco fashion, another CPU handles the rest of the inputs (i.e. coins, dips). It's an H8/3007, a variant with no internal ROM.
I had to add support for a few more unemulated instructions, but it still has issues with the 16-bit timers.
Sound wise, it uses ADPCM samples, alas through an unemulated OKI MSM9810 chip.
The graphics emulation works though, as the board uses the same chips (DX-101, DX-102) I emulated in seta2.cpp.
Just some trampoline functions were needed, in order to connect the 32-bit data bus of the ColdFire to the 16-bit handlers in that driver.
Thanks to Haze.
|