Re: [新聞] (WIP) David Haywood's Homepage

看板Emulator (模擬器)作者conpo (獅子たちの旗)時間9年前 (2016/03/14 23:02)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串58/78 (看更多)

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