Archive for August, 2012

I’ve continued to work on Little Robin and started making some more sense of the displaylist structure, as well as fixing the screen resolution to 336×288. Layer clearing / scrolling is still incomplete / wrong but the HUD graphics now appear, as does the title screen, a mini-map when starting the game, the boss death animation, and the high score table.

Here is an updated video (in which I’m not trying to play the game properly) to show the new progress.

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

Also, there is an old video Dox put on YouTube recorded from his original board, the lack of solid colour in the background is an artifact of it not really agreeing with his monitor tho. As you can see the smiley faces that come down between levels are missing in the emulation, as is the background to the mini-map. Fixing those is my next target.

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

Also if you need a reminder of how things looked before the progress over the last 24 hours, you can check the old video here

I don’t usually do multiple video updates, but I figure people might like to see the various steps involved in making progress from time to time.

Little Robin by TCH is one of those games that continues to taunt MAME developers and evade emulation.

It’s not that either the game, or the hardware happen to be anything spectacular, it’s just the way everything is hooked up is rather awkward, from the sound (which Kale fixed up a few months ago) to the video.

Essentially the game has a ‘VDP’ type device, all video hardware is accessed through ports, the palette DAC, the graphical data, and the display lists.

In reality it’s just a basic layer of indirection, but it presents quite a few unknowns (correct addressing, which writes should auto-increment the target address etc.) which have slowed down emulation.

The game uploads all the graphic data to this device, so the addressing has to be correct in order to ensure data doesn’t get incorrectly erased by new data, which is what I thought was happening before hence the platforms etc. ending up corrupt after starting a game.

Now I’ve decided that assumption is incorrect, furthermore I’ve decided that the spritelist isn’t a spritelist after all, but more of a command based blitter, capable of writing data to a front buffer and a back buffer. The reason the background and platform data was being overwritten appears not to be due to bad addressing, but because it simply isn’t needed anymore, the data has been copied to the back buffer and can therefore be replaced with sprites without consequence. This isn’t an unreasonable line of thought because Wheels & Fire, and Reality Tennis, both other games from TCH are also dual framebuffer + blitter based, albeit with more direct access but a more complex blitter.

Of course this is slightly trickier to implement, and it becomes important to understand which writes are meant to trigger the ‘render’ operation (or if things should be rendered as they’re written) Layer clearances are also a problem.

I’ve started improving the driver based on these assumptions and already I’m seeing some good progress. There remain some issues tho, some ‘sprite’ (blit commands) are misaligned, presumably because I’m not correctly interpreting other commands of different sizes (the normal ‘sprites’ are 6 words, but there are other bits of data sent too and I’ve not managed to figure out how the hardware decides what the data is meant to be yet) As a result ingame looks better, but the title screen has a large amount of corruption, some backgrounds are cleared prematurely (or not cleared at all) and the HUD with the score / credits is never displayed.

Still, it’s a step closer to understanding how things work, even if the whole thing is strung together with a fair number of hacks and (incorrect) assumptions still. At least things are starting to fall into place now.

The pictures below probably make the current emulation status look a fair bit more complete than it actually is:

The video is more reflective of how things actually are, as you can it’s still very glitchy, there’s an entire intro sequence before the game starts that you’re not seeing because my handling is wrong:

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

The game, as you can see from the video is a pure Snow Bros rip-off, using Robin Hood inspired characters, it also seems to run at a rather wacky resolution of 320×288 in 256 colours (actually it’s 336×288), something I’d more commonly associate with an Amiga; I assume it’s a PAL based video mode running at around 50hz, which is no doubt why the game is a pain to get to sync properly on many arcade monitors (and thus even harder to run tests on). I did check if the VDP / blitter was related to the Amiga’s blitter, but it doesn’t appear to be. Hopefully I can manage to get it to a stage where it works well enough to come up with some hardware tests to nail down the proper behavior and remove some of the hacks holding this together.

