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.
.. and under the Sub-Board
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.
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?
Content not available.
Please allow cookies by clicking Accept on the banner
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’
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.
