2016.03.14
"Android Android"
The game development cycle can be a fascinating thing, especially for games
that ultimately might not have been released.
We knew of a game called ‘Android’ by Nasco, because Chris Hardy has one,
he uploaded a video here and apparently he was wanting to write a driver for
his PCB before submitting it but had got stuck on something to do with the
sprite attributes shortly after uploading that video.
When another copy of Android turned up we initially almost passed on buying
it because of this, however a closer look at the version on offer showed it
was rather different to the one that was in Chris’s hands so we ended up
buying it (or rather Ryan Holtz / MooglyGuy ended up buying it – it cost a
rather hefty $500, so as always donations are appreciated, we don’t have
bottomless pockets and that was a fair chunk of money. Without funds things
WILL get lost because sadly some people would rather put profit before
preservation)
Anyway, as I had to check out the dump to make sure it was good, and don’t
know what hardware the one Chris has runs on I looked at emulating it.
Searching the PCB board number turned up an obscure driver ‘himesiki.cpp’
in which ‘Himeshikibu’ a 1989 Japanese Hanafuda type game by ‘Hi-Soft’
was the only game present. Looking in the driver that was a 3 board stack,
so I ruled out the chances of it actually being the same board as coincidence
as this was only a 2 board stack.
I then spent a bit of time looking at the romset, and realised that ruling
out that driver was a mistake, because everything was mapping to be exactly
the same as the driver I’d found except for a there being one less set of
sprites; presumably this is what the 3rd board provides and Android simply
didn’t have it or need it.
I needed to fix up a few things such as the CPU banking, and tilemap
scrolling, but essentially it was an easy drop-in. The build we picked up
feels very much like a prototype, rough around the edges, unfinished in
places.
For fun I did some side-by-side comparisons with the version Chris owns. What
you can’t see in these screenshots, but can see in the videos is that his
has more complete music too.
http://mamedev.emulab.it/haze/pics2016/android_title.png
http://mamedev.emulab.it/haze/pics2016/android_scores.png
http://mamedev.emulab.it/haze/pics2016/android_stage1a.png
http://mamedev.emulab.it/haze/pics2016/android_stage1b.png
http://mamedev.emulab.it/haze/pics2016/android_stage1c.png
As you can see, the differences are very significant.
The font between the two versions is entirely changed, the one Chris has uses
a thin font, the one we picked up has a chunky one.
The title screen is modified, the sprite graphic is changed, but most
significantly the galaxy used in the background has been replaced with a
smaller, cleaner more elegant looking one in the version Chris has.
The high score table is fully populated in the version Chris has, but not
ours.
The stage introduction text is more detailed on the one Chris has
The ingame background is coloured on the one Chris has, it’s a starfield on
the one we have.
The ingame sprites are completely different too, the player ship is changed
as have all the enemies, the enemies on our board are various robots, the one
Chris has uses eggs that turn into heads. The one Chris owns also has a
shield powerup, and you can move all the way up the screen into the enemies,
ours has no powerups and restricts you to half the screen.
Now.. all this clearly suggests that the board Chris has is a newer version,
HOWEVER, the one we have also does some things that his one doesn’t. We for
example have a level timer, when that timer expires any enemies you haven’t
killed turn into a circular boss, you must shoot the left edge of that boss
to stop the spinning so that you can attack it’s weak point. Upon starting a
game our version also has a big dragon (it quickly retreats and reappears for
you to kill after several stages) This dragon does not appear at all after
coining up on the version Chris has (if it appears later is unknown)
I’d still say the one Chris has is newer, it’s a lot more polished, has a
proper coin-up sound etc. but this definitely gives some insight into the
development of the game, a game we’re not actually sure if was released at
all.
For reference, here are some screenshots of the things in the MAME version
that I can’t see in the one Chris owns.
http://mamedev.emulab.it/haze/pics2016/android_mame_1.png
http://mamedev.emulab.it/haze/pics2016/android_mame_2.png
http://mamedev.emulab.it/haze/pics2016/android_mame_3.png
http://mamedev.emulab.it/haze/pics2016/android_mame_4.png
It remains to be seen if the one Chris owns drops straight in the Himeshikibu
like this one did, although if it does then I’ll cross my fingers and hope
he submits it soon, as his reason for not submitting it before was that his
driver was incomplete, but if it’s actually this PCB we already emulate then
that problem is already resolved. It will definitely be interesting to do a
more intensive comparison of the two versions if the other one does get
submitted.
In the meantime, here is a video of me playing the one we have badly. It’s
actually an interesting game, you have 2 gun types, one transforms the
enemies between different forms, the other zaps them. If you zap an enemy in
anything except their 3rd form they’ll respawn. Any enemies left when the
timer runs out will form into the bigger ‘circular’ boss enemy, the more
enemies left the more difficult that boss enemy. There’s also a bonus stage
following similar rules, and the ‘dragon’ stage which seems less complex.
https://www.youtube.com/watch?v=RY36BaXL3w0&feature=player_embedded
"Catching Fire"
Until it showed up a week or so ago I had never heard of the game ‘Fire Ball
’ by FM Work, but the screenshots on eBay made it look like a Bomberman ‘
clone’.
Team Europe picked up the board and dumped it. The hardware was a z80 based
board (with an additional Z80 for sound) so definitely not based on bootleg
Bomberman code, but instead an original Korean product.
Even with original Korean games the hardware is usually cloned from something
else, and identifying what it is early can save a lot of time. (I actually
ended up discovering the Black Touch ’96 is a modified clone of SNK’s POW
hardware – many years after I added it, had I found that earlier it would
have saved me a lot of time figuring out the video hardware!)
The cloned hardware is rarely a straight 1:1 copies, usually the sound
systems are degraded, clocks often changed, sometimes graphics hardware is
tweaked (for higher BPP tiles, as we saw with Lock On previously covered
here) and physically they look nothing alike so when trying to work out the
basis of a piece of hardware you have to look for ‘unique’ characteristics
in terms of addresses used, sprite / video formats etc. in order to pair the
cloned hardware.
Anyway, with Fire Ball I decided to start by decoding the graphic tiles, that
turned out to be simple enough, 3 sets of graphics, 2 sets of 4bpp 16×16
tiles, and a set of 2bpp 8×8 tiles.
I then started looking at the code for the main CPU. It’s was a Z80 program,
clearly driven by an NMI (Non-maskable interrupt) rather than the regular
IRQ0 signal on the PCB. Generating an NMI too early caused the game code to
crash, so clearly there was an external enable / disable flag for the NMI
generation. The only real things the game did of note aside from clearing RAM
were some port writes, especially to address 0xf80e. One of those was surely
NMI enable. The last thing it wrote there, before sitting in a ‘halt’ loop
was 0x08.
Searching the MAME source for “0xf80e” in the memory maps gave precisely
one hit. The driver for Legendary Wings (lwings.cpp)
Mapped at 0xf80e there was “AM_RANGE(0xf80e, 0xf80e)
AM_WRITE(lwings_bankswitch_w)” which on the surface might not sound like
what I was looking for, but if you look in the actual function you’ll see it
does a few things, including having an NMI enable flag on bit 0x08.
Legendary Wings also used a 2bpp text layer, 16×16 4bpp sprites, and 16×16
4bpp tiles.
It quickly became apparently that it was the base FM Work had used to create
their cloned hardware from.
Anyway, I added it to the driver, taking note that the sound system was
definitely different, this PCB used a single M6295 for sound, none of the
Yamaha chips of the original hardware.
None of the games in the driver supported 4 players, so I also had to figure
out where the extra inputs mapped, not really a challenge, and then tackle
the sound. Worrying there was a big epoxy block on the PCB, however we’d
already established that removing it only caused one thing to happen, the
sound stopped working. Team Europe had also already decided to throw caution
to the wind and open it up, there was actually very little of note inside,
just 2 20pin devices.
Hooking up the sound didn’t take long, it isn’t great, but that’s because
the sound hardware is awful; test mode lets you test every sample. Having
hooked it up I’m actually left a little confused as to what the purpose of
those devices inside the block are, maybe they’re related to the sound
banking or memory map for the sound, because the actual sound system is very
simple, a simple M6295 driven by a tiny program, with some sample banking.
I played through the game a bit, noticed that the 3rd boss and above had
corrupt graphics, noted that the game has twice as many sprites as anything
on the original hardware, and found the sprite bankswitch address (same
location as the rom bankswitch)
Interestingly, because this game has a single 0x20000 program rom, rather
than 3 0x8000 sized roms like the other games in the driver a chunk of the
program rom is inaccessible. Alone this isn’t too unusual for these Korean
games, often such areas are left blank in roms or just duplicate the first
part of the data.
What’s weird here is that the inaccessible area is mostly a direct copy of
the first ‘fixed’ / ‘non-banked’ part of the program code but with a very
slight change, 2 pieces of code are switched around.
3822: CD 73
3823: 00 23
3824: 3E 72
3879: 73 CD
387A: 23 00
387B: 72 3E
first copy in ROM
3822: 73 ld (hl),e
3823: 23 inc hl
3824: 72 ld (hl),d
...
3879: CD 00 3E call $3E00
2nd copy in rom
3822: CD 00 3E call $3E00
..
3879: 73 ld (hl),e
387A: 23 inc hl
387B: 72 ld (hl),d
I’m not sure why this is, I don’t think the 2nd copy can be banked in,
maybe it’s an older copy of the game code before they fixed a bug, I haven’
t worked out when the code is called either.
Anyway, the game is fully playable, although clocks and refresh rate aren’t
verified. Here are some screenshots (and yes, the 16-pixel border on the left
is correct, only test mode uses the full width)
http://mamedev.emulab.it/haze/pics2016/fireball_0.png
http://mamedev.emulab.it/haze/pics2016/fireball_1.png
http://mamedev.emulab.it/haze/pics2016/fireball_2.png
http://mamedev.emulab.it/haze/pics2016/fireball_3.png
http://mamedev.emulab.it/haze/pics2016/fireball_4.png
http://mamedev.emulab.it/haze/pics2016/fireball_5.png
http://mamedev.emulab.it/haze/pics2016/fireball_6.png
http://mamedev.emulab.it/haze/pics2016/fireball_7.png
http://mamedev.emulab.it/haze/pics2016/fireball_8.png
http://mamedev.emulab.it/haze/pics2016/fireball_9.png
http://mamedev.emulab.it/haze/pics2016/fireball_10.png
http://mamedev.emulab.it/haze/pics2016/fireball_11.png
I’ve also uploaded a video of it to YouTube, not being played well, but
enough to show you the game.
https://www.youtube.com/watch?v=csJUAj3tZFg&feature=player_embedded
來源 http://mamedev.emulab.it/haze/