Oh, and for anybody wondering what happened to the MAME SVN

“Due to circumstances beyond our control, the currently hosted SVN @
svn://dspnet.fr/mame/trunk is down. This is due to a hardware error
on the host machine and as of this time it is unknown when SVN will be
back online, or if it will be hosted elsewhere. This note is to let
you know that any submissions you have in the works will not be able
to be applied until after the SVN is officially back online.”

You can still grab the latest files from the GIT mirror if needed tho, although don’t expect to see any fresh checkins until the issue with the main server is resolved.

It’s very easy to moan about people not giving back to MAME, and sometimes it really does feel like you’re throwing what you’ve created out there and people only really speak up when they have something to moan about.

Every project, in order to succeed however does need some form of user base, you need your testers, people following the project, people making sure everything actually works as intended and maybe it is natural that the majority of those only speak up when they actually have a problem.

Even so I’ve always been a fan of sites which do try to give a little back, even if it’s not in the form of code to directly advance the project it can be good to know that drivers are being used and thus tested, especially obscure ones. Part of MAME is about bringing history to the forefront, educating people on what came before, and for that reason review sites such as the MameZach one are of interest to me.

While he is no longer doing daily updates the previous reviews are all still accessible, with the occasional new one posted and they represent the views of a fairly regular guy playing some arcade games, not an expert by any means, but that’s part of what makes it interesting, it helps give some perspective on what your average arcade goer might have thought of some of the titles and with a focus on the less common ones it shows that there was life in the arcades beyond the obvious shout-out titles.

With that said, I suggest you check out the site, the reviews might not be in depth, but it is still a contribution, drop a few comments his way and continue the chain of giving back.

The other site I’ll mention has been something of a staple pin in the MAME community for a long time, and that site is MARP. It might appear crude and stuck somewhere in the late 90s in terms of site design but the site is the proverbial treasure chest of goodies. Game-breaking Tool Assisted replays might be all the rage these days, but MARP has none of that it’s just a good down to earth honest site where people can upload replay files recorded from MAME, and there are some *really* good ones in there.

Not all of them are recorded with current versions of MAME, which is a shame, but when they are they can be really useful for just watching a game be played properly, while keeping your eye open for bugs (some of which get reported when the replays are uploaded) Obviously it’s not always clear if a bug if an issue with the original game, or an emulation bug, but having a replay, and a clear reproducible way of seeing the bug in action for yourself at least gives you the first steps needed in order to start looking at it. Sometimes when it comes to fixing bugs simply having this is vital.

One replay which caught my eye recently, due to the bug report was an upload by player ‘WEDNESDAY’ for the game Mission Craft, the text alone didn’t really make the bug clear, but watching the replay demonstrates a rather unusual issue. Thanks to MAME’s –aviwrite feature I’ve converted this replay to a YouTube video (hopefully the uploader won’t mind, I’m sure it was uploaded for people to watch)

Mission Craft – MARP Replay – Player WEDNESDAY

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

As you can see, after a couple of stages the music goes very quiet, and shortly after all sound stops working, and while the Q1000 sound emulation is still considered preliminary that’s still slightly unusual behaviour. The fun doesn’t end there tho, part way through the second loop the game developers a random pausing problem, whereby the game will continually pause every few seconds, with the CPU sitting idle, a state which is permanent until the game is turned off / reset. Assuming it’s not an original game bug it makes me wonder if it isn’t an issue with the Hyperstone timers, I have my doubts over their general accuracy anyway due to the weird game speed issues in Raccoon World, another Hyperstone CPU based game.

Anyway, if it wasn’t for that replay and people actually using the emulation code we write, that bug might never have been highlighted, and while I haven’t thus far been able to fix it, at least we have it on record now.

