Archive for December, 2015

MAME 0.169 was released over at mamedev.org earlier this morning as the final release of the year.

There have been a lot of ‘under the hood’ modernizations which will hopefully have minimal impact, although do require updated compile tools, so if you build your own make sure to update your environment.

There are no major surprises with this one, although work done on some older drivers is definitely noteworthy. Vas Crabb’s work means that the Zaccaria’s Laser Battle / Lazarian driver (which also runs Cat and Mouse) got a fair bit of attention, making MAME easily the best emulator for those games now. Previously, despite being marked as working they weren’t really properly playable.

I recorded this video of Lazarian a couple of weeks ago, although I should really re-record it as things have been tweaked and further improved since then, as you can see all waves are now playable tho.

Content not available.
Please allow cookies by clicking Accept on the banner

Cat and Mouse also gained much improved colours, as well as working music / sound effects which really is the highlight of the game; it’s not surprising Zaccaria heavily promoted the audio side of this game in their flyers etc. because every level has it’s own melody, not the most common feature back in 1982. Unfortunately we’re 99.9% sure that the sprite rom on this game is underdumped, probably incorrectly marked on the PCB and therefore ended up being dumped as the wrong size (much like the last program rom – which is why set 2 doesn’t work still) Flyers for the game show graphics that simply aren’t present in the set we have. I’ve uploaded a video of the current emulation state of that too anyway, and again we’re easily the best emulator for that game now. If anybody has a PCB for Cat and Mouse we’d really like some videos, a redump of the gfx ROM as a larger chip type, and closeups of a few parts of the PCB.

Content not available.
Please allow cookies by clicking Accept on the banner

You’ll notice that Run and Gun is relisted in the new working section despite being ‘working’ for a long time. The reason for this is that the game never really worked properly, we ran it in single screen mode, but even then it was confused, the default option upon starting a game was ‘play against the other screen’, and option which shouldn’t have appeared at all in single screen mode and worse still selecting it would cause the game to hang. The game now correctly runs in single screen mode, and also has some clones added with the dual screen setup (they use the same ROMs because it’s actually the same PCB with a different dipswitch setting and a video demux board added, but in MAME it’s easier to support as a clone)

A video of it running in dual screen mode can be seen below, there are still some minor video issues in this mode, but you can actually play a full 4 player versus match now.

Content not available.
Please allow cookies by clicking Accept on the banner

One thing that shouldn’t be overlooked is finally getting a bios dump from the GameKing handheld. This isn’t working yet, but does boot to the internal 3-in-1 menu. The system has a resolution of only 48×32 pixels despite being released in 2003(!) I’m sure there were general household appliances with higher resolutions at that point. As I said, not yet working, but I do always enjoy seeing progress on these obscure handhelds, and dumping the bios / roms when they’re not in standard packages (they’re inside small epoxy blobs) is always a challenge, one that in this case is now out of the way.

The new ‘Knock Out’ set is quite interesting too, it had been sitting there overlooked and not added for many years because it had simply been described as ‘copyright string removed’ and ‘no other changes’ Turns out this isn’t actually true. Below is how the existing Knockout set in MAME looked (and the original Triple Punch game on which it’s based)

Now.. the new set looks like this

The copyright is indeed gone, and the set has definitely been hacked a bit for the Italian market (all the life dipswitch settings give you 2 less lives than mentioned in test mode) however there’s also this extra ‘Treasure’ listed on the title screen, and a bonus round to go with it. Also the ‘bean’ type character is black, making it more stealthy, although I’m not 100% sure if this is intentional or if this set should use different colour proms, the character colour in the bonus round is a bit ugly too. Either way, a surprising discovery.

… more to come

The Dooyong developed shooters are some of the more original Korean efforts of the 1990s, while other companies were simply bootlegging hardware ideas and code and hacking them into new looking games, Dooyong actually created their own games and used their own hardware designs.

The quality in general was fairly average, but they’re not terrible to play.

The emulation of them still had some bugs too, each game uses a slightly different mapping (same basic ideas, but all the ports moved around, slight changes etc.) which means sometimes bad assumptions get made, or things get missed. One game in the driver that had always had issues was Pollux with visible problems even on the title screen, and a number of MameTesters bugs relating to it.

We knew from earlier work on Flying Tiger that the hardware had some palette banking, it just hadn’t been hooked up on Pollux.

