0.146u4 [Arzeno Fabrice]
0.146u1 [Tirino73]
0.104u2 [Pierpaolo Prazzoli, Guru]
0.36b10 [Bryan McPhail]

TEST MODE:
- To access test mode, reset with both start buttons held.

Bugs:
- Most of background missing on Flip Screen. Tafoid (ID 04919)

WIP:
- 0.146u4: Arzeno Fabrice added Dynamite Duke (Europe set 1). Changed 'Dynamite Duke (Euro)' to clone '(Europe set 2)'. Renamed (dynduke) to (dyndukea).
- 0.146u1: Tirino73 added Dynamite Duke (Euro). Renamed (dynduke) to (dyndukej), (dyndukef) to (dyndukeu), (dbldyn) to (dbldynj) and (dbldynf) to (dbldynu).
- 0.133u1: Renamed (dyndukf) to (dyndukef).
- 0.126u4: Fabio Priuli added conditional dips and DIP locations to Dynamite Duke. Added dipswitches 'Coin Mode', 'Coinage' and 'Cabinet'.
- 0.119u3: David Haywood fixed colors in Dynamite Duke. Changed palettesize from 3072 to 2048 colors.
- 3rd October 2007: David Haywood - The source of most of the problems in Dynamite Duke was the strange way in which the background layer was being decoded and handled. The biggest problem is that 1 bit of data for each pixel was being completely overlooked. Dynamite Duke's background decode was 5bpp, not 6bpp. If that was all there was to it then it would have been a very simple fix, however, the problems were deeper than that. Neither of the upper 2 bits of the data are used in the traditional sense, to simply extend the available colour palette. Ignoring the 6th bit for now, the one that was being used as transparency, I started looking at the bit that wasn't being decoded, the 5th bit. There was clearly data there, it wasn't just unused rom as you'll sometimes find. Infact the data present conincided with the tiles that were being rendered with the wrong colours in the game, logically everything would suggest that the decode was simply missing a bit, and hooking that up should fix the colours as it would then be able to address the correct colours. It didn't. Usually if you increase the bpp of a set of graphics it allows the colours directly after the current palette to be addressed in addition to the ones already being used. For Dynamite Duke something different was going on. Regular System: 4bpp decode | Pal#1 Colours 0-15, Pal #2 Colours 16-31, Pal #3 Colours 32-47 and 5bpp decode | Pal#1 Colours 0-31, Pal #2 Colours 32-63, Pal #3 Colours 64-95, for Dynamite Duke however: 5bpp decode | Pal#1 Colours 0-15 & 256-271, Pal #2 Colours 16-31 & 272-287 etc. Basically the extra bit is being used by the hardware more as a palette bank bit, grabbing the extra colours from a completely different part of the palette. I needed to clean up the driver a bit, remove some palette hacks that were already in there, and rework a few things, but by implementing that logic I at least got the right colours on all the scenes, except one, the map scene. For the map scene it turns out there was another error in the driver. As the previous decode didn't allow for accessing of colours above 255 one of the layer disable bits had been incorrectly hooked up as a palette bank, probably because the map screen happened to have that layer disabled and also by chance needed the higher palette codes. An easy mistake to make. Removing that hack, and correclty hooking up the layer disables had the advantage of also getting rid of some garbage sprites left on the screen during 'continue' etc. That just left the 6th bit, marked as transparency. Finding out the use for that was pretty straightforward, it quickly became clear that it was actually a priority bit (which is basically how it was being used anyway 'transparency' was rather misleading). With everything fixed up Dynamite Duke looks better than ever, and one of the longest standing bugs that I can remember has finally been fixed.
- 30th September 2007: David Haywood - I've hopefully fixed the colour problems from the first boss and beyond in Dynamite Duke. Note, the background is now correct in shots 3 / 4 onwards.
- 0.118u3: Changed NEC V30 CPU core to use a 16-bit data bus [Aaron Giles, Phil Bennett, Pierpaolo Prazzoli].
- 0.104u2: Renamed (dynduke) to (dyndukf), (dyndukj) to (dynduke), (dbldyn) to (dbldynf) and (dbldynj) to (dbldyn).
- 0.103: Pierpaolo Prazzoli and Guru added clone Dynamite Duke (Japan). Pierpaolo Prazzoli, Bryan McPhail and Guru added clone 'The Double Dynamites (Japan)'. Changed parent description to 'Dynamite Duke (US)' and clone 'The Double Dynamites' to 'The Double Dynamites (US)'.
- 0.99u7: Curt Coder fixed background layer color in the first levels. Added 'Bonus Life' dipswitch. Removed 'Unknown' dipswitches.
- 0.66: Changed clock speed of the 2x V30 to 8MHz.
- 0.37b16: Nicola Salmoria decrypted the Seibu sound CPU, giving sound in Dynamite Duke. Added Z80 (3579545 Hz) CPU3 - Sound works now.
- 17th June 2001: Nicola Salmoria decrypted the Seibu sound CPU, giving sound in Raiden (alt), Dynamite Duke and Toki (original).
- 0.36b12: Changed YM3812 clock speed to 3579545 Hz.
- 0.36b10: Bryan McPhail added Dynamite Duke (Seibu Kaihatsu 1989 (Fabtek license)) and clone 'The Double Dynamites'. Known issues: Coins are controlled by the sound cpu, and the sound cpu is encrypted! You need to play with sound off at the moment to coin up. The background layer is 5bpp and I'm not 100% sure the colours are correct on it, although the layer is 5bpp the palette data is 4bpp. My current implementation looks pretty good though I've never seen the real game.
- 17th November 1999: Bryan McPhail sent in a driver for Dynamite Duke / Double Dynamite.

LEVELS: 9

Other Emulators:
* FB Alpha



Romset: 5280 kb / 28 files / 1.63 zip