The same player also uploaded a replay for Semicom’s Wyvern Wings which runs on very similar hardware, but interestingly that suffers from no such problems and instead just makes for an awesome and seemingly bug-free replay. The sound is still preliminary because it uses the same sound chips as Mission Craft and the emulation is only a recent addition, but you can still hear the ripped off ‘Metallica’ tracks in a rather mangled form ;-) Replays like this are useful because quite often when emulating a game, unless you *know* there is some devious protection you won’t play it all the way through, having a good quality replay for the entire game makes it much easier to see the whole thing and if there are any graphical bugs you need to fix for example. In this case, things look good.

Wyvern Wings – MARP Replay – Player WEDNESDAY

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

Of course replays don’t magically just work, they rely on the emulation being entirely deterministic, meaning the same set of inputs will always give the same outputs, something which frustratingly doesn’t always happen. Sometimes uninitialized variables can be the source of the non-deterministic behaviour, that’s never a good thing, in the past MAME’s sound output buffers were somewhat tied to the host soundcard meaning status registers could sometimes act differently, other times non-deterministic random number generators were used rather than the core ones, or actual emulation code was put in the video update functions causing things to vary with framerate which again is bad. That still doesn’t help me understand why some Kaneko games like Shogun Warriors and B.Rap Boys don’t want to record and playback properly, I’ve been through my checklist, even tidied the driver and devices up significantly in the last release and still they persist to not record and playback properly, even if you make sure to clear out your NVRAM beforehand. This is frustrating because I know there are hard to reproduce bugs in at least B.Rap Boys. Such frustrations are part of the rollercoaster of emulation I guess, I can only imagine the frustration of the player in the first replay demonstrated here when his game just freaked out mid-way through the 2nd loop, althougly thankfully that freakout was properly recorded!

Anyway, that’s drifting off-topic, I mainly wanted to highlight those two sites as examples of how simple bits of community effort, and people doing what they enjoy, or do well can actually be of benefit to MAME and while you might think it silly for me to highlight a site such as MARP which has been around forever I have a feeling that many newcomers are probably unaware of it.

Just remember, we put a lot of work into MAME, and sometimes it’s good to see people actually doing things and giving back a little in their own ways :-)

For the developers out there the latest announcement on mamedev.org is rather important.

As of now there is one official SVN server (and the GIT mirror) for both the MAME and MESS projects, which now share a single development tree / team.

This means the old MESS SVN is now retired (although can still be used to see revision history of the MESS files if you require that)

The projects, for now, will retain their individual identities, and releases, although the UME target still exists within the new SVN and can still be used to build a unified binary, which I’ll continue to offer here after each release.

As long as people are sensible about this then it offers some good benefits as far as regression testing goes. Previously MAME / MESS changes were only synced between the projects at various intervals in single large commits, which made it hard to see the exact impact of individual changes from the opposite project when doing regression tests and trying to track down the exact cause of bugs. For shared drivers, like the Genesis this was problematic because most of the games run in MESS, but most of the changes occurred in the MAME tree and weren’t visible with a fine enough granularity in MESS.

Now it does become more important that developers test their changes better as not to break anything, but it hopefully means that large scale search+replace type changes will automatically get applied to both projects, at the same time eliminating the periods where the codebases weren’t even really compatible anymore. It also however means that if somebody does break the compile it’s going to get noticed more quickly, and fixed more quickly because it’s the active tree for both sets of developers.

Official read access to the official SVN should also make it easier for external contributors, they have one SVN they need to be concerned with keeping sync with, and one place to submit changes for either project, which can then be reviewed by whoever has best knowledge of the systems which again comes heavily into play when systems / devices are shared and it isn’t obvious in which project the primary development has taken place. (For example the TMS CPU and device source files are in MAME, but had been almost exclusively developed by MESS developers, that no longer matters because the point of contact is the same)

I hope one day we do see UME built and hosted as an official build (and I feel it should be the default target in the makefile of the new setup because it’s a ‘neutral’ target and the one which ensures that all the code compiles) Actually I still hope that one day UME becomes ‘MAME’, fully inclusive of everything, and what we have as MAME now just becomes ‘MAME classic’ with only pure arcade video games, no gamblers etc. but that’s a long way off I feel, if it ever happens.