I spent a bit of time hooking it up, but was initially a little confused, we knew that Pollux was missing a palette cycle effect on the title, but none of the colours in any of the palette banks were cycling. That actually turned out to be a simple case of a missing vblank flag. The 2nd palette bank uploaded by the game is for the most part a darker copy of the first, although it was quickly obvious that the title screen was meant to be using that darker copy and not the one that it was using before, the darker copy is where the palette colours were cycling, and also where the correct colours were for several other title screen elements rather than entirely just darker versions like the rest of the time the game is running.

Now, when the palette ‘banking’ was hooked up to Flying Tiger we didn’t actually treat it as banking, we treated it as some ‘ram write protecetion’ meaning the bank bit was being used more like a RAM write protect flag than actual palette banking. This struck me as wrong, and a little more studying of a reference video for Pollux gave further weight to my theory that the hardware really did want to do real palette banking instead.

What I’d noticed is that in Pollux, when a bomb was released, the screen was meant to show periodic brighter pulses for the duration of the bomb. What I found out is that we’d actually been rendering the whole of Pollux with the wrong palette, the brighter version, since it was first emulated. That brighter palette was actually only meant to be used when you used a bomb, that was the entire point in there being two palette banks, a simple and quick way to turn the whole screen brighter / darker without having to write a new palette during gameplay. This simple bankswitch on the palette actually fits well with Dooyong’s general design of this hardware – leaving the CPU as free as possible to just run the game logic, not be updating palette data and tilemap data)

I implemented this, it turned out the selected palette bank for writing is also always the visible one. As a result the game looks much darker now, which greatly improves the contrast between backgrounds and sprites.

There was a MameTesters bug concerning the character portraits in the ending, after fixing the above issues I checked and that was fixed too, not too surprising.

Title screen – Left = Bad palettes, Right = Good palettes

Here’s a video from MAME with the fixes, it’s got cheats enabled, but allows you to see all scenes in the game for reference.

Content not available.
Please allow cookies by clicking Accept on the banner

The Flying Tiger code was also updated with this new knowledge, although I don’t know if anything has changed in it as a result. It’s possible some of the other games in the driver should have this hooked up too, I plan on checking that soon.

One of the most important things we can do as a society is make videos of things, take photos of things, and share them for the world to see, you never quite know when what you’ve done might come in handy, or prove to be the only remaining reference that something once existed, it continues to amaze me how even things that were at one point popular are now difficult to find any visible trace of now.

This is true of arcade games as much as anything else, and I Know when looking at the fruit machine and other non-video games the situation is even worse, sometimes not a single photo of a machine anywhere.

While looking at Mega System 1 it was noted in the source that the game P47 sets some other bits during the Jaleco logo, effect unknown. Luckily, in this instance there was a video on YouTube of P47 booting up. It’s a terrible quality video, but it still gave us an idea of what was missing.

Content not available.
Please allow cookies by clicking Accept on the banner

some kind of trail effect…

I poked around with the code a bit, and have attempted to implement this in MAME.

Content not available.
Please allow cookies by clicking Accept on the banner

I don’t know if this is actually correct, at the point where they want the trails to vanish they adjust a parameter, the original video isn’t really clear enough to show how the trails are removed, so I’ve had to guess. If anybody has a P47 PCB and can record a better quality video it would be appreciated, the one on YouTube was more useful than the original poster probably ever thought it would be, but not really good enough to say my emulation is correct :-)

Another long-standing problem with the Mega System 1 driver is the lack of character movement in the attract modes of 64th Street and Chimera Beast. A similar problem was fixed in Cybattler a long time ago by handling a mirror address for main RAM, easily noticed due to unmapped reads/writes, but the other two games weren’t making any unmapped reads or writes.

Today I decided to try a little experiment. I knew from the ‘nmk16.cpp’ hardware that sometimes the 68k is hooked up to RAM in a way that means the byte write behavior is a little unusual. The standard way of handling byte writes is to make sure only the byte of the word that is being written to changes, leaving the other half of the word alone. Due to the way the 68k works it’s also possible for that hookup to be slightly different, so that a byte write alters the content of both bytes in the destination word, mirroring the written byte in the other half.

