I do like it when rare clones of existing games turn up, some have proven to be more than just a little elusive over the years and the subject of this article is one such clone.
MAME has emulated the IREM title ‘Fire Barrel’ for a while now (with significant improvements a few years back) and if you’ve ever booted the game in MAME this Japan region warning and title screen will be a familiar sight.
Fire Barrel is quite a rare game compared to some other Irem titles but even rarer is the export version of that game known as Air Assault. For many years one could be found at the Trocadero in London, but apart from that nobody had seen a trace of it. We knew it was an official version because the tiles for the ‘Air Assault’ title were present in the graphic roms, just unused.
System11 has been a good source of clones in the last year or so, dumping every board he comes in contact with and often uncovering previously unknown revisions of existing games (especially Korean ones where there is no real indication whether something is an alt version until you’ve dumped the roms).
Anyway, to cut the story short one of his new arrivals was Air Assault, the very same Air Assault board that has been sitting in London for years. It looks like it might have been a location test version based on the ROM labels, although I think the code is actually a newer revision than the Japan set.
Luckily he got the board just in time, he’s also put up a strongly worded warning about a leaking capacitor problem that he’s witnessed plaguing these IREM boards, with this one already showing the first signs of that.
Getting this working in MAME wasn’t entirely straightforward, it uses a different encrypted sound CPU when compared to Fire Barrel, in this case the same as Gunforce rather than the same as R-Type Leo, however, there were some gaps in the encryption table causing the sound code to not run correctly and report a ROM error although I managed to fix them by using the code from the correctly decrypted set as a reference.
So here are some screenshots of Air Assault running in MAME, possibly salvaged from the only remaining board in existence. It might ‘only’ be a clone, but it’s one I’m very glad to see dumped.
This just missed being permanently lost, did it not?!
Amazing!!
Thank you, Haze, and MOST ESPECIALLY SYSTEM11!!
I read System11’s failing electrolytic capacitor post, it needs correction and I don’t see on his site where to post it. My guesstimated edit:
“Aside from the flush fit ones (couple on each game), just cut the old ones off at the legs for a safe and easy removal later, by heating each leg and pulling them out that way. Otherwise there’s a decent chance of damaging the hole.”
Fire Barrel is one of the few Irem games I like. It’s nice to see a version like this recovered. Did other manufacturers have similar problems with any boards?
Fixed, it was just badly worded.
Yesss, finally world version in MAME, thanks Haze :D
any ETA of 153
and great work as always. Thx :)
Konami ones with their all-in-one sound custom are time bombs too. That’s Xexex, X-men, Violent Storm, etc. They put SMT caps on top, customs on the bottom, sealed it with potting compound and soldered them in. The caps destroy the tracks while the black compound hides the damage until it’s really bad.
Like a child in a candy shop.!
Nice one again & great work as always.
These prototypes can’t hide for ever THE MAME TEAM are gonna find them sooner or later, the thing is these prototypes & non export to other countries boards are more than likely being held in boxes gathering dust with probably no name on them.
Fire Barrel was one of the first games in Mame I finshed using the cheats, so i’m looking forward to doing the same with Air Assault & seeing if I can spot any difference’s.
THANKS
Nice clones,maybe X222 also needs look at sound
without the sound roms x2222 will never have sound. the sound roms probably don’t exist anymore.
maybe se yong jang knows about the more sound information who develope the x2222
Is a lack of sound roms also what’s holding back Ghox, Vimana & Fire Shark?
the lack of the internal rom from the MCUs, yes, all the proper music sequence data etc. is inside them.
unfortunately we have no proven way of dumping them, for all the hype there was over decapping a few years back it came to very little as the most important chips (like those ones) didn’t get done but rather a flood of near useless common ones and now we don’t really have anybody to even attempt the more complex cases.
as you’re probably aware there are some cheap and ugly hacks using very large samples of the music to work around this in some builds, but that’s more a bootleggers approach than an emulation one and isn’t exactly a reliable / correct / acceptable way of doing things just a cheap hack.
I do not believe anybody has any additional information or it would have been shared already.
no.. there are still plenty of sets in a worse state than 0.152, so it seems unlikely although I have a gut feeling people will just forget about that form some cases and continue anyway. (There comes a point when you really just have to, not having releases is worse than having a release where some systems people don’t use much are temporarily broken)
Unfortunately I say ‘temporarily’ but it’s cases like that (where somebody breaks something with a modernization and doesn’t bother to repair it) which result in some of the longest term bugs in MAME / MESS. Cases where you break somebody else’s driver, without actually making any real improvements to the driver, tend to result in high levels of resent and an expectation that the person who broke it will actually fix it again. Sometimes it’s the fault of the underlying driver that are exposed, sometimes it’s the bugs in the newer implementations, sometimes it’s errors made during the modernizations, but either way it is a little rude to break things then not repair them.
Would you like to name some specific sets that are “in a worse state than 0.152” so that someone can try to fix them before the next release, or would you rather just spread FUD?
They are known about, would you like to stop with the condescending and quite frankly insulting comments directed at me?
I know you seem to want to join the “Haze doesn’t know what he’s talking about crowd” but it’s wearing thin, very thin.
I speak with Tafoid etc. on a daily basis, so I know our current state, I have various list mails forwarded, so I know the dev team are aware of the current state of certain things.
To pick one example, there are still issues with the 68681 modernizations, certain things that don’t work with the new device but did with the old one. There is a discussion on the list about that and regardless of where the problem is it should ideally be fixed prior to any release, if the new device is failing in some drivers that is an issue.
Hi Haze,
I sincerely hope that we keep Decapsulating and reading the protection MCU’s and other chips that are otherwise unemulatable.
What is the current status of the remaining unread chips that were sent to the Dr for Decapping. Are they safe? Have they been returned?
What would it take to get the Decapping Project going again?
Regards,
Tingoes
I don’t know the current state of the chips that were sent, AFAIK that’s between Guru and Dr. Decap, although I think it is of concern to some people who donated rare ones.
Getting the project going again would require somebody with the skills, knowledge and access to equipment required to do it, and for them to be willing to do it at a reasonable price.
There are people who can maybe handle the easier cases (which is how we’ve seen some Microvision stuff done recently* etc.) but the more complex ones, non-mask chips etc. takes a rare set of skills… there is nobody.
* very impressive it has been too
Microvision squeeeeeee!
uhhh, I mean cool. Mine stopped working long ago. That plastic they used for the overlays was way too fragile. :(
Do you know if anyone is working on those one off handheld platform games like Bank shot and Tron for integration into MESS? The amount of handhelds out there would probably be about on the size of early MAME efforts. Unfortunatly they all pretty much had custom one off LCDs/LEDs. I know there are a few simulations out there. But nothing on the scope of MESS/MAME. After the tease of merlin in the 2012 round up. :)
Hopefully we can get the Dr back on side and some donations and commitment from other MAME and MESS aficionados toward getting the Decapping project going again sooner rather than later.
It’s very important to the completeness of both projects that we do.
sometimes, it would help if the original author of the driver could collaborate in the fix by explaining what the code was originally attempting.
in some cases, functions are not very self-explanatory and this might make difficult to fix regressions
sometimes the original driver author doesn’t know because he hooked up the old components, connected up the interrupts from them, looked at what was connected to each of the ports, hooked those up and everything ‘just worked’, as you’d expect from a shared device core.
then everything was converted to use a different core, and it stopped working. I’d guess an interrupt isn’t happening, or is happening at a different time.
I was talking in general: drivers which remain broken for a long time are often those whose original creator has long disappeared leaving people sometimes uncertain about the original functionalities (I was referring for instance to BBC drivers, or Atari 8bit ones)
is the problem with the new 68681 related to interrupts? or are you referring to some other modernization?
AWESOME WORK:
“Depackaging the Nintendo 3DS CPU”
http://gaasedelen.blogspot.co.uk/2014/03/depackaging-nintendo-3ds-cpu.html
This method may help with other chips for MAME.
Anyone can contact with him?
I don’t know if it’s related to interrupts, although the behaviour is like it was without them hooked up. I do know the drivers had a debug build assert before with the old device and something being unsupported(?) but they worked anyway.
On a larger scale I think you’ll find that most driver authors don’t remember all that much about their old drivers, they wrote them, they worked be it because they were correct or by chance. Personally I try to actively keep track of everything I’ve worked on, give the majority of it test runs to ensure it works as well as it did when I added it etc. and generally I have a good memory for details and how things I’ve worked on worked.
In cases like this tho, I really don’t know much about the device in question, I hooked it up, it behaved how I expected it to, I got on with other parts of the emulation, the end. Ideally this type of platform (pretty much all the Fruit Machines for that matter) do actually need somebody with a far better understanding of all the peripherals, both external and integrated into the CPUs because they’re a pretty good stress test for them, a lot of our hook ups could be wrong, and I wouldn’t count on lesser used modes in the devices being correct.
Furthermore a lot of things in MAME were done by people who no longer have time to contribute as well, so you can’t really expect them to help repair damage.
Don’t get me wrong, I’m very much for single *good* implementations of a device, and I’ve argued that very point many times (as well as merged as many things as I could in places) but the responsibility does fall with the person doing the work to convert things / the people who have worked on the new devices to ensure things work as they did before or better, but not worse, or at least not worse in significant driver-breaking ways.
Thankfully we do have Firewave back on board for some cases like uninitialized variables which happen a lot during other types of modernization, as well as picking up some obvious coding errors etc.