One word of warning, the new SVN *does not* contain the MESS associated Artwork (scans of Chessboards etc.) This needs to be handled as an external project as it is for MAME; ideally the MAME artwork site and projects will take up the existing files. This hasn’t been done merely to piss people off, it’s simply to make a clearer policy that everything included with MAME/MESS should be original work, and when you consider that in the future things like the Pico are going to need scans of the books then it’s clear that including such artwork with the project would be of highly questionable legality and best handled outside the core project.

Anyway, this should be the dawn of a new era for development and it will be interesting to see how things go. Hopefully the strengths of both teams can be combined, and awareness of where the skills of each team can be applied in the opposite project is increased; it only takes one somebody to notice one SVN check-in and think ‘I could help with that’ for some good momentum to build up.

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

This is based on MESS SVN revision 15977 (GIT Mirror)

I’ve decided to stick with doing a single package containing source + both 32-bit and 64-bit binaries now, it’s a larger download but less confusing than requiring users to download separate resource packages etc.

The 0.146u5 release can be downloaded here.

The changes from MAME 0.146u5 can be read about here
The changes from MESS 0.146u5 can be read about here

General Release Commentary

I’m still hoping we see some movement towards a proper unified SVN because I’d like to do some further work on rewriting most of the Genesis emulation which would benefit greatly from a single SVN when it comes to regression testing because under the current structure multiple changes just end up lumped together at sync points, but we’re still not quite there yet unfortunately. Anyway, I did start some of that rewrite work in u5 and killed off a bunch of old code in the progress by allowing System 18 to use the current Genesis VDP code rather than a legacy copy, although be warned the System 16/18 drivers are in a state of flux due to work by Aaron and a fair number of the System 18 games don’t have the I/O hooked up properly at the moment it would seem.

Of course, that’s not very interesting, u5 as a whole however is a noteworthy release for several reasons. Top of the list of reasons is the work done getting several games / systems to a ‘working’ state. Sky Destroyer, Cycle Maabou, Last Survivor, Cybertank; that’s 4 rarities right there and while the pair of Taito games might not have sound yet they’re still working well. Cybertank has seen the sprite rendering improved by ‘hap’ since the last release so sprites are no longer leaving trails and the current state of the others can be seen in the YouTube videos on previous updates here.

There’s also the Space Invaders / Qix Silver Anniversary Edition addition, which is more interesting from a hardware point of view than perhaps an end user one. The games appear to be ported rather than running on an emulation based board and they make use of an H8 CPU which has seen a few bug fixes made by R.Belmont in order to get them working, and these bug fixes which will no doubt be useful for other platforms using CPUs from the family.

Pairs Redemption is also something of a rarity which as a kiddie friendly game sits in stark contrast to the original Pairs / Hot Memory games which were strictly 18+ titles.

From the MESS side Kale has been making good headway with Nintendo’s dud of a portable the Virtual Boy (which again is resulting in CPU fixes and the like that will no doubt be of use for emulating other systems like PC-FX) as well as the Japanese PC-88, home to a fair few original titles. The Sharp X1 software list also saw a bit of bulking up with a couple more rare Japanese tapes identified and listed for testing.

Improvements were also made to the emulation of the ever-popular C64 with Curt Coder adding support for some protected disk image formats amongst other things.

Another highlight is Micko adding support for an internal mouse pointer on games with clickable artwork making it easier to use such systems while also highlighting a bug in MAME/MESS which is causing screenless systems to only update their artwork at around 15-20 fps; I always thought the reels on the Fruit Machines seems a bit too laggy / slow to update. No fix for that yet, but at least it’s confirmed as an issue.