Most games break if you implement things the latter way, they assume they can write bytes without them corrupting the adjacent byte. I quickly changed Megasystem 1 to use that method to see what happened, the result, a working attract mode. I do wonder if this is part of a bigger picture, NMK and Jaleco often worked together, there are Jaleco games in ‘nmk16.cpp’ and NMK developed several of the titles for Jaleco’s Megasystem hardware too, it’s possible some hardware ideas / designs were also being shared.

While only Chimera Beast and 64th Street show obvious improvements from this, and both of those are ‘Megasystem 1 Type C’ hardware, I’ve hooked it up to all hardware types (except D, but that’s very different and did cause the game to crash) I’ve not noticed any real differences this way, most games don’t make many byte writes, some avoid them entirely. St. Dragon makes an unusually high number so it might be worth checking / verifying that nothing has broken there with these changes, it is afterall possible that only one of the board types has this design.

Here are some revised attract mode videos from the games. The 64th Street one also shows the environment damage that was previously missing (Kale fixed it last week) and the Chimera Beast one, to my surprise, shows the Mosaic effect, it’s used ingame when you get grow.

Content not available.
Please allow cookies by clicking Accept on the banner

Content not available.
Please allow cookies by clicking Accept on the banner

Following on from the post about the rare PV1000 game being dumped we have saw another rare Japanese console / computer game dumped. This time it’s one for the Tomy Pyuuta system, an early ’16-bit’ machine.

The Pyuuta games while not graphically spectacular or ambitious do seem to offer some fast paced arcade-like gameplay, and this one is no exception.

The game in question is “Bermuda Triangle”

Despite the initial appearance (what looks to be a massively oversized ship at the bottom of the screen) it has no connection with the much later arcade title released by SNK. This is a fast and challenging wave based shoot / dodge game.

This one was also rather costly, with most of it being paid for by MooglyGuy this time around.

Content not available.
Please allow cookies by clicking Accept on the banner

The Jaleco Megaystem 1 driver is broken to an almost shambolic level, nothing really works as it should. This is mainly down to interrupt handling, timing, sometimes subtle protections, and generally things not being understood well. It did used to run ‘better’ but even back then it was held together with hacks.

If you’re expecting this post to be about Ninja Kazan (Iga Ninjyutsuden) being fixed, or the random sprite lag being fixed, or Takeda Shingen / Shingen Samurai-Fighter crashes being fixed then stop reading now, they’re not, I have no clue how to fix them without resorting to the hacks of old, and I’d really rather not do that.

Kale did add a video RAM mirror allowing the background destruction to function correctly in 64th Street (characters still don’t move during attract tho) and so I decided that while fixing the bigger issues with the driver simply wasn’t going to happen it was probably worth making some other improvements for the time when that does happen.

It has been known since system11 acquired a PCB and made a video that there was a graphical effect missing in Takeda Shingen, A Mametesters report was created with 2 handy videos demonstrating the effect in Takeda Shingen and the P-47 test mode.

This was a while back, and in the meantime the Final Burn Alpha devs emulated the effect due to having more active devs on the MS1 driver than we have.

Since nobody else had done it yet, and it was easy enough, I ported the FBA code that dink and iq_132 had written back into MAME; since the FBA code was based on the MAME code in the first place this wasn’t too difficult.

The result can be seen in the vidoes below. Note, I’ve used the English language set ‘Shingen Samurai-Fighter’ instead of the Japanese language set system11 used for his video. Also note, the game really is broken beyond being playable in MAME right now and crashes out at the start of level 2 even in this test video. The effect can be seen after I pick up the power-up which turns my sword into a flashing one, and then kill some enemies, with the effect emulated they ‘pixelate’.

Content not available.
Please allow cookies by clicking Accept on the banner

The P-47 test mode video demonstrates more clearly the settings for Mosaic that are available. (same settings as Mametesters reference video have been used, you can see the effect creates the same pixels in MAME)

Content not available.
Please allow cookies by clicking Accept on the banner

The effect is also used on the Jaleco logo in P47, after the spinning squares, looks a bit ugly, but should be correct. There’s actually another missing effect on the Jaleco logo here, the initial graphics should draw sprite trails, we’re going to have to look into that one too, could once again be the only place it gets used(!)

Content not available.
Please allow cookies by clicking Accept on the banner

Obviously these will be more interesting to you once the driver works properly again (which like I say, I have no ETA on) but until then you might appreciate seeing them anyway.