2016.06.06
"Kyuukoukabakugekitai (Dive Bomber Squad)"
Before anybody jumps in, this is not a return to the regular programming
here. I’m still unsubscribed from Mamedev, and surrendered my commit rights
to the project, however, as preservation is the number one priority, and the
following article is about a ridiculously rare title, I was willing to assist
ShouTime with bringing it to MAME.
Kyuukoukabakugekitai, sometimes referred to as ‘Dive Bomber Squad’ is one
of Konami’s long lost games, one of the most famous prototypes in Japan,
even if ultimately it is clear why the game didn’t make it to market.
The Hardware
From a hardware perspective the PCB looks fascinating.
http://mamedev.emulab.it/haze/pics2016/dbs2_small.jpg
.. and under the Sub-Board
http://mamedev.emulab.it/haze/pics2016/dbs1_small.jpg
So GX840, a unique Konami board. The number doesn’t really date the board (I
’m not sure how Konami assigned them) but we already know from the ShouTime
booting the PCB that the game is from 1989.
CPU-wise you can see 3 Z80s on the board. Most other major manufacturers had
actually moved on to 16-bit CPUs by this point, even Konami had used dual
68000 chips for the ‘Twin16’ hardware in ’87, so immediately a triple-Z80
based game in 1989 stands out as a little underpowered.
The only Konami marked customs on the board are a pair of ‘051316 PSAC’
chips, we’re familiar with these, each one provides a ‘ROZ’ (Rotate and
Zoom) tilemap, meaning this board has the capability to deliver 2 background
layers, each capable of rotating and zooming. The same chip had previously
been used on games like Chequered Flag and Ajax (Typoon)
The other noteworthy custom is the MN53060KGB, we don’t actually have any
information on that, but it’s probably fair to assume it handles the sprites.
Sound hardware isn’t obvious at first, but if you look at the main board
picture there’s a column of 6 SN76489 chips near the edge. The use of these
chips is another odd choice, they give quite a primitive mid-early 80s sound.
Konami had the chip (2 of them) on classics like Mikie to great success, but
by 1989 the market had moved on, and 6 just seems excessive.
There are also 12 BPROMs under the sub-board, I’ll come to them later, but
again, unusual to see a significant number of BPROMs on hardware from 1989.
The actual use of roms is curious too, in the top left there are 4 ‘OTP’
(one time programmable) ROMs, this is unusual for prototyping where
typically erasable, socketed EPROMs were used, so that the content could be
changed quickly and easily as the game developed; clearly the data contained
in those roms had already been finalized.
The bluey-grey-gold chips on the left hand side of the board might look
interesting too, but they’re actually just RAM chips.
4 banks of 8 dipswitches is also unusual, most games only have 2 with
gambling boards typically being the exception where you often see 4 or 5.
The elephant in the room here of course comes from all the wiremods that have
been made to the PCB. Usually wiremods are used either in repairs, or when
trying to convert one PCB to another, modifying the behaviour in ways to
avoid having to modify the game code, quite why this PCB is covered in
wiremods when it was designed for the game it is running and nothing else I
don’t know. Unfortunately it’s not something emulation will really tell us
either, it did make the dumping task more difficult as it makes the PCB very
fragile.
So, in conclusion, some odd hardware choices; the game is known as “Konami’
s attempt to do a Metal Hawk style game”, but from a hardware perspective
what we have here appears on the surface to be many times weaker than Namco’
s System 2 platform on which Metal Hawk runs.
The (unemulated) Game
Until Shoutime picked up the PCB very little was known about the game, there
were a select few screenshots from the period it was location tested but
little else. He did make a video of it, which can be seen here
Immediately from the video it’s clear that the game isn’t really quite on
the same level as Metal Hawk from a technical achievement perspective, BUT it
is a prototype, so we have to ask the question ‘could it have been’
The Emulation
The first step in emulating this game was to work out the responsibility of
each CPU. Typically when you emulate something the CPU with the most code /
data is your ‘main’ CPU which drives everything else, and hooking it up is
the obvious starting place, either that, or you can work out which seems to
be the main CPU from the positioning on the board, if a CPU is near the sound
section it’s probably the sound CPU for example.
Here things weren’t quite so obvious, it was clear that the ROM near each of
the Z80s was the program for that Z80, but in terms of code content they all
weighed in close to equal, and none of the roms contained any obvious strings
(another good hint at which CPU is the main one in many cases)
Having sorted out all the ROMs, and decoded all the graphics I also had 3
remaining ROMs (u9, u10, and u11 on the sub-board) that clearly were not
graphics. One of them contained Z80 code, so was clearly meant to map in CPU
space for one of the Z80s, the other 2 contained large 128×128 structures,
which I quickly concluded were the tilemap layouts for the background. The
051316 PSAC chip however works with 32×32 tilemaps, so definitely couldn’t
be using this data directly (unless it was operating in a previously unknown
mode) so I concluded that those roms were probably CPU mapped too.
At the time the BPROMs had not been dumped (actually, they hadn’t even been
mentioned / identified as needing dumping) so I couldn’t examine their
content. I also hadn’t identified the sound hardware at this point, but
after dropping ShouTime a mail he pointed me at the SN76489 chips; the labels
on them weren’t entirely readable in the images I had and I was looking for
a single, larger custom.
Anyway, not knowing which Z80 to start with I tried hooking them up 1-by-1
and examining their behaviour. With the knowledge of the sound hardware from
ShouTime I quickly identified a group of 6 sets of writes on startup that
each corresponded to the init sequence for a single SN76489 chip, these were
being driven by the code in the ROM at U20, presumably running on the Z80
next to it, at U2. Most obvious conclusion there, it was the sound CPU.
Next one I decided to poke around with was the code in U19, for the Z80 at
U1, this was under the sub-board, near the 2 ‘051316 PSAC’ chips, and it
immediately became clear that this CPU was meant to drive those chips,
handling the rotating background tilemaps; there were 2 blocks of port writes
and 2 blocks of appropriately sized RAM being cleared, both of which aligned
well with how the 051316 PSAC chips are expected to hook up.
At this point I was simply generating interrupts and NMIs (Non-maskable
interrupts) in a mostly random fashion on the CPUs to try and encourage them
to run a bit more code, likewise input ports were just hooked up to return
random data. One thing I did notice, and a quick disassembly confirmed it
further, was that this CPU had code that jumped outside of the usual ROM
space covered by the U19 ROM. I checked, and these jumps aligned with the
code contained in the 3 previously mentioned data ROMs on the sub-board,
which made sense; that was the CPU that would need access to the background
maps too.
There was too much extra code / data here to map directly into CPU space, so
clearly some kind of bankswitching was going on, luckily this was quite
obvious at the bank write was made immediately before the jump to the banked
area. I’d already hooked up the ROZ layers to this CPU and with the
randomized inputs to the CPU I could see it trying to write data to the
tilemap; using this data I was able to figure out the bankswitch algorithm,
noting down all the bank values written and how the data read was used and
coming to a logical conclusion – the bit order of the bank writes was
reversed.
As this was now the CPU with the most code I did stipulate that it might also
be the main CPU, but I still wasn’t really sure how anything communicated,
while this CPU did seem to be in charge of the ROZ layer and have the most
data it also seemed more interested in responding to commands rather than
issuing them.
Moving on, I started looking at the ROM at U21, for the Z80 at U3. This
actually seemed to be the simplest of the CPUs, not really much mapped apart
from the ROM and some RAM as well as what was clearly a communication port.
Again, with just random inputs being thrown at the CPU it populated the RAM
with what was clearly a spritelist, the format was simple, 4 bytes per
sprite, surprisingly simple actually, no room for any kind of zooming or
rotation attributes, just a very simple system of x/y co-ordinates, tile
number, and an attribute value, presumably flip bits or palette select. This
surprised me, for a game with lots of zooming and rotation I was expecting to
see a more advanced sprite system. The sprite data, which I’d already
decoded, was contained in the OTP roms at u15,16,17 and 18 on the main PCB.
At this point I’d managed to identify which CPU was in charge of the
background layer and which CPU was in charge of the sprites, but was still
missing the foreground layer and the palettes. As there didn’t seem to be
any significant unused memory area on those 2 CPUs it was time to take
another look at the first CPU, the one I’d identified as handling the audio.
Taking a similar approach of just forcing random inputs to the CPU I was able
to identify an area of memory that appeared to be the text tilemap, a very
simple layer, probably doe entirely in logic on the PCB using the roms at u22
and u23 in the corner of the PCB. It also became obvious, looking back at
this CPU that it was accessing far more input / output ports than any other
CPU, and was the most likely candidate for being the main CPU driving the
game, despite also driving the sound (usually a task reserved for a slave CPU
in multi-CPU setups)
Of course, with every CPU just running based on random inputs every layer was
doing something different, none of them were synced together, and nothing
resembled a game at all; all the CPUs had both input and output communication
ports, and were relying on signals from the other CPUs to do the right thing.
Understanding the communications required more detective work. There were
clearly some ports involved, but I also wondered if some of the operations
were based around shared ram; 2 of the CPUs were definitely acting based on
bytes at the bottom of RAM. Ruling out this shared RAM theory was fairly easy
tho, every CPU has, next to the ROM, a 8464A-15L RAM chip, this is an 8KB
RAM, and the main RAM area for each CPU was 8KB, making the shared RAM
scenario most unlikely. Two pins appear to be tied together on each chip,
which could potentially halve the capacity of each RAM, but looking up the
pinouts didn’t seem to indicate those to be addressing pins. The accesses to
the RAM areas at 0x3000 were mostly done in the NMI routine of each CPU, as I
’d concluded that these were unlikely to be communication related I decided
that the NMI routine on each CPU was likely the vblank IRQ, called once per
frame, every frame.
The regular IRQ routine for each Z80 was also valid, this is where various
port accesses were made. Logical conclusion here, these were the
communication ports, and commands sent to each CPU generate an interrupt.
The interrupt routine on the first CPU, the one in charge of the foreground,
and assumed main CPU was a little more complex, the port it read from
depended on the read from another port, this again isn’t too illogical if
you think about it, the main CPU has to communicate with 2 other CPUs, it’s
likely to be getting interrupts from 2 different sources, but there’s only
one interrupt routine, so it needs to know which CPU wants to talk to it.
With all that hooked up the game started to run something resembling an
attract mode, layers were offset, and I still had no palettes, but you could
see it following the same sequence as ShouTime’s video.
Inputs were mapped from there, coin was easiest to find, after finding the
coin it became easy to work out some inputs for the joystick directions and
buttons for each player etc. One thing of note here is that while the PCB has
4 banks of dipswitches the game code clearly only ever attempts to read from
2 of them, there is a hole in the address space where the other 2 presumably
map, but the game never reads from them, maybe they were used for debug
features earlier in development?
So palettes, where were the palettes? Nothing was being uploaded. This is
where I decided to take another look at the PCB pictures ShouTime had
supplied, to my surprise there were some BPROMs, and not just 1 or 2, but 12.
12 BPROMs arranged in 4 banks of 3. There were 3 banks of MB7122 BPROMs and 1
bank of MB7114 BPROMs. The MB7122 can hold 1024 4-bit bytes each, while the
MB7114 hold 256- 4-bit bytes each.
BPROM triplets are more often than not used for palettes, with one rom for
Red, another for Blue and a third for Green, 4-bits per pen. For a 1989 game
the use of BPROMs here was certainly an odd choice, but at this point there
was no doubt in my mind that this was where the palette was stored on the
board, as opposed to being in RAM as you’d maybe more typically expect for a
game of this period.
I speculated that the smaller BPROMs were being used for the text layer which
at 2bpp, or 4 colours per tile, clearly wouldn’t need as much storage space.
It seemed likely that the other 3 banks were for sprites, and one set for
each of the rotation layers.
Luckily Andy, who had helped ShouTime dump the OTP sprite ROMs was still at
hand to help dump these PROMs; ShouTime had struggled with PROMs in the past
because his programmer has a weird way of reading them. Andy helped remove
the roms and figure out how to dump them while I, using a document provided
with ShouTIme’s PROM adapter wrote a little program to convert his dumps
(1-bit per byte format) into the expected data format for MAME / other
programmers (4 bit per byte)
He actually started with the MB7114 BPROMs, which I was expecting to be less
than useful for verifying the dumps because I’d speculated that those were
used for the text layer, which was barely used, however it turned out those
were for the sprites instead, and I was quickly able to verify that the
BPROMs contained the palette, and that the dumps were good. The rest of them
followed. The roms used for the text layer palette were mostly empty, which
does make me wonder why the lower capacity ones weren’t used there too.
For the Rotation layers each of the BPROM triplets contains 4 palettes (the
Rotation layer decode is 8-bits per pixel, or 256 colours per tile, so BPROMs
of 1024 give 256*4 palettes) For one layer 3 of the banks were valid (the 4th
contains garbage) and for the other layer all 4 banks are valid.
Again showing the inefficiency of this method of storing palette data, the
difference between each of the banks was incredibly minor, just a handful of
colours in each 256 changed, clearly as a crude way of doing a 3-stage
palette cycle effect on a mere handful of background graphics. Even finding
the bank select for this proved tricky, I’ve had to make a complete guess,
there was a port on the same CPU where values of 00, 01, and 02 were being
written, changing every couple of frames, presumably to do the colour cycle
on the layer with 3 valid palettes, however I didn’t manage to locate
anything to select the bank for the other layer. I later discovered another
problem with this hookup, but I’ll come to that later.
There are actually extra bits in the attribute RAM for the rotation tilemaps
which I initially thought might be the palette select, but they get used in
ways which appear to be nonsense, for example, the bottom left (only) tile
over some of the 4×4 turrets gets set, giving invalid / mismatched colours
on them due; I assume those bits are just being used internally by the game
for some reason.
So where are the pictures? I guess it’s time to put up some pictures, so
here are some pictures.
http://mamedev.emulab.it/haze/pics2016/divex_1.png
http://mamedev.emulab.it/haze/pics2016/divex_2.png
http://mamedev.emulab.it/haze/pics2016/divex_3.png
http://mamedev.emulab.it/haze/pics2016/divex_4.png
http://mamedev.emulab.it/haze/pics2016/divex_5.png
http://mamedev.emulab.it/haze/pics2016/divex_6.png
http://mamedev.emulab.it/haze/pics2016/divex_7.png
http://mamedev.emulab.it/haze/pics2016/divex_8.png
http://mamedev.emulab.it/haze/pics2016/divex_9.png
http://mamedev.emulab.it/haze/pics2016/divex_10.png
http://mamedev.emulab.it/haze/pics2016/divex_11.png
http://mamedev.emulab.it/haze/pics2016/divex_12.png
http://mamedev.emulab.it/haze/pics2016/divex_13.png
http://mamedev.emulab.it/haze/pics2016/divex_14.png
http://mamedev.emulab.it/haze/pics2016/divex_15.png
Does this mean everything is good now? Maybe, despite my work and analysis of
how the CPU communication works I was, up until yesterday still having some
issues where the communication between CPUs would fail rather quickly,
resulting in the controls no longer working, and the game logic not advancing
at all, just scrolling forever in a straight line. Despite being able to
reproduce this easily at the time I’m no longer able to, suggesting maybe it
’s the result of a dipswitch setting?
There’s also another uncertainty, if you do manage to complete a level, and
bomb all the targets a boss appears, at this point, the palette bank write
becomes 03, which is again the invalid palette. This actually rules out my
theory of the palette bank bits above being for the front-most rotation
layer, instead, it appears that this specific register is for the lower one,
the forth palette in that set of colours is a darkened version of the
palette, which makes sense for fighting a boss.
That does again leave me without a bank select for the front-most rotation
layer, maybe it’s hooked up differently and each of the 3 roms for that
layer uses a different palette; I did however observe that the upper bits of
the register change from 00 to 10 when hitting a boss, which would give a
colour effect if that was bank, but i’ve never seen 20 written there which
would leave one of the valid palettes unused. For now I’ve decided on that
solution, although I’m not 100% convinced that it is correct, it’s just a
guess.
There’s another issue with the boss, it doesn’t actually seem to be able to
harm you at all, I’m not even sure this part of the game has been programmed
in or if it’s another emulation issue. Furthermore, after defeating the 3rd
boss I had no sprites at all on the 4th level (could be another communication
issue – the only way I was able to get the game this far without it crashing
was save states) Regular enemies do appear during the boss fight, and they
can damage you dying from a hit by them at the same time as the boss dies
appears to break the game, but that does smell like a prototype bug to me.
Upon reaching the 4th level I was presented with a screen containing no
sprites; I could fly around, rotate etc. as I’d expect, but there was no
gameplay and no way to die; this could simply be a sign that the prototype is
unfinished however, rather than an emulation bug.
As mentioned, when trying to crash it, I can’t, so here is a video of me
playing a few games, I get to the 2nd level once. Maybe some of the unknown
bits in the port where the coin maps, or one of the dips influences the
likelihood of the game crashing?
https://www.youtube.com/watch?v=lZjPIAXbM6I&feature=player_embedded
Was it viable?
Even from the current, incomplete, emulation state it’s actually fairly easy
to see why this game didn’t make it to market. Previews of the game might
have made it look a bit like Namco’s Metal Hawk, but Metal Hawk was a game
that put you in full control of the rotation and altitude using analog
controls; Konami’s offering gives you less control (digital input only) with
no direct altitude control; you can either fly high, or fly low but not hold
your position at a mid-level. Holding the joystick backwards while flying
high allows you to rotate, although you never stop moving forward. The only
point in diving seems to be to make the ground targets bigger as the sprites
don’t zoom none of the enemy planes change screen position at all when you
dive, the attack patterns just continue as if nothing was happening.
That in part is due to a hardware restriction; the fact that only the
backgrounds can zoom. The sprite hardware on the platform has no zoom
capability at all whereas Namco’s hardware offered full zoomable sprites
making it possible for them to scale with the backgrounds and produce a
multi-layered effect.
The detail level here is also vastly inferior to Namco’s game, you’re
seeing all the pixels in the zoomed out view, as soon as you dive down all you
’re doing is quadrupling the size of all the pixels rather than revealing
any hidden detail, it looks much more dated.
The BPROM based palette technique Konami employed here also makes it
impossible for the hardware to do nice palette fade effects and also severely
restricts the themes and variation possible in the graphics as they all need
to fit in the limited number of palettes that can be hardcoded in the BPROMs.
This does mean the CPUs have less work to do (you can change palette with a
single write) but the gain really isn’t worth it, despite the weaker CPUs
here I’m fairly sure they could have managed a RAM based palette without too
many problems.
Sound, again, the odd choice of using 6 SN76489 chips comes back to haunt the
game; Namco’s platform had a YM2151 for great sounding FM music, and a Namco
custom sample playback chip for sound effects, giving crisp explosions etc.
Konami’s board is limited to 8-bit blips, and while I doubt the sound is
complete, or taking full advantage of the hardware available, the limits are
already far too obvious.
From a technical perspective this game was never going to fly, Namco’s Metal
Hawk was released in 1988 and arcade gamers had been blown away by the
precise controls, free rotation and zooming of all objects not only in that
but also Namco’s Assault where similar visual techniques had been employed;
Konami’s best effort here, a year later looks generations behind.
Looks aren’t everything tho, a good game could have papered over weaknesses
in the hardware; Konami put put Ajax in 1987, a year before Metal Hawk, on
similar hardware to this. Ajax as a game worked to the strengths of the
hardware, something which was important back then, this didn’t. I’d
actually go as far as saying this game does the opposite, it exposes the
weaknesses of the hardware from the very start especially the lack of sprite
zooming.
The actual game, while still in early stages of development shows some flaws;
the mini-map isn’t especially useful as it’s difficult to correlate your
position with the scanner you can bring up, and the scanner gets in the way
when you bring it up too.
Furthermore, some of the missile silos can launch missiles which just appear
at a seemingly unrelated screen position a second later; if you keep moving
you’re usually ok, but the game doesn’t do a good job of representing this
so it often just looks like you’ve been blown out of the sky by a sprite
that appeared underneath you.
Levels have no kind of time limit either, you can leech them forever for
score which really rules out the game being used in competition.
Diving, supposedly a key aspect of the game, doesn’t really seem worthwhile,
on the first level it’s pointless, because you crash into the higher ground
if you do it, and all the bombing targets are on higher ground; on subsequent
levels it might have more uses, it’s easier to hit a target, but it makes
positioning yourself in the first place more difficult. The way the enemy
sprites don’t zoom or have their behavior altered in any way by the change
in altitude actually ends up making it feel more like a laserdisc game where
the background is just stuck on.
Another irritation in the game is the actual bombing, bombs follow your
craft, so you can’t just launch a bomb then rotate the plane away from an
enemy shot; the bomb follows your rotation in mid-air, even if it is no
longer connected to the plane. While this isn’t uncommon for older 2d
shooters with ground-based targets it feels out of place here.
As I opened this section with, it’s quite obvious why the game didn’t make
it to market, and I don’t think the hardware Konami were using here was
really suitable for the game being created, however questionable game
mechanics in what was produced means it would have taken a significant amount
of reworking to turn this game around.
Why Emulation?
So, in my opinion, this wasn’t a great game, but was it worth emulating it?
The answer is a resounding yes. Until now this title had been condemned to
history, nobody was quite sure why aside from those who got to test it back
in the day, and whoever at Konami decided to cancel the project. With the
game emulated people can draw their own conclusions.
Discovering the PCB, and having it emulated reveals that to the world; you
can see first hand how flawed some of the hardware choices were, see that the
project was almost certainly doomed from the start by some of these bizarre
and limiting choices, how strong competition in the market was back then, and
how much difference just a year could make to the viability of a product.
Ultimately somebody / team of people created this game, spent maybe a year of
their life working on it only for it to ultimately be lost for 27 years due
to not making it to market. It’s a piece of art, a creation, seeing it lost
would make all that nothing more than a waste of time and effort.
The other real difference with looking at these old games today is that the
date of release can be ignored; while the marketplace was fierce back in the
day, and the reception for a dated looking game would have likely been
negative we’re no longer judging things by the same criteria; these are old
games, 5 years either way makes little difference when the titles are already
30 years old. You can compare the game more easily and more favourably to
earlier titles rather than the ones it was actually meant to compete with. In
some cases this works in favour of the games, which were good, but simply too
late to make an impact, or, as we saw especially in the early 1990s,
abandoned because everybody wanted to make Street Fighter 2 clones instead of
something original.
Clearly the game has no commercial value at this point, and since it was a
cancelled prototype it really had no commercial value even back in the day,
but it has cultural value, value in what it tells us about industry
conditions, what Konami was looking at at this period of time. Emulation is a
great way to tell a story.
An International Effort
Getting us to the point shown here was a tremendous amount of work. The only
known PCB for this game started off in the hands of a PCB collector in Japan
who isn’t emulation friendly, but through the financial support of the
global community, was acquired by ShouTime, also in Japan, for the purpose of
emulation.
The work done to get it dumped and emulated crossed international borders too
in a very literal sense; Andy, who dumped several of the trickier ROMs and
PROMs while very carefully making sure not to damage the PCB is based in the
US, but was visiting Japan.
The emulation work was no different, I’m based here in the UK, and have been
communicating with ShouTime in Japan whenever unknowns came up, or I needed
something verifying. The timezone differences in cases like this make for
late nights and requires patience in waiting for replies to queries.
Ensuring these games are preserved takes work from people all over the world,
from different backgrounds and different cultures, and so I feel it important
to take the time here to thank every single person who has contributed or
helped out with this at all. Preservation of our past is not so much a game,
but a responsibility and everybody who has contributed here has helped make a
difference.
Misc Information
It would appear, even with the game not really holding up that well against
the competition, Konami already had plans for localization; ShouTime was able
to get hold of a flyer for the export release of the game where it carries
the title ‘Gaia’
http://mamedev.emulab.it/haze/pics2016/divebomb_flyer_small.jpg
This is no relation to SemiCom’s rather poor effort released in 1999, a game
I covered here previously.
As I can’t submit the driver myself it can be downloaded HERE if you want to
compile it, not 100% clean / tidy, but writing / doing any of this with a
broken arm is a monumental effort. I’m sure one of the devs will pick it up
and include it.
来源 http://mamedev.emulab.it/haze/