To tie a few things together Wilbert Pol (judge) submitted his work on the PCE video chips although the new code is much slower and has it’s own share of issues right now so is treated as a separate driver for the time being. The submission is interesting because the PC-FX requires the same video chips, having them as a device makes this easier, and with all the Virtual Boy work going on, and the common CPU core it shares with PC-FX I doubt the timing is purely coincidental.

Beyond that, a lot of code cleanups, and reorganization; hopefully nothing too damaging (I tested everything likely to be affected by changes I’ve made myself, and while as I mention there are some remaining issues with Aaron’s work on the Sega systems I imagine they’ll be cleared up sooner rather than later) Some people might comment on the sheer number of ‘new’ Fruit Machine sets in this release, but in reality there’s hardly anything new at all, it’s just reorganization of what was already there into proper sets, moving towards a greater goal of documenting everything as best we can.

There are probably more things I’ve missed, it’s been a busy period for both projects, if anything crosses my mind I’ll do a quick update to this text as usual :-)

(note, I’m not ignoring progress on some ‘lesser’ systems in MESS, but if I know nothing about the systems, and nobody posts work in progress pictures from them then I really don’t know what to write about them)

Right, bit of a round up post here showing some work from various developers.

The Rare Sega game that was won on auction a while back was Last Survivor, and is quite possibly literally one of the Last Survivors, very rare game using Sega’s FD1094 encrypted CPUs which thankfully was alive and could be read out by Charles MacDonald. Aaron Giles has actually posted an update about this, with a couple of screenshots etc. The game was apparently location tested in the UK because one of the Speccy magazines did a review of it, but I guess it failed, or was just too expensive for most arcades. It also got a port to the FM towns, but the arcade version is graphically superior and also allowed linking up to 4 cabs for an 8-player pre-‘Wolfenstein 3D’ deathmatch experience (although MAME can’t do this, yet). Anyway I’ll post a video at some point too, because people seem to like videos and it helps show that some cool stuff does still happen in MAME but for now check Aaron’s page :-)

*edit* here is a video of Last Survivor, I’ve made a few comments about the game / control setup in the video description, it’s a little awkward on a PC and really needs the original rotary controller to play well.

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

Speaking of videos, Kale got Cycle Maabou working when improving the I/O simulation code for Sky Destroyer. It’s a rather unique Taito game, just as rare as Sky Destroyer, although probably not as rare as Last Survivor above. You play the role of a guy on a unicycle, and must performed timed jumps to land on various items to collect points, holding the button longer does longer jumps etc. At the same time you need to balance your character using the paddle / spinner control so things can get quite tricky. Each stage gives you a target score, here is a video of me failing on the first stage. Note, no sound as of yet, I’m hoping Phil B. can hook it up, he mentioned he was looking at these MCUs in a comment on one of the posts below (with a view to actually emulating the ones which were dumped for Taito’s Gladiator)

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

So, thank Kale for that one, I do wonder if the colours are correct on those traffic cones tho :-)

I’ve been hacking away at the fruit machine drivers a bit more, sorting things, moving things around based on hardware profiles, and adding basic CPUs in places where they can be added. One that has the potential to be quite interesting is ‘Big Chief’ which is one of the few (possibly only, or at least the only one there are dumps for) MPU4 games using a Dot Matrix display extension. The Dot Matrix is actually driven by a 68k and the good thing about working in MAME is that it’s quick and easy to hook anything up for a quick test. I haven’t looked at the MPU4-video board comms yet, but the video roms do show a boot screen at least. There’s a video of the real thing on YouTube.

*edit* Also identified Clickity Click as a Plasma game, and one for which we have the Plasma roms too. The Flyer at Mametesters was useful confirmation :-)



‘Apache’ and ‘Elite’ also seem to be Plasma based, although the Plasma roms for them don’t appear to be dumped, and I can’t find any flyers to confirm.

Still a staggering amount of sorting out, identifying and labeling to do with the various sets tho, working out which are original, and which have been hacked etc.

So that’s your mini-round up, this progress will all be in u5 when it gets released.