I haven’t got much to report here, post 147 continued the massive ‘change all files again’ refactoring efforts in MAME which kinda derailed progress for a few days, although things appear to have settled down again now. I don’t think I would have made much progress anyway, I haven’t really been in a MAME mood, so in reality the timing of the changes probably wasn’t that bad, even if the first part of them (which crept into 147) are largely responsible for the ‘Mortal Kombat is broken!! bug which I must have seen posted on at least 30 forums (surprising really because regressions in other drivers can go unreported for the best part of a year but I guess the MK games are unfathomably popular) Breakage aside, I still need to write about some of the other cool bits in 147 however, again the lack of a MAME mood hasn’t really helped there.
Probably the most interesting piece of progress lately is Kale’s work on the Seibu COP protection. It’s no secret that a fair number of the remaining unemulated 90s games are serious tough cookies when it comes to figure them out, for many systems it’s like the final boss run with every battle suffering from SNK Boss Syndrome.
I’ve mentioned the COP here before, it handles all sorts of game operations, movement, collisions, DMA, BCD maths, indirect ways to access memory and is even semi-programmable through a series of short ‘Macro’ commands which get uploaded to a table on startup etc. It also manages to blur the lines well between what are operations actually performed by the COP and what are external operations. The programmable Macros also only seem to be half the story for some of the functions they provide, the collision ones for example appear to be incredibly simple, too simple, with barely enough operations to grab the values from the doubly indirected table they use and perform calculations on them, so it’s likely the actual macros only perform half the work for several operations allowing for game specific customization of how more complex commands hardcoded in the silicon are fed their data etc.
Kale has been doing most of the work on this, as mentioned, I’ve been trying to understand bits of it, the collisions, hitbox checking etc. which is less straightforward than it should be for the more complex cases of Legionnaire and Zero Team. I think I’ve figured out how it determines the basic size of the hitboxes, we have X co-ordinates, Y co-ordinates, origin and size, which works much better than what we have now in the “SD Gundam Sangokushi Rainbow Tairiku Senki” case (you no longer fall through the elevators etc.) but actually ends up worse for Legionnaire, which has 2 extra 8-bit parameters and additional flags checked based on those. Logically you’d expect them to be Z, but you have no pointer to any RAM containing a base virtual ‘Z’ co-ordinate (assuming it isn’t just after the X or Y one, I should check) Also in terms of the resulting flags, for X and Y you get the distance between the parts returned in registers, you get no such thing for a possible Z value which would make Z checks meaningless because you’d only have the hardcoded ‘Z’ values from the doubly indirected ROM table.
Further confusing things is that Legionnaire, with the ‘correct’ basic hitbox sizes only checks collisions to your right, if you’re facing left, it sends the same hitbox as if you were attacking right, and there doesn’t seem to be a parameter to flip it, so you still end up attacking enemies to your right instead of left. This makes me think the extra parameters might just exist to extend the hitbox, or another command is failing and the software is requesting the wrong hitbox from ROM because some of the game code still thinks you’re facing right (there is other odd logic like having to double the X speed value another command returns if you’re moving left which might suggest the same, the half speed might be a backwards walk speed for enemies)
To make things even more annoying the ROM tables are inconsistent. Every game calls the same set of commands, which fill in the same values. Legionnaire’s second table is 4 words (xxxx yyyy ???? 0000) with the first table containing pointers to every 4 words. Zero Team has data in the format (xxxx yyyy ???? 0000 0000 0000) and pointers in the first table to every 3 words, meaning every 2nd pointer is basically useless because it points to blank data. Then you have the games which don’t have any ‘depth / z / ????’ value which just have the tables in (xxxx yyyy xxxx yyyy xxxx yyyy etc.) formats and point to every 2 words. I assume this means that the calculations are independent of each others because if the commands get processed the same then they’re going to end up with invalid ‘x’ data from the next entry for the ‘depth / z / ????’ parameter in the cases which pack the table without the ???? values. Kale’s testing would appear to back this up because he was getting an unpredictable value he couldn’t understand at all in one of the result registers.
So you can see the challenge, and that’s only dealing with a tiny, tiny piece of the puzzle. For these games to work perfectly every single piece needs to be understood properly, implemented properly, and full verified / tested against real hardware results. It’s possible the chip has alternate ways of doing things too, if for example the ‘Macros’ executed for the collision simple substitute some kind of regular memory access it’s entirely possible there are manual ways of doing the same thing (and I actually wonder if this isn’t what Raiden 2 does, it accesses registers nothing else does for some bullet / sprite processing, although they could be specific to the sprite chip on that game because it uploads the encryption params to the same area, which is what I mean about the lines between COP functionality and other hardware being blurred)
I could speculate endlessly on this because right now there are so many unknowns, so many little surprises, odd choices etc. that you’re left wondering what’s around the next corner and really questioning how everything fits into place.
What Kale is doing is cool, but I think everybody needs to keep their expectations realistic, there is simply so much game logic tied to the device in all these games that getting to a point where it can be considered trusted is going to be a long slog and between now and then I fully expect things to both improve and regress multiple times as new findings are made and previous ones invalidated.
In some sense we’re lucky, we’ve got a large number of games making different use of the protection device, but it means coming up with a generic implementation to keep everything happy is important, as opposed to coming up with per game hacks just to provide the logic the game wants, which is what the Seibu Cup Soccer bootleg appears to do, albeit still mostly in hardware with additional hardcoded tables, making it no easier to emulate than the original! The good thing about having a large number of games is it gives us a variety of test cases, and a good slap if we’re doing things wrong, or not fully implementing something, as the collision stuff proves.
As stated before, to the best of our knowledge the COP protection isn’t provided by an MCU, but fixed function logic programmed inside one of the customs, ie it’s not something you could decap with really meaningful “well let’s just emulate the CPU then” results, so an accurate simulation is essential.
If none of this makes any sense to you, that’s fine, an awful lot of it still doesn’t make sense to anybody else who has looked at this thing either, unlike a number of other systems which are relatively simply and just suffer from a lack of interest this one has slain every other developer who dared come close.
I know you mean well, and giving the public a bit of tech/inside info is great. =)
But I also think that part of this post can be interpreted as stealing some of Kale’s thunder. The recent developments, IMO *all* credit to COP Monster bashing should go to him and Smitty. If you think you found out something new (about hitbox/whatever), tell him personally, not the whole world. :D
a good read as always Haze gives me an idea
on how hard and time consuming mame dev work is
fully appriciate all the work you guys put into this
seems a hard nut to crack seibu cop protection
maybe one day
hap>
I’m pointing to Kale’s blog in the 2nd paragraph, the one where I start talking about the COP, I don’t see the issue.
I’ll report on whatever I want here, it’s interesting work, I’ve been looking at a few things, and I think communicating some of that process it important. Kale couldn’t make sense of the hitbox stuff, so asked me to look, based on values in the tables I believe I’ve made more sense to it than we had before, Kale has my code.
Again, I’m sick of the political BS, is it now coming down to ‘you can’t comment on this even if you worked on it’ ? Many of the attitudes coming from mamedev lately seem very condescending, this included, I’ve only been writing about things I’ve looked at in MAME for over 10 years, I think I know what I’m doing and stealing credit has never been my game because for the most part I don’t even care about credit.
I also see the ability for MAME to run cdi / cd32 stuff has been removed by adding extra code specifically to prevent it too, despite the arcade systems containing the home units and booting the home software if you put it in there, with all this done under the guise of ‘reduce confusion’. This is the complete opposite of what eta was telling me only 6 hours ago, where he said the correct setup for the Sega Shooting Master would be a list of the titles which shipped by default, and the SMS library listed as compatible (because in the same way, you could put any cart in it) MAME, writing more code, to do less? People can still use UME or MESS of course, so I’m not too bothered, but it’s nothing but more petty politics and artificial limiting of functionality you otherwise get for free.
Of course you did work on it, and I understand you’re sick of it when someone tells you what not to do. Let me clarify, the ratio of the amount of work you and Kale/Smit did is let’s say 1:99 here. What I’m saying above is that readers may interpret it differently in this blog with most of it being about your contribution. Or even worse, the developer losing motivation over this.
hey you edited your reply :P confuser
and the relevant updates reflect that, Kale now has 3 updates about cop, with multiple points per post, showing what he’s testing, screenshots of how things change etc.
I’ve done a post addressing one thing I’ve looked at in order to give people an insight into the scope of it, and show how much work it is to even understand a single part of the protection, 1:99 of it if you like. This point is even stressed throughout the article.
I’d like to think developers wouldn’t lose motivation just because their work is being talked about, Kale is a professional Mame developer, not a child, or at least I’m assuming that. One of my goals of this blog is to write about cool happenings, promote them, give further insight into them and make sure people know cool stuff is happening with MAME, and possibly even peak their interest levels to a point where they feel like having a nosey around in the code themselves; there simply isn’t enough of this going on lately, hence people saying MAME hasn’t done anything worthwhile in years (usually dating back to when there was an official WIP hyping things up with pictures, JoseQs emuviews giving sneak previews etc.) I’m in a good position to know and understand what’s going on, so why not?
and yes, I’ll add to my posts as I write them, submit small and frequent is not only my philosophy with code, but also blog posts and forum posts ;-) (although it would appear this is the reason for my initial ‘reposting deleted posts’ MW ban, simply because I was doing live editing of a post I’d written which had also been edited by admin without my knowledge…)
Is it possible that they are using some sneaky way of storing the “base Z” and the “Z” value in a single variable like this sort of thing…
http://en.wikipedia.org/wiki/XOR_linked_list
Haze, I love your updates, and at no point did i think your was bagging any credit, just pointing out what thought off kale`s/smit excellent work.
Keep your chin up, anyway, top news about Angler Dangler :) next stop data east Mole Hunter ah…….
:) onwards with a smile.
Well if the only ‘Z’ values you have are hardcoded in the ROM tables it’s not going to matter how they store they because collision results against 2 objects will always be the same, which isn’t very useful.
I doubt it’s anything like you point out, if there is a base Z value I’m guessing it will be stored in RAM after the value either the X or Y pointers point to (given that we only have 2 RAM pointers that’s really the only option if there is a 3rd base co-ordinate)
I’ve briefed Kale with a few tests I’d like to see done for the basic behavior first, to at least verify if my logic w/regards the basic X/Y sizes is correct, logically it makes sense, the majority of the X/Y table entries are in the form 0x10f8, ie size 0x10 (16 pixels) starting at 0xf8 (-8) which would place an even box around a single point co-ordinate. Treating things like this gives much more logical sizes and box positioning for the Gundam game, as mentioned.
The ‘Z’ values are clearly 2 8-bit values of a similar nature, but I don’t think they act in the same way, maybe instead they represent alternate X/Y extents or sizes.
Needless to say tests will reveal more than guesses, which is why the work Kale is doing is vital.
It’s also important that we get these things emulated if there are to be any future ports. While R2 did get a PSX and a PC port there are likely rights issues tied to those specific ports, and the Seibu of today are very different to the Seibu 10-20 years ago so getting hold of a usable codebase for a modern port isn’t easy. It’s becoming very noticeable that games only end up in current licensed retro collections AFTER MAME has documented how the trickier parts of them work and therefore entirely unsurprising that the recently announced Raiden pack for iOS contains everything except Raiden 2 and Raiden DX (and likewise the Irem pack excluded Fire Barrel which wasn’t emulated properly at the time that was released, and still doesn’t even have the world version of it, Air Assault, dumped)
Though most of the information was over my head, it was still an interesting write up. Wish more devs did such write ups.
In other news, it looks like Osso’s work with the “new device” implementations (mentioned in the comments of Coming out of the Shadows, though comments are off on that post now) are being commited by hap. Good work Osso.
Thanks, but actually the megadrive/gg family updates and the eventual removal of the legacy implementation was done by hap, not by me. I did work on the other drivers.
I have to say that I was very pleasantly surprised with how everyone was very patient, kind and helpful to me, since I’m not a programmer and was asking very stupid questions. Haze helped me a lot and Curt, RB and eventually hap were always very quick to answer to my dumb requests. Also thanks to Tafoid for his patience in dealing with my little submissions.
So thanks to everyone! I hope that some people who know how to code will see how pleasant it is to work on MAME.
Also, if someone is interested, there’s still a double implementation of the tms5200 sound chip family. I dabbled with it some weeks ago but got stuck and didn’t want to bother the devs. It would probably be quite easy to do for someone with a bit more of coding experience.
I think there’s also a double implementation of a cpu core, though I’m not sure I remember that correctly.
@Haze: Your blog is one of the most informative MAME dev blogs on the net.
I might not have caught this news if you hadn’t posted about it (and I also read Kale’s entries too).
Stick with it, and ignore the petty comments!
> I have to say that I was very pleasantly surprised with how everyone was very patient, kind and helpful to me
why should they have been not? you were trying to help and learn…
oh, and CPU search at projectMESS will be available as soon as the advanced search options are all working… they still need some tuning…
Osso, I was looking at the drivers using the tms5200 you mentioned last time around. Since I had some trouble getting my head around it (but also didn’t have too much time to spend over it) I wandered to something else and messed that one up instead. But thanks for the pointer anyway ;-).
Haze, thanks for the explanations. I was going to ask Kale in his blog about some gory details on how the COP works (since it is obviously more than a few XORs or an old-fashioned Feistel network). This explains why Kale is doing all these tests and some more things. A big thumbs up to him for giving it a try !
Thanks for another interesting post Haze.
And FWIW, no part of your post could be misinterpreted as stealing credit. Not unless one were to approach it with presuppositions and try really hard. If anything you are illuminating Kale’s work. You are hardly trying to steal even a small piece of his sunshine. And now I’m sure at least one small minded insecure a**hole here will have something to say about my “sucking up” lol, so be it.
@Huggybaby: +1
Haze, that metaphor about comparing COP to SNK Boss Syndrome is a great one!
Next thing you know, Rugal Bernstein will pop up out of the COP, genocide-cutting both Kale and you.
I’m joking, of course. In all seriousness, though, the work you both are doing is great. Keep it up.
I’m not saying hap is an a**hole or anything like that, I just don’t like it when people question genuine motives, or somehow think they know better than me my reasons for doing things.
I’m probably just in a grouchy mood lately which is also why I haven’t felt especially like doing much MAME work, so didn’t really appreciate the ‘stealing Kale’s thunder’ comment when really it was just meant as an informative post, showing the thought processes, and promoting what Kale is doing.
Too many people have come to take emulation for granted, mainly because people working on MAME (and other emulators) have done an excellent job of covering *almost* all bases in some form, and making things look easy, so giving some perspective on the difficulty of tasks like this I feel is important.
Like everything in emulation the last 5% is more work than the entire previous 95% combined, a great amount of it is even completely out of the hands of ordinary developers (systems where every game was an MCU and needs decapping etc.) This can be applied to time, effort, and costs involved.
Haze,
some more questions if you don’t mind.
I wonder for quite some time how a project of this size runs without a bigger testing environment. Granted, there are regression tests but those do not run every night under something like CruiseControl, say, according to my understanding but are run manually by tafoid (which is probably a major pain since it should take a few hours). So bugs can creep in and nobody might notice it in the beginning (see probably MK…). Implementing unit tests for every little piece of code is definitly even more of a pain (also I dunno whether the project is not already in a stage where it doesn’t make a lot of sense any more) but I guess there are the famous 20% of code causing 80% of the headache, especially when code is getting refactored. Covering those a little closer might help a lot.
What makes me also wonder is that code is being released while there are still broken tests. AFAIK the guy who breaks it has to fix it. If he doesn’t or isn’t able to you roll back to the last version when it worked, period (after all that’s what a version control system is for…). These things happen during development, no problem, but releasing code with noticeable bugs scares people off imo.
The reason why I’m asking is that I’ve seen these things handled a little different in various commercial projects. Usually there was good reason why things were done the way they were done and usually it was benefical for everyone involved (saving a lot of hassle, lifetime and gray hair).
Fanclub above: Haze & I are on the same team*. He can be annoying sometimes and so can I, but there’s definitely no bad blood between us.
*(no he’s not literally on the MAME/MESS team, but I tend to ignore that fact:P)
@Fast Eddie: sometimes it’s not so easy to spot when a thing has broken, and if a crash happens after several minutes of gameplay, no automated regression test can help finding it… this means that issues can go unnoticed for years, if the game is not very popular, and then good luck to track down who broke it and why (maybe while attempting to fix something else?)
in conclusion, after every big change of the core and before most releases, at least two people run extensive regression tests and submit the results for devs to fix regressions.
this already leads to *most* issues being fixed before the release, but sometimes things might slip unnoticed for long time…
in other words, we have automated tests and I think they do a good job with it.
but it’s not always a black/white situation, like you seem to suggest with your “if it does not get fixed before a certain time, rollback”… we have had pretty often the case of improved accuracy of some specific device leading to regressions in games because said games were previously abusing the code, or because the other components were inaccurate as well and for some lucky chance the sum of the inaccuracies resulted in the correct behavior.
with your strict rule, one shall revert to the inaccurate code just to keep things playable, unless the person which has improved that component makes all the job for the other components too? not acceptable! it would paralyze progress!
and, differently from what some posts/comments here might lead to think, *NO* massive refactoring happens for the sake of it. it’s just that the end goal is not always immediately visible.
for instance, the changes done in the past 10 days made the project to move towards emulation of two linked cabinets (or two linked gameboys) on a single computers much more than the changes done in the previous 6 months.
this is because the more components switch to using classes and modern devices (which is what Aaron and Micko are doing), the less static variable we have and the closer we are to running two separate instances of MAME in a single computer… in turn, the latter would finally allow to emulated two linked cabinets or consoles…
Well MK broke simply because of too many large scale changes right before a release, Micko should have probably called time on such submissions at least a week before a major release, but they went in barely a day before with no *time* to test it. As a result I think I’ve seen it reported on at least 30 different forums now.. shit happens anyway.
Some regressions just aren’t going to be caught, no matter what your test methodology, that’s why any emulator (or other serious project) needs a userbase, there are too many factors to consider otherwise.
Some breakage does just reek of poor testing, other breakage, as pointed out, is the cost of progress, it’s like science, sometimes you find out something new which disproves everything you thought you knew.
In theory the ‘simple’ mass refactoring shouldn’t change behavior, but unfortunately as we’ve witnessed time and time again, it does, sometimes because drivers were doing things in less standard ways and code had to be temporarily hacked / patched out, other times bad assumptions are made, initialization orders change and drivers are sensitive to them, then you just have unfortunate typos in search + replace operations. I do like to give a cursory glance over the SVN diffs when such changes go in, but quite often it doesn’t really tell you much at all.
The ongoing goal, as eta says is to make MAME / MESS capable of running multiple instances of the emulation, which in theory will make supporting games which used multiple boards etc. a lot cleaner, although I fear most people would just prefer to see research done on finding more optimal ways to emulate a single system, no regular user is going to understand why Yoshi’s Island (SNES) or the 32X titles are so slow in MESS, when the the supposedly ‘most accurate’ emulator (BSNES) is/was significantly faster, and then the ‘NOCASH’ one, supposedly just as accurate absolutely blew that away in terms of performance. (I have a feeling this is another reason some of Mamedev would rather keep the MESS / UME side hidden, people have directly comparable emulators with better accuracy, better compatibility, better usability and vastly better performance)
That is of course a harder problem to solve than simply moving stuff into class based c++ structures over time as it would require more radical rethinking of how things work and probably goes against the ‘make everything as flexible, generic, non-specific, and reusable as possible’ design goals. The cost of things like high frequency timers and high synchronization between CPUs is still crippling for a number of systems but more intelligent algorithms to handle all that would probably require rewriting CPU cores from the ground up with more preemptive behavior to warn the rest of the system that what they’re about to do would be ‘detectable’ rather than after it, when it could be (and usually is) too late.
There is a lot of work to be done all over MAME and MESS, real emulation work, core work etc. most of it IMHO more important than anything this refactoring will win us, but as I’ve said before a lot of people seem to see MAME more as a software project than an emulation project these days; it certainly results in cleaner code, but doesn’t bring about much real progress. I think the problem is that emulation stops being fun for most people once it gets difficult, and in that we go back to my previous point, getting the 95% done is less work than the final 5% at any level, be it CPUs cores, sound cores, drivers etc. Knowing that performance will end up dire as you work towards that goal is a problem too, for all Curt’s good C64 work in MESS I can’t recommend it to anybody because it struggles to hit 100% here and it’s a C64…. The X68k is much in the same boat, it seems to have dropped to around 50-60%, and honestly, it could give a perfect emulation but in most people’s eyes it will be seen as a vastly inferior emulator for that reason alone.
I don’t have a magic solution, much of this is understandable, again I’m just trying to provide some insight into things.
Anyway the original comment was about regressions, yes, they happen, but the overall goal is to fix them by moving forwards, not backwards, if MAME had to wait to fix / revert on every single regression it would never move forward at all, most of the critical ones do usually get ironed out over time, especially in periods where the project is more stable, but some of them are just tough to get right.
@Haze: Since you mention BSNES, what ever happened with Byuu’s cothread library and MAME. It was added last year, but now it seems to be gone from the source as of 0.147. Was it just never used?
cothreads seemed to introduce mass instability, and issues with the debugging tools, nobody quite understood why (bumping the stack sizes helped, but didn’t cure it entirely) turning it off made the problems go away, turning it on made them come back.
furthermore nobody had actually taken advantage of it, and because you couldn’t really expect it to get turned back on in any official build nobody was going to take advantage of it…
so yeah, MAME still can’t handle blocking reads / writes which can stall execution and only return when there is data to read / data been written.
A Dream come true or its not to far away for Raiden 2 playable ?!? Kale & Haze and the rest of the Mame Team please make this happen… best Christmas Gift ever :-)
@Haze
What really interest me why is Seibu Kaihatsu not helping in emulating their old Hardware . I mean the Games are out of Business and not making much money i think . Look at Gaelco i heard they helped with “World Rally” .
It could still take years, I very much doubt it will be fully figured out by Christmas.
I don’t think Seibu can help, as I said above it seems the recent iOS ports lack Raiden 2 as well, even the most recent versions of the arcade (the ‘New’ / ‘2000’ versions of R2/RDX/ZT) were reworked to use different protection. You have to remember that the present form of these companies is very different to how it was 12-20 years ago. It’s entirely possible Seibu *don’t know* how it works anymore. In my experience, when asked to do a modern port of something old you’re told that the emulators are your reference, when something isn’t emulated it may as well not exist.
Gaelco helped with World Rally yes, however many of their games remain unemulated; World Rally was just a one-off thing, they wanted to be able to put it on their website as a historical piece, a gift and so needed it emulating.
Keep in mind that I can’t recall a single instance of a Japanese company helping with emulation either, it’s always been the US or European developers who have provided assistance, the Japanese culture is much more protective.
Agreed.
I heard some hearsay about the developers of Triangle Service apparently being an offshoot of the team at Seibu that made the original release of Raiden in 1990. It’s hearsay, but if you think about it it’s quite likely that this isn’t the only time something like this occurred. Ergo, it’s quite likely those involved in the development of Raiden II are no longer at Seibu/MOSS.
Co-operation is unlikely either. In my own experience there’s still segments of Japan that are very anti-Western. Need help with a Japanese program? You’d be hard-pressed to find friendly developers who are willing to go ‘against the norm’ so to speak to help you out. I’ve said in the past even Cave have shown anti-Western traits at times prior to the implementation of Cave World and the steer towards digital distribution.
The Japanese culture in general has always been very different, even their emulators.
I think maybe if MAME better represented the arcade industry (Japanese versions rightfully as parents for Japanese developed games) rather than presenting the more US / Euro-centric view of things then MAME might be seen in a different light over there, but at the same time I’m doubtful; MAME has stood firm in stating the importance of emulating things like Mahjong games in the face of a great amount of hate from non-Japanese speaking users, so to say Japan is seen as second class in any way is unfair, although maybe Japanese users reading English forums seeing the MAME userbase heavily bashing the Mahjong games they grew up with hasn’t helped matters..
MESS is also emerging as a good platform for emulating a number of Japanese only systems, again showing the dev team care about these, but just like Arcade stuff sourcing the systems and games for proper bios dumps can be tricky (historically Japanese emulator developers tried to avoid bios roms being a requirement, preferring to substitute them for HLE and homebrew fonts etc. because they saw being able to run your original media without needing dumps of anything under copyright from the machines to be a more important goal than low level emulation)
It seems with Japanese devs a fair number only want their dumps to be emulated by other Japanese devs too, quite often with Japump stuff the dumps would be submitted with a driver, the readmes indicating that the actual dumps had been done 3-4 years prior rather than everything being open to teamwork. Luckily there are others who do work more closely as part of a team, this has been very important when it comes to sourcing and dumping the incredibly fragile Deco Cassettes for example, those aren’t going to last much longer.
It’s a tough nut to crack, and it’s not like there aren’t non-cooperative people outside of Japan either, the simple fact that Marble Man is almost certainly never going to be emulated in MAME is a much higher profile case for the majority of users than the struggle to source some rare Japanese hardware / software. You could argue there’s a chain of agreements there, and I understand that can make for a sticky situation if trust gets broken etc. but it’s still a shame because the product in question is of no commercial value at all, it was never even released so the very fact that any such secretive agreements were made in the first place, and that it fell into the hands of somebody willing to make them is what frustrates people I think.
The full story, who knows, I have the roms and driver for at least one *really* interesting prototype game, which I can’t talk about. The initial agreement was that it would be secret while some repairs to the original hardware were done, probably 6 months tops, I was given them to help figure out what was needed. That was 2-3 years ago, with no end in sight; while the ROMs etc. were fine for creating a mostly working driver it seems like entire PCBs were missing from the original setup. There’s also the Indiana Jones Genesis proto I was sent, I can’t do anything with that either (although given the machine / email account on which it was stored got hacked I’m surprised it didn’t end up being leaked, guess that isn’t what whoever hacked it was looking for tho) So yes, sometimes it’s not possible to do anything about a situation even if you’d like to.
I think when you’re dealing with old games, or ‘at risk’ software / hardware it’s important that everybody does pull together, and you see a lot of that with MAME / MESS, but as I’ve said before you do also see a lot of things being done for personal / political reasons which really don’t benefit the bigger picture, and sometimes it just isn’t possible.
I imagine even if Seibu do have paperwork for any of this stuff there’s so much history, so many changes made to things since it was originally done, turnover of staff, red tape and other processes to go through that a release of such information wouldn’t be possible, maybe they even licensed it from somebody else? One of the good things about MAME is that things just get done, rediscovered through genuine reverse engineering, bypassing that issue altogether and documenting things for people to use / build upon in future ports.
In the end asking everybody to work together is a bit like asking for World Peace; unfortunately it isn’t in the best interests of all concerned and everybody is afraid they’ll be the ones getting a raw deal.
My 2 cents regarding refactoring:
Imho it is always a delicate balance and this is not just limited to emulation projects but basically everyting that looks like software. On one hand you want to make progress, implement new functionality, clean up and improve stuff and the like. This is very satisfying in the end since you can “see” what has been done (maybe not in a physical sense but people using it will notice the improved API and the like, I think you know what I mean).
On the other hand your code base matures, some assumptions initially made no longer hold true, new areas of application exist (which nobody could imagine a few years ago) or maybe your code simply has some design issues that didn’t bother you in the first place since it made things so much easier but now it does (think global variables for example).
Which means imo that some refactoring becomes inevitable over time given that you want to continue developing the code base. If done properly it shouldn’t have hell of a performance impact (eg converting C code into proper C++ comes with minimal overhead whereas the ease in handling usually increases much more). But of course you have to watch out not to overengineer. When it takes a medium to good programmer a couple of minutes to figure out what is being done and how things belong together whereas beforehand you could just see it you probably did too much of a good thing (I have seen some real life examples of this, unfortunately).
In the end it boils down to a matter of good taste and experience I think. You probably shouldn’t do without refactoring but overdoing doesn’t help either. It’s a fine balance and sometimes tricky to strike.
Hap,
I think there are more than just two characters in the room. Which isn’t necessarily a bad think.
Gosh, I meant “thing”.
Yes, the refactoring into device classes has overall benefits, and if done carefully should be zero impact. There are many cases where I’ve been able to clean up drivers by making use of devices, systems with multiple instances of a sprite / video chip benefit greatly for example (the work I did cleaning up toaplan2.c)
The timing is more the questionable part, with a full release on the horizon I personally think the codebase should have been mostly locked down and tested properly for a week prior, actual progress / new drivers and bugfixes for regressions only, not changes which could have a wider scope for things breaking and require subsequent full regression runs.
MAME also has fairly long standing ‘split-personality’ issues with old legacy devices and modern ones which is slowly getting cleaned up, I think the introduction and then complete replacement of the device system which created this mess is one thing which has put some people off, a lack of trust that the work they’re doing won’t become obsolete as soon as they’ve done it. Thankfully MESS has always had a cleaner codebase in this regard, and with Micko, from the MESS side at the helm we’re starting to see some of the good work done there applied to MAME. CPU cores are still an issue however, the upgrade path is anything but trivial. In that sense again I’m not moaning that these things need doing, because it makes it clearer how things should be developed, however the real world benefits are minor.
I do have an issue with ‘tinkering’ in MAME tho, especially with MAMEdevs not being able to decide what’s what. One day the ‘free’ ability for MAME to run some console software on arcade units is ripped out, because ‘MAME emulates preinstalled standalone cabinets and the user wouldn’t really be changing discs and using alternative setups’, today a change is made that will force everybody to go through the initial setup procedure for CPS3 games again instead of just loading a preinstalled setup, despite most units shipping preinstalled (the setup process is really just for exchanging games with kits options, and upgrading to new revisions, a procedure not really necessary in MAME) If you wanted to force a way to run the setup code it would make more sense to also have an additional blank ‘CPS3’ unit and use the MESS style software-lists as an additional option, allowing software listed CDs and carts to be exchanged / upgraded as you would with the real hardware if hardcore users wanted to play while leaving MAME to run the conveniently preinstalled cabinet sets for regular users otherwise. That would be win-win for all concerned, but the idea was rejected.
Such tinkering benefits nobody, is inconsistent and in the end just makes MAME harder to use by forcing users through processes they’d never really have to worry about. I fear all the nicely calibrated defaults some games have might end up being stripped out on similar grounds, because it’s the same thing really, a convenience so the user doesn’t have to manually configure all of it. I find this frustrating when I’ve been trying to promote the positives of MAME, show the easy of use, make sure things ‘just work’ with minimal messing about needed from the user; one of the big drawbacks of MESS which has has made it less popular than MAME over the years is that you had to know a lot more to operate it (although that has been improving over the last few years) Such changes also destroy the ability to use replays from MARP (who wants to sit through a 10 minute setup each recording attempt) and also make it more frustrating if you want to do dev work (I’ll quickly check a bug in Warzard, oh wait, no I won’t I have to run a 10 minute setup program) It was harmless functionality, which benefits everybody being stripped for no *real* good reason with no *positive* contribution to the driver, and I wasn’t even consulted about it despite it being my driver. Anybody who actually needed to run the flash procedure could just create a blank set of read only nvram files, or force the procedure through the test menu, now everybody must run it again or remember to keep all their old nvram files (when the good MAME advice is almost always ‘use in a clean environment’)
I think some of this just comes down to people who have run out of things to work on, or just don’t have the skills required to work on the remaining cases and are trying to stay relevant somehow. There’s plenty of REAL work to be done, but people would rather just do things like that which start to move MAME into the ‘hard to use’ dark ages despite an increasing number of people requiring things to be *easy* to use because they’ve never experienced the days when using a PC was tricky.
The argument ‘there’s no point in catering for such users’ comes up often, but I don’t think it’s a valid one, a solid userbase acts as a gateway for more experienced developers, if you lose your entire userbase you lose all mindshare, you lose the ability to attract anybody. Look at something like Facebook, it is what it is because of the users, and while not every user is going to be an app developer without any users you wouldn’t have anybody developing apps either, because there would be no point and nobody to test them. This means compromise too, giving people what they want. I’m sure FB want to make everything public, force you to use real names etc. but if you do that and enforce such policies you drive people away, or fail to attract them in the first place, hence nobody wanting to use G+, even if it’s by Google and so many people have gmail accounts.
I know I don’t run MAME / MESS, but these things do my head in… at a time when building up a good user base and providing the most complete functional project you can is of up-most importance it seems counter productive to strip convenience features.
I’m trying to promote all the good sides of MAME / MESS with my blog here, via UME, give people something they can use to it’s full potential, but it seems for every release I’m having to add ‘but be warned…..’ either because mass changes were made too close to a release, or people tinkering has destroyed convenient functionality.
It’s getting to the point where I’m worried about working on anything (especially the Fruit Machine stuff) incase somebody decides to kill off a couple of thousand hours of work, or relegate it to some unknown second class part of the project, with the amount of work put in so far something like that would be the proverbial straw tho.
On a more positive note, there are devs like Luca tackling some of the more difficult remaining cases.
http://www.lucaelia.com/mame.php/2012/Battle-for-the-Sun-A
One more Korean title to chalk off the list of unemulated games :-)
well,very surprised luca has done a great Mame work,Star Fighter is a good game,but I guess most people hope another vertical shooter game Double Wings also can be emulated one day
Double Wings is fine unless you let one of the bosses time out, if you can’t handle that I fail to believe you’re a real player with an interest in the game, and simply think you’re trying to sell MAME, and can’t sell it with such a bug.
Your obsessive repeating that I should emulate Double Wings every time I put a WIP post up is annoying.
Haze,I don’t sell Mame,sell Mame will be break the law,I can’t do it,I only think Double Wings is the last vertical shooter from 1990 that many people expect it can be emulated,the game is very famous
Yes, and it works 99.5% fine, better than a lot of games which are marked as working. There is one known issue which you’re unlikely to ever hit, most games have more original bugs than that.
Fighters History has MORE issues than Double Wings using similar / the same protection system, but is marked as working, incorrectly so in my opinion, but nevertheless, it is.
Kudos to you Haze, I imagined you were standing at speakers’ corner.
Also I do apologise if any of this seems ranty, people should know by now that they’ll get my uncensored opinion here, and if things frustrate me, they frustrate me and I’ll express that.
Throwing all history aside, I’m just a regular person trying to develop MAME, these are my concerns, my frustrations, whatever you want to call them. I’ve said before, praise where praise is due, hence also calling out Luca for his excellent SunA work because those games have so many subtle protections and weird per-game hardware variations that they’re just a nightmare to figure out and I’m damn glad there are still people involved capable of getting to the bottom of such things out. I expect we’ll see SparkMan up there soon too :-)
Excuse me, i’m annoying but can you help me?
i’ve successful imported time attack fantasy zone from ps2 in mame 0.146u2. Now in 0.147 loads but immediately crash.
In 0.146u2 i’ve added to segas16b.c this lines
static INPUT_PORTS_START( fzta )
PORT_INCLUDE( system16b_generic )
PORT_MODIFY(“DSW2”)
PORT_DIPUNUSED_DIPLOC( 0x01, IP_ACTIVE_LOW, “SW2:1” )
PORT_DIPUNUSED_DIPLOC( 0x02, IP_ACTIVE_LOW, “SW2:2” )
PORT_DIPNAME( 0x0c, 0x0c, DEF_STR( Lives ) ) PORT_DIPLOCATION(“SW2:3,4”)
PORT_DIPSETTING( 0x0c, “2” )
PORT_DIPSETTING( 0x08, “3” )
PORT_DIPSETTING( 0x04, “4” )
PORT_DIPSETTING( 0x00, “240 (Cheat)”)
PORT_DIPUNUSED_DIPLOC( 0x10, IP_ACTIVE_LOW, “SW2:5” )
PORT_DIPUNUSED_DIPLOC( 0x20, IP_ACTIVE_LOW, “SW2:6” )
PORT_DIPUNUSED_DIPLOC( 0x40, IP_ACTIVE_LOW, “SW2:7” )
PORT_DIPUNUSED_DIPLOC( 0x80, IP_ACTIVE_LOW, “SW2:8” )
PORT_MODIFY(“DSW1”)
PORT_DIPNAME( 0xff, 0xff, “Free Play” ) PORT_DIPLOCATION(“SW1:1,2,3,4,5,6,7,8”)
PORT_DIPSETTING( 0x00, DEF_STR( On ) )
PORT_DIPSETTING( 0xff, DEF_STR( Off ) )
INPUT_PORTS_END
ROM_START( fantznta )
ROM_REGION( 0xc0000, “maincpu”, 0 ) /* 68000 code */
ROM_LOAD16_BYTE( “fzta.a7”, 0x00000, 0x20000, CRC(ad07d1fd) SHA1(63fbaa135a3860bd956d5147a5f64d951d2ebdba) )
ROM_LOAD16_BYTE( “fzta.a5”, 0x00001, 0x20000, CRC(47dbe11b) SHA1(edc6960506745235bb8668eaf71139cef4a2cd16) )
ROM_REGION( 0x60000, “gfx1”, 0 ) /* tiles */
ROM_LOAD( “fzta.a14”, 0x00000, 0x10000, CRC(9468ab33) SHA1(714660b9eafb78ef5d3aed218367b4e5708376f6) )
ROM_LOAD( “fzta.a15”, 0x20000, 0x10000, CRC(22a3cf75) SHA1(6f21bc2a565738b997f898ed6ee631e9452662ca) )
ROM_LOAD( “fzta.a16”, 0x40000, 0x10000, CRC(25cba87f) SHA1(abece2c27cd9d299319fa3ea87e016606426abc2) )
ROM_REGION16_BE( 0x180000, “gfx2”, 0 ) /* sprites */
ROM_LOAD16_BYTE( “fzta.b1”, 0x000001, 0x20000, CRC(0beb4a22) SHA1(e35f6d92b88f0730ccf03a090900ca2ed9824e74) )
ROM_LOAD16_BYTE( “fzta.b5”, 0x000000, 0x20000, CRC(7f676c69) SHA1(231e7829b4ddb039f9075aebd1f2a123c79d396d) )
ROM_LOAD16_BYTE( “fzta.a1”, 0x100001, 0x20000, CRC(40e1db9a) SHA1(305cd5e2d8512774638dfa724df6696ffa81ebb2) )
ROM_LOAD16_BYTE( “fzta.b10”, 0x100000, 0x20000, CRC(acbb5cff) SHA1(bd356f664ec1c0e955161aa3afd06f2aeda80357) )
ROM_REGION( 0x50000, “soundcpu”, 0 ) /* sound CPU */
ROM_LOAD( “fzta.a10”, 0x00000, 0x08000, CRC(dab6fcd0) SHA1(151b62c5353533ae8660cbeebd8fe3219adbf4b5) )
ROM_LOAD( “fzta.a11”, 0x10000, 0x10000, CRC(835fbdca) SHA1(ae0a6aab9c546b002298d5361a564b905af1c8f6) )
ROM_END
GAME( 2008, fantznta, 0, system16b, fzta, generic_5704_extra_ram, ROT0, “Sega / M2”, “Fantasy Zone – Time Attack Mode (System 16C version)”, 0 )
Now in 0.147 i’ve modified GAME as
GAME( 2008, fantznta, 0, system16c, fzta, segas16b_state,generic_5704, ROT0, “Sega / M2”, “Fantasy Zone – Time Attack Mode (System 16C version)”, 0 )
What is changed in the driver that doesn’t allow the game to start anymore?
If you would i can upload the rom somewhere to permit you to try.
Thanks
No need to apologise imo. This is your blog, your place, so you can do whatever you want here. If people don’t like what they see or are not interested they just move on. As far as I can see you produce (or provoke on times) enough feedback and have enough people coming back, so it can’t be that bad ;-).
There’s also an update at
http://agemame.mameworld.info/
after I pointed JW in the right direction (pun intended) for the M1A/B games.