+ T +

The old code is still in the current source, it's just commented out in favour of the new stuff. Then it's just a matter of a few little adjustments here and there. An adept coder like djohng would have no problems re-implementing it. I'd be happy to post my modified source but my build of FBA-XXX is so heavily customized to my own romsets and tastes that many of the roms from djohng or gogo's version wouldn't even show up.

svchaosa is the MVS version

Actually the worst sound problems were caused by changes to the VMM routines that were made in later versions of FBA-XXX. I was able to virtually eliminate all sound issues by restoring the original VMM code.

Is the source available? And if so, could you please post a link to it? EDIT: Nevermind. the source is included in the distribution - many thanks

djohng, does your new build include support for the SVC Super Plus romset svcsplus? If so could you possibly post your driver? I've had no luck at all getting it working Many thanks.

I understand what you're saying but I think we should keep in mind that the purpose of MAMEoX is simply the playing of arcade games on the Xbox whereas the purpose of MAME is to emulate arcade hardware as accurately as possible no-matter the performance cost to low-spec systems. There may come a time at some point in the future when just blindly updating to the latest core will actually cause MAMEoX to slip to the point where the Xbox struggles to run anything at all at a decent speed. Then the only way forward for the project will be backwards as developers begin to look at which drivers were the most Xbox friendly. The ultimate goal being, not just an Xbox version of MAME, but an 'Xbox optimized' version of MAME. Just my thoughts.

djohng, if a custom MAMEoX is your next project, would you consider re-implementing the older Midway drivers that were changed after version 0.72 so that we can once again play the Mortal Kombat games at a decent speed?

The VMM issue is seperate to the mslug4nd problem. In fact I got so sick of the sound glitching every so often in big games when using any compile based on 09-01-2004 that I'm now using the 06-04-2004 release and just adding the features/drivers that I want to it. samsh5sp works just as nicely on this version as do all the most up-to-date rom dumps that I have. The only difference I've found is that to get the transparencies from 512Kb S roms in games like SvC Chaos, the rom data has to be in memory order whereas 09-01 required it to be in rom order, that's it so far as I can tell. IMO this version is a far better base to work on. Manto should never have changed the VMM code in the 08-02 release. It was much better as it was.

Make sure you're using decrypted V roms. A while ago I tried to use a set that had the V roms encrypted with the 09-01 release and the results were just as you describe.

Bad sound (that is to say slightly crackly at times) in the larger games is something that got noticeably worse when the VMM routines were changed in the 08-02-2004 release. If you try the 06-04-2004 version you'll hear that it still occurs only to a lesser degree. A good place to check this is in SvC Chaos on the character select screen. Notice how when you move the selector to each character the 'bleep' that sounds is broken up and crackly, however if you move it back over a character you've already highlighted then it sounds fine. I did try to re-implement the original VMM routines into my own build which I'm continuing work on but I think it would take a level of coding skill that I'm not yet capable of. Perhaps djohng might consider giving it a go. But I really don't know why Manto changed the VM routines in the first place, there was nothing wrong with them as they were. >_

djohng, if you replace the file 'burn_ym2610.cpp' with the one from the 08-02-2004 version source then it fixes this problem. I don't know why but it works.

I use WinHex for splitting/joining.

Just split each file into 2 equal parts and rename accordingly.

Will someone be able to host the modified sourcecode?

I wonder if someone here might be able to help me out. I'm trying to get hold of sources to versions of FBA-XXX prior to the 08-02 release to test a theory. There is an old GOGO source on xbins but I haven't a clue which version of the emu it's from. So if anyone has any old sources lying around could they please let me know? Many thanks.

The build I've released patches for uses much older S roms that are mostly incomplete 128Kb versions. I used these in the build because they're the ones that came with the original releases of the romsets and so people are far more likely to already have them than the new ones. The custom build I'm using on my Xbox has been updated to include all the latest drivers for the most recent (and in many cases final) dumps of the roms including the above S roms. I was going to release patches for this build in case anyone else was interested but djohng's upcoming version sounds far better than anything I can produce so, if he doesn't mind, I think I'll leave the releasing side of things to him from now on. The following is a list of updated roms in my unreleased custom build (all tested and working):

