I suggested to Kale that after Cool Riders we should take a look at another long-term non-working game, Gunpey.
The reason it hadn’t been emulated was because everybody was rather scared of the AXELL AG-1 blitter chip, boasting some useful features including graphic compression. Beyond that the game code is ugly, and difficult to follow, the interrupt system was less than clear, and previous attempts at writing the driver had resulted in something where the game code appeared to be running super-slow, the blitter copy was meaningless, and it wasn’t sending anything that resembled useful game data to the video device. Basically, if you ran it in MAME over the last couple of years you’ll have seen something like this at best. This is the result of the ‘blitter’ emulation copying some data from the roms to the screen, it’s clearly nonsense.
(Gunpey in MAME as it was 2 days ago)
Tasked with this Kale set about improving the interrupt emulation, and removing the hacks needed to run the game, while doing this he noticed something else, while the game was said to use a blitter there was actually also a spritelist in RAM, and tracing around the code showed that ASCII text from the game rom was being written here as sprites. With this in mind he changed the renderer to draw solid blocks for these and instead we ended up with something like this.
(Gunpey after Kale identified a sprite list, with solid block drawing)
Clearly a menu, the test menu. This required a little more work from him in fixing up some broken inputs and the like, but it soon became possible to navigate the test menu. I decided to help a bit at this point and hook up the same fake ASCII rom we used for Cool Riders up to the emulation, although in this case it wasn’t quite as straightforward because the ’tile numbers’ in RAM were actually co-ordinates, so to render them with the fake ASCII rom we had to convert each set of co-ordinates to a character number. I did a few, Kale filled in the rest and we ended up with this.
(Gunpey with a fake ASCII rom hooked up)
Doing this presented various useful test menus, making it clear that the OKI sound write had been hooked up to the wrong byte (I fixed that) and that the sound banking was wrong / missing entirely (Kale fixed that)
Now, keep in mind that the graphic rom is a 2048×2048 page of ‘textures’ (a very uncommon setup for a 2D game) you might ask why we didn’t just use the co-ordinates directly to index that page and draw the real text. The reason is it’s not really that simple, the co-ordinates were not references into that texture page, I did try. That’s actually where the ‘blitter’ comes in. It’s not so much a blitter to show things on the screen, but a device to copy graphics from the 2048×2408 page of graphic ROM to another 2048×2048 page of RAM, which is what we’d been trying to display in years before, not realizing it’s real purpose. The existing hookup was wrong anyway, putting the data in the wrong places, so I hacked up a quick viewer for that RAM, and improved the copy operations somewhat. This left us with a page of data in RAM where there clearly seemed to be a font at one location, as shown here.
(abusing the MAME tile viewer with 2048 wide tiles to identify where a font gets copied to RAM)
Yes, that’s tiny, but remember that’s a view of an entire 2048 wide texture page in RAM, and I could just about make out some character like symbols over there, you need a keen eye for these things sometimes…
I then attempted to replace the fake ASCII font with the one from this data, leaving us with this…
(Gunpey, first attempt at using the font copied from ROM to RAM)
Clearly not quite right, but at the same time it clearly IS a font as expected. Kale did some checks, and it appeared even my new copy operation was buggy, every texture was being copied at half-width, to the wrong places (I’d initially made the RAM texture page 1024×2048 based on the values used by the blitter) This meant that while we were indexing roughly the right place for the real font it couldn’t be right until that was fixed, so after a bit of head scratching I fixed it, so we ended up with some more readable text using the real fonts.
(Gunpey with the original font hooked up properly)
Booting the game at this point resulted in something actually resembling a game, but with many corrupt graphics. This was because our indexing was still incorrect for anything not on the first few lines of the RAM page. This did allow for some more fixes tho, the Demo Play text for example showed that the hookup for X/Y size sprite size Kale had done was swapped around (unsurprising because he only had 8×8 sprites to work with before) That made a good reference point for a fix.
(Gunpey, preliminary ingame shot, showing Demo Play text used as a reference for another bug fix)
After a bit of work I was able to improve this, and get the game booting with somewhat correct graphics.
(Gunpey with more of the source offsets fixed)
Meanwhile Kale was fixing the palettes. The palettes are stored in the ROM with the graphics, and copied to the RAM page in the same way as everything else. In addition to this Kale added support for transparent pen, and decoding of the 8bpp graphics. (The chip supports 4bpp, 6bpp, 8bpp and RGB555, but the game only seems to use 4bpp and 8bpp, although the test mode has tests for the others) He also fixed sprite X/Y positioning and a few other problems.
(Gunpey part way through Kale fixing some graphical issues)
At this point the game booted and you could easily identify what was going on, but was still it had significant, and hung if left in attract mode. Also inputs weren’t working on the I/O test screen nor properly on the character select screen. Kale figured out this was an interrupt problem, fixed that, and also identified the end of sprite list marker, and fixed that, getting rid of most bad graphics. We also found things to work better without an ‘invert bank select’ hack that had been added earlier for the spritelist, so that was removed.
I then spent an hour or two debugging some of the remaining graphic problems, figuring out, getting rid of some issues where graphics were incorrectly offset (because we weren’t using enough lower bits to index the RAM bitmap when drawing sprites) and identifying which bits were source sizes, and which ones were zoomed sizes.
That leaves us where we are now. The majority of remaining glitches can be attributed to a handful of things. The major one is the graphic compression, it’s used for most backgrounds and a number of other elements, there doesn’t seem to be an obvious bit to enable decompression when the sprites are drawn, so it might happen during the blits. Beyond that there are still transparency / alpha issues, and the zooming hasn’t been hooked up. Anyway, this is what it looks like *now*
(Gunpey as things stand now, still missing the graphic decompression, but otherwise looking good)
Not bad for a days work on a driver that has been sitting idle in the source for years where every previous attempt at making progress quickly hit a brick wall. I think it’s fair to say that Kale did most of the important work with this one, especially in getting past that initial brick wall and identifying some vital points about the hardware, but like Cool Riders team work was involved in getting us this far. The compression looks interesting, the compressed data for the BanPresto logo case shows that it might not be especially efficient, the white fill still needs a significant number of bytes to represent it, but we’ll see.
The actual game is most similar to the PSX version that became playable in UME/MESS recently, I don’t know if the background data there will be helpful / needed to decompress this, but still it’s something you might find interesting. Obviously the hardware here is VERY different, and strange for a (c)2000 release, an original V30 CPU being used at that point definitely wasn’t common.
Nice work. It is really insightful to look into the process of getting a ROM decoded. I really wish there was more information available like this. It would also be very interesting if we could see the breakdown of a MAME Driver, Mr Do! for example, simplified for lay men, so we could all see and understand the work that has gone into making games work in MAME.
As an aside, and purely out of interest. Is there any legacy code left in MAME now that was in 0.01?
well there isn’t much to Mr. Do, it’s 2 tile layers and some sprites driven by a single CPU, probably most interesting to note that there are a couple of things the hardware can do that MAME doesn’t emulate because Mr. Do doesn’t use the features. (switching the priority around)
I doubt there is any untouched 0.01 code in there, even the most basic parts of MAME have undergone significant refactoring and modernizations since then, even if it’s just as part of ‘all file touching’ automated operations.
You do still open up old files and see some outdated comments / code that has no real purpose anymore tho.
dec8.c still contains
/* Blank out unused garbage in colour prom to avoid colour overflow */
memset(RAM + 0x20, 0, 0xe0);
MAME hasn’t required any form of colour marking for years, back in the day you had to mark each colour used by a sprite so that MAME could build a table and decide the best 256 colours to present the screen with (dropping ones that didn’t fit etc.) These days you can’t even *have* a 256 colour palettized screen.
nice work guys!
About the larger pictures being compressed: it’s possibly JPEG style?
I was thinking the same, with it being mostly backgrounds, but it doesn’t have JPEG header bytes at least, so it’s unlikely JPEG.
The Banpresto logo has some very obvious patterns for the white data being compressed, looks RLE-like, but there could be multiple modes.
Also, I can’t see the bit to tell it to draw compressed, and it clearly doesn’t decompress when copying because there isn’t enough room.
although there are at least unused params when blitting, so maybe they do, and the code is just inefficient, and copies over things again as needed even if they have plenty of space elsewhere
about the v30: I don’t think it’s so strange. The original Gunpey game was developed for Wonderswan, which uses a v30 CPU, so using the same CPU for the arcade makes sense… this way they could re-use most of the code for the game logic and just update/focus on the video hardware.
0.148u2 coming out soon?
I think it won’t be released until the migration of the mamedev.org website is completed
nice work… you are teh best ¡¡
hope someday , you can dump the rest of PGM games or even more enjoyable the PGM2 games :)
I will be the first to put my hand up and say that I wouldn’t know where to start in building/documenting drivers for anything, so kudos to the team again. Reading these blogs – and I am afraid to say it that I only read Haze’s one, I really should look elsewhere!
As Marc Colman said, I too would love to see a breakdown of a MAME driver and how it all corisponds to a ROM for a lay person.
A ‘real world’ example would be is to forget Rasperberry Pi, if you want new blood in coding (in any form) this should be the way to go for schools as there are public domain ROMS with the coding all in place as well as documentaion all the way through it. The hard work is already done for the most part. It wouldn’t take much to make this into some part of of a syllabus – and doesn’t detract too much from MAME’s philosphy
This way, not only could you teach kids how to code (something that isn’t really being taught in British schools), you would also bring new blood into the MESS/MAME team – the nice side effect is that the kids would play the games after. A win-win situation if there ever was one.
The Pi is hideously underpowered for any serious MAME use.. it’s a cheap toy, and a lot of hype, nothing more, nothing less unfortunately.
Back in the days the open but still easy to use / cheap machines you had at home and were cutting your teeth on were the same level as commercial developers were releasing games on, and while it’s good to have learning systems available it has severe limits, even in educational scenarios IMHO.
I wish there were more consumer focused laws with regards openness of actual console hardware and the like, but there’s too much money in it for that to happen and we’re going more and more in the opposite direction. I fully expect even PC platforms to be locked down for the majority 10-15 years from now, if we assume today’s ARM tablet devices are tomorrow’s PCs (Windows 8 RT / Mobile etc.) we’re actually already there with many of them due to the (what should IMHO be illegal) licensing terms and conditions of the OS when it comes to how locked down the hardware it is allowed to be installed / shipped on is.
I’ve gotta agree on the PI…. not only is it underpowered, it’s over-priced. I don’t have a problem with people playing with it, but when they suggest it’s a legitimate solution to… well … nearly anything…. it bothers me.
When you start a project with a PI as the base, unless it’s something very specific that takes advantage of it’s unique hardware, you are putting a handicap on yourself. It’s not a mini computer…it’s a very slow tablet, without the screen.
Admittedly my emulation coding chops are pretty weak. I barely manage to fix some I/O issues every now and again, but I do know programming and the PI wouldn’t run desktop apps that I coded 10 years ago without serious optimizations.
The problem with the PI is the fact that it was released last year. If it had been released 5+ years ago, like it was supposed to, for the price they are asking now, it would have been one heck of a deal. Once tablets went mainstream though, it was immediately obsolete.
I love to see new hardware projects come out, especially for the benefit of education, but my enthusiasm doesn’t blind me to that fact that a product is a dud.
This is why i think something like mame, which is platform independant would be a soultion to coding in schools as it already has been done and can be used to teach kids programming skills as well as showing the history of games, name me any kid that wouln’t like to learn & play games in school and get away with it!
I agree that Pi seems to be something that had it’s chance and is likely to fail. Regarding ‘crippled’ hardware, I am slowly putting my HTPC out of operation thanks to M$ – but that is a totally different argument!
I don’t think a school with any sense is going to touch MAME with a 10 foot pole.
You’ve got multiple legal issues. First off even though there are freeware roms out there, kids aren’t stupid. Within minutes they’d be downloading commercial roms while the teacher isn’t looking. Roms that are on the school’s servers and they are liable for, not to mention the fact that some rom sites are riddled with viruses and malware and ect.
Then you’ve got the drivers themselves. Most governments don’t keep up with technology and thus the laws are a little strange. The DMCA says that circumventing any kind of protection (even if it’s stupidly bad protection) to play or extract data is illegal. It shouldn’t be, but it is. MAME decrypts a lot of the roms it “plays.” In a round-about way that could be considered a violation of the DMCA. It also documents various hardware, hardware that while defunct, might still hold a patented design.
Ok, obviously I didn’t think out those ‘tiny issues’ LOL
But as a concept though, without the legalities etc, it would be a good platform if someone came up with the framework.
A software framework for coding that doesn’t need a lot of power to operate (whatever that framework is – MAME is an example only because I am interested in it at all levels) is going to have more staying power than any PI (whatever the flavour!) in any school. (lets face it notepad can code anything from MAME to a webpage)
All this is purely hypothetical though!
Although, a real world example would be the fact that I now patch/complie MAME source code – I wouldn’t have dreamed in compiling software before.
I understand that patents/ideas have to be protected, but now they seem to be out of control. I think 25 years after something has been produced should be enough – regardless whether the person is living or dead. (25 years on it’s first outing in ANY format – otherwise Disney is just going to re-release Lion King every 25 years!!)
That’s why I moved on to Linux years ago. No political bullshit involved.
@T-Jay patents are currently at 20 years. You are confusing it with copyright which has a much longer term.
Also jumping into MAME for a first sort of programing project would probably really discourage people from it. It is huge. That can be very intimidating for someone just starting out. I usually point people at python. Its easy to pick up and has dozens of very good tutorials out there and you can see things going on very quickly. 25 years ago I would have pointed people at basic or pascal. Sometimes you need to walk before you run (and MAME is really a sprint :) ). Just having the concepts of if/while/for/variable management etc is usually a big hurdle for those starting out. Never mind what a bit-blt memory area is and how it ties into interrupts and what an interleaved memory rom is with mirroring.
Now dont get me wrong. It is worth learning. But for someone just starting it may be a better just getting the basics first.
There have been a few tries over the years to describe the MAME framework. However, it would take some serious discipline to keep it up to date. Then it would also take someone who is into tech doc work to do it (most devs find this sort of work dull and boring). Aaron had a decent start of one for awhile but it was wildly out of date by the time he took it down.
Though a simple tutorial probably would not hurt. Something like ‘hey lets hook up pac man’ and walk people thru the steps. Then people can compare their results to the real one inside of the code.
I agree. It’s a shame really… there aren’t many “starter” languages anymore.
Visual Studio 6 was the last version where visual basic (my recommended starter language) was actually simple to write for. Don’t get me wrong, vb.net is still an easy language, but all the headers and nonsense that they’ve tacked on to it kind of defeat the point of starting with a “headerless” language.
Game programming is certainly a good activity to get people interested in programming, and you can make a game in virtually any language.
Coding an emulator for a beginners project is kind of like teaching a person electronics by giving them a vcr and telling them to figure out how it works and build a copy.
Long story short, it’s at least 75% reverse engineering. That’s something that requires high level logic and reasoning skills in regards to programming. Something you don’t have starting out.
As “me” pointed out, your initial lessons involve understanding how operators and comparators work, data storage, ect. All programming boils down to is instructing the computer to to a series of tests via questions that you input. Understanding which questions to ask is the key to being a good programmer.
To ‘me’,
Now if there was a simple tutorial for pacman/mame I would be there like a shot, especially as there is a compare/contrast aspect to it. I also appricaite the hurdles for anyone going 0-150mph into coding/reverse engineering mame, I was just wondering how we could get the kids of today to start programming rather than give them crippled hardware like the Pi, also at a cheaper cost per unit, and make it fun.
I can see where I have got confused…oopsy!! So thanks for point those out., rather than letting me continue making those mistakes again elsewhere. For example, I didn’t know that patents have differnet terms than copyright, so at least that is something I learnt too!
I’m on here posting comments here because of the love MAME, and am reading about whats happening next because I’m finding it interesting on so many levels not to mention how hard the devs (all of you guys) work to get these rare boards working, and what obstacles you face too.
So going back to Colman’s original idea, of a breakdown of a MAME driver and how it communicates to a ROM – this is already in the sourcecode isn’t it, i.e. uncompiled
On the educational aspect it’s something I’ve thought about MAME for a while, not necessarily in a ‘running games’ capacity, but if you want to teach the basics of assembler while referencing REAL cpus, not theoretical ones, then it would be quite a nice tool, especially if further improvements were made to the debugger, and assemblers were added in addition to the disassemblers we have now.
It is important to look at the project beyond something simply used to ‘play games’ because the actual value of the codebase is so much greater, that’s one of the reasons I think keeping our primary project as ‘an arcade emulator’ is a bit silly, the arcade emulator is really just a small part of something much bigger.
I agree but remember the old adage “jack of all trades, master of none”
Without the very strict “arcade games only” rule that lasted for so long I don’t think mame would have lasted as long as it has. It gave the project limits and direction, which allowed drivers and such to be perfected instead of every electronics device on the planet being haphazardly added to the code base.
I think you and Kale’s recent efforts are proof of that. In a matter of a week or so you got two “unfixable” games working. The primary reason being the flow of new drivers has dried up, so it’s time to work on the ones that aren’t quite right yet.
MESS certainly makes a lot of sense, afterall most console hardware is very similar to arcade hardware… and the two projects help each other along. Gambling games and ect… make sense as well. Again, virtually the same hardware.
Where mame lost me though is when full x86 computers started being added. Now you are no longer talking about a fixed hardware base. Things start getting complicated to use, they start getting sloppy in their implementation, in regards to user interface.
You mentioned it yourself with your 2012 wrap up.. it’s quite complex, and in some cases impossible to “just run a piece of software” in Mess. In many cases I’m more interested in the hardware than the games/software itself but at the same time building an emulator that doesn’t run anything (easily) seems like a pointless exercise.
I don’t think the value of the code base is in question btw. Everybody that knows anything about it agrees that it is a huge asset.
Like I said though, as long as “romz” are tied into the code it can never be used as a formal educational tool. There are too many legal issues.
So I disagree. The “an arcade emulator” bit is what made mame the unstoppable juggernaut it is today. Mess, the pinball stuff, the gambling stuff, the em hybrids. They are all important to preserve, I’m glad they are in mame and in the days when they weren’t included I complained about it, but keep in mind they are an extension of the arcade community and it’s drive to get these things running, not the other way around.
Hmm, well I started looking at Cool Riders, because the PGM board we had didn’t want to run the Puzzli 2 trojan I was trying and that needed to be shipped off to somebody else.
I’d actually looked at that (and Gunpey) many times before, without success, it’s not like it had been ignored, it’s just this time when things cycled into view things started making a lot more sense, and a great deal of that can be put down to experience.
Kale even admits that his experience emulating x86 based platforms in MESS helped *greatly* with tracing and understanding the Gunpey code (experience gained in emulating obscure Japanese systems like the PC88, PC98 etc.) It’s entirely possible that being able to use the PSX version as a reference will improve it further.
I looked at Gunpey again because I’d been running the PSX version using the MESS driver, and was thinking ‘a game like this shouldn’t be tormenting us as much as it does’ while still being curious as to why the Arcade used a V30 type processor (like the Wonderswan original version) but had graphics very very similar to the PSX one, so from my point of view revisiting this was very much MESS inspired.
So to that degree I can’t really agree with the jack of all trades comments. The experience and exposure to a whole variety of things is what is helping solve these last couple of cases and that’s the primary reason a LOT of progress happens in the projects, encountering something new, understanding it, and realizing it might apply to something else, or drawing from that knowledge next time it’s visited.
MAME already emulates far, far more platforms than MESS, and *none* of them to the quality needed for a MESS driver. The MESS element actually only helps improve things, and in terms of number of drivers is a drop in the ocean because one driver tends to have many games, rather than with MAME where you’ve got many things on entirely custom built platforms with nothing reusable and no further tests of the code / emulation (like Cool Riders..)
I’d say the opposite, and that ignoring consoles etc. has actually shackled MAME, caused developers to be lazy, adopt lower quality standards because they don’t need to run at much, and as a result many edge-case games where arcade hardware is shared with console hardware fail too. Another such example comes in the shape of the ST-V game which will be playable in u2, the experience from MESS and test cases exposed by MESS code allowed fixes to be made and the problem with the st-v emulation understood, without that aspect of the code being important it would never have happened. A *lot* of the current problems with MAME / MESS are simply because decisions made early on failed to consider what are obvious needs for the majority of consoles / computers just because they might only matter to a tiny handful of arcade games where they can be hacked around with disgusting hacks.
Maybe as a PR stunt ‘arcade only’ worked, because it hides many of the limitations, makes MAME look better than it is etc. and in that sense maybe it did help it grow, with people repeating the myth that it’s the most accurate emulator etc. etc. when in terms of real accuracy is isn’t a patch on what is needed to even emulate even something like the ZX Spectrum to a high level of quality, nobody cared because such details were kludged around. I find it sad that we set the standards so low and these days we are paying for that and it could have been avoided by giving such things a higher priority earlier in the life of the project before certain things were so ingrained in it.
As a statement of ‘Ok, now we need to be serious’ The MESS stuff sets the bar much higher, and provides actual incentive to improve things, which is lacking with regular MAME. I think it’s time to move beyond the lies, and the facade we put up and the tricks we play on people making them think they’re running some ultra accurate emulator when the very same code actually falls apart when presented with real challenges to test its accuracy in MESS. Working in MESS makes you realise just how important things like timings are, how much of a difference in terms of what the game does there really is between 59.7hz refresh and 60hz refresh, how triggering a vblank interrupt one line early can actually be catastrophic, it makes you realise that some of the problems in your MAME drivers might actually have just been because you were too lazy / not wise enough to care for such details, and that’s a vital understanding to have and a level of detail still probably not accurate for 99% of drivers in MAME.
I know as you’re primarily an arcade fan you’re not going to understand that, nor want to hear it, but it’s the way things are and why MESS is the future of MAME both due to the decline of arcades in general and on a technical basis.
Ok, these are only words, but consider this, if you take away the work Kale and myself have been doing so far there’s practically nothing else worth mentioning in MAME for the u2 release so far, and for the u1 release before it you can add Robbie to the mix with some of the gambling games (but you seem to want to write off / exclude those from the equation too) then the situation really isn’t that different, so the words you’re reading above are coming from one of the few people actively still involved in improving MAME and fixing up difficult drivers. Both myself and Kale have been actively involved in both MAME and MESS stuff, and that is vital to all of this for the reasons of experience mentioned above. The devs who have never shown that interest in gaining extra experience and exposure tend to be the ones who have dropped off, and haven’t continued to improve their skills in order to solve such issues and tackle these remaining cases. Only Luca who has been an exceptional MAME and only MAME contributor really bucks that trend.
Tools to do layouts, all all the techs hooked up and working. That’s all I want for u2. :)
yeah, the fruit machine stuff is still in my cycle of things to check. The problem with those at the moment is that I tend to work better when there is somebody else to bounce ideas off and work with in the areas I’m not so good at and right now there isn’t a great deal of interest within the team in helping out with such things on them. As you’ve probably noticed from the last couple of things here they’ve all come about through teaming up with other members simply because it allows people to concentrate on their strengths.
Sometimes it just comes down to what mood people are in ;-)
I am assuming, (probably making an a bad one though!) that for a fruit machine to work in MAME it needs artwork such as reels, ‘lights’ and the display of the machine itself.
As I have mentioned previously, I have zero experience in coding, but can photoshop etc. This is something that I could easily put some time to if that is something that is wanted by the MAME team.
I am also assuming (possibly the second bad one) that there are restrictions on the artwork in regard to transparant layers amongst others that I am quite possibly unaware of, but on this side of the emulator I am most interested in especially as I used to wate money on these machines, before going off to waste more on the arcades on the Palace Pier in Brighton!
the artwork system is quite limiting at the moment, yes. for good looking layouts you’ll need external stuff, although there is already a vast collection of that out there for the existing emulators, much of which could probably be converted once things are more finalized, and with a bit of manual tweaking.
you can do some alright looking stuff, but it’s a LOT of legwork right now, and not particularly efficient, it’s also possible to make decent enough representations of the gameplay elements enough to make the games ‘playable’ using internal stuff (and appropriate labels on lights etc.) alone.
I am probably gonna reget saying this, but the legwork wouldn’t put me off at all, as things like reels can be reused, I was thinking that the ‘Hold’ ‘Nudges’ etc buttons could be done alone in MAME, and the cabinet display would be down by a layout. I am also assuming any furit with a LED display can be done through MAME alone, it wouuld ‘just’ mean reconverting what is available now into MAME.
This is something I would be very interested working on once everything else is finalised.
Gunpeys looks interesting,hope it can fully working…
If you like so much this type of games, you should love the Namco System 10 and you should enjoy improving it!!! :-)
Thanks for the FM update, sorry for hi-jacking the thread. Last I heard James Wallace was working on some layout tools but that was months ago.
JW seems to have vanished, haven’t heard from him in a few months, that’s not helping in the ‘nobody to work with’ grand scheme of things ;-)
Anyway, System 10, yes, I look forward to it being emulated although it has some pretty nasty encryption. There were however several checkins related to it made today, so maybe cracks are starting to appear. At the end of the day it’s just Playstation hardware, and the PSX version of Mr Driller G runs just fine, so I imagine once the encryption is out of the way most of it will ‘just work’.
Hi David
By speaking of puzzle game, I remerber in the past (2008 or 2009 may be) Luca has posted some screenshot of puzlet running on the Metro hardware but with a H8 CPU.
Since then, some work has been done by the Mame dev on the H8 CPU.
Did you have a look at this game recently ?
Update :
It was in 2008, see here : http://www.lucaelia.com/mame.php/2008/Puzzlet
and for reference, I’ve found some videos on YT :
http://www.youtube.com/watch?v=ccmPc2nPJOY
Puzzlet, an interesting one.
It actually seems to do less now that it did before, and before it seemed mostly like an H8 interrupt issue causing the game to run at a fraction of the real speed.
It’s also one where we have a decap of the sound MCU.
Ah, the old “nobody to work with” problem. That happens a lot, and generally happens much more with gambling games, as soon as they find out that the game you’re testing is not a fun ‘arcade’ style game. The Konami “GX” ones probably should have been in-game long ago (even if they did nothing and had a garbled ‘default’ palette; not sure about the PPC versions, especially since enchlamp is the only complete dump on that hardware), but no-one wanted to help with getting them beyond the POST (as with aristmk5; with a few ‘nasty hacks’ two of the games managed to show graphics in Arculator before hanging – unable to reproduce in MAME despite using the exact same code, probably due to incomplete A3010 emulation though).
I Just wondering to know when Tekken 4 & 5, Soul Calibur 2 & 3 be playable on MAME Emulator. PLease advice :)
Thank you.
I wouldn’t hold your breath.
My best bet is never, at least not above 2fps, so you wouldn’t consider them playable.