The S rom contains the text layer for the game. This data usually resides within the encrypted C roms and is extracted as part of the decryption process. However since using pre-decrypted roms (nd sets) bypasses this time-consuming process, a pre-extracted S rom is usually necessary. FBA-XXX, on the other hand, is designed to extract S rom data from even pre-decrypted C roms unless otherwise specified in the driver. This makes the loading of nd sets take longer than they should and also is annoying because (and call me old-fashioned if you like) a true pre-decrypted set should always include an S rom. So I'm glad to hear that support for them is being re-included in djohng's promising sounding build. And none of the above roms are overdumps. Those are all perfectly correct CRCs as extracted from the original C roms. The only exception is kof2003 which actually has 1Mb worth of S rom data in its Cs. But the 512Kb works much better with the current set. The names are just what they are called in my sets ATM, ultimately the names of all roms need to match those in the individual driver.

Then here's the driver (note that I've removed the s rom decryption lines at the bottom since with the s rom added they are unnecessary): Have you tried the latest patch?

Did my build run samsh5nd okay after I added the s rom? If so I'll post the driver data for you.

Are you using the 512Kb s roms for the romsets those that support them? Here are the 100% correct crcs if they're of any use to you : garoud.zip ---------- motwn_s1.rom 512Kb be2ba1a5 mslug3nd.zip ------------ ms3n_s1.rom 512Kb 2628d663 mslug4nd.zip ------------ 263-s1.bin 512Kb c349ad60 kof2knd.zip ----------- kof2k_s1.rom 512Kb 38901d4d kof2k3ba.zip ------------ 271b-s1.bin 512Kb 3b658d26 svc.zip ------- 269-s1.bin 512Kb AD184232 svcplus.zip ----------- 269p-s1.bin 512Kb 06125f98

Phew! Finally someone who knows what they're doing. I guess I can take a rest. I just have one question. Since it isn't against the rules, would it be possible for you to put up the modified source-code for d/l? I'd love to take a look to compare and see exactly where I've been going wrong. This has been a great learning experience for me.

Well I've replaced the samsho5 driver with a more recent one in the hope that this might help (again I don't have the encrypted set myself). However this driver was written for a newer version of the romset and I've simply substituted the CRCs for the current FBA-XXX set so who knows. Unfortunately I'm not a coder, so things like this are the best I can do when problems arise. If anyone with more knowledge can help out then I'd very much appreciate it. http://www.thraxen.com/emu1/FBA-XXX_09-01_newsets_FIX3a.zip

samsh5nd should be working now since it's just the old s rom problem again (check the README for CRC). samsho is the encrypted romset and so doesn't use a seperate s rom. I've removed the extra code that was causing the encrypted set of mslug4 to be broken. Perhaps this was causing problems for samsho as well (?). http://www.thraxen.com/emu1/FBA-XXX_09-01_newsets_FIX3.zip

This update fixes display problems in Metal Slug 3 and 5 (128Kb s rom should work now): http://www.thraxen.com/emu1/FBA-XXX_09-01_newsets_FIX2a.zip

Prican, I've had another crack at adding IQ_132's code. There were some duplicate lines last time. See if it works now: http://www.thraxen.com/emu1/FBA-XXX_09-01_newsets_FIX2.zip As for matrimnd, does anyone have the v2d and v4d roms from the original dump?: 266-v2d 945F8831 266-v4d 393C9A62 If so perhaps substituting these for the newer ones in the driver might help the sound problem. I don't have them to hand ATM so I'd be grateful if someone could just put them in their matrimnd.zip and give it a try (just make sure CRC check is off). I had to use several files from the 08-02 version to make this build work properly. So it's not surprising that some previously fixed bugs might return. If anyone can give me an idea of how I might go about addressing this then I'll happily take a look. But surely it's not that big a problem is it?