mame mame

    
 
Haze's MAME WIP

rss  Subscribe this feed

Recent Articles :
Last Article :
[15/05/2012 23:59] UME is GO

As of MESS SVN revision 15179 the UME (Universal Machine Emulator, aka combined binary) target is present in the MESS SVN tree
(mirrored on the GIT too)

This target can be built using the command
make TARGET=ume
(or make -j6 TARGET=ume if you want to use more cores when compiling)

Hopefully people will remain open minded about this target, and it doesn’t become some sort of taboo subject.

There might still be some issues with building the tools which need cleaning up (windows specific hacks which things like wimgtool depend on, but exist only in MESS) but as far as a working combined binary goes you should be good to go with that.

As I’ve stated I will provide these binaries for the next major release synced to the point of whichever release comes last (MAME/MESS) (the projects are usually synced at each others release points anyway)

For day-to-day use the MESS tree isn’t 100% synced with the latest MAME developments, but usually gets synced up within a day or two, so it isn’t usually an issue. There will be an eventual move to a new server where development of both projects will take place, and I’d assume the target will be carried over when that happens.

As I’ve stated elsewhere the main advantage of this solution is convenience, if you’re running MAME anyway you may as well be using UME instead. That way if you ever get curious about how something else runs on one of the consoles, or just use the project to it’s full potential then you have that option already at your fingertips. The quality of the MAME emulation is the same as always, and the integrated MESS emulation provides a ‘good enough’ solution for many computers / consoles which could save countless hours in setting up and learning a completely different emulator if all you want to do is quickly test something in a familiar environment. I’m not going to lie and say MESS / UME is currently better than the standalone emulators, but it can be a heck of a lot more convenient if you’re already familiar with MAME and don’t need all the bells & whistles offered elsewhere.

I hope this does eventually increase exposure to the MESS codebase for people who might have been weary to try MESS otherwise, I fully understand that not many people are going to want to actively search out MESS on it’s own, but if you already have the code in the binary you’re using anyway there is nothing to lose by trying it as a first option and in many cases it will be just fine. Obviously having it as an alternative build doesn’t quite have the same impact as having it as the main build, but hopefully people will see that they have nothing to lose by building this target, even if you just ignore the MESS side of it completely!

I’m assured by various people that proper support in the QMC2 frontend will be available with the next major release too, so again that’s one reason I’m not supplying binaries yet, although I imagine the QMC author can take the addition to the MESS tree as a sign that the UME name / configuration is final now and put something out :-)

Personally I find it pretty cool to know that I can run the Genesis version of Sonic using the exact same codepaths in the emulator as the Megatech version (just sans the annoying menu), and in addition to that use the very same code to run the majority of the Genesis library rather well. Likewise I can compare ports easily, and really have a whole new world to explore without leaving the confines of the emulator. It’s also good for seeing how solid the emulation code used for a number of MAME systems is when exposed to a larger software library, and thus building (or destroying!) confidence in the accuracy levels of MAME for those systems or understanding how well the Arcade games on the platform actually utilized the hardware compared to the more general software library. It’s an adventure of knowledge and new discovery.

As I said, I’m not posting binaries yet, although I won’t stop people posting them! (I’d love to see others taking the idea and running with it) but this is just a heads up to the ongoing progress really.

I’d like to thank Micko (current head co-ordinator of both MAME and MESS) for checking in the target (and in fact being responsible for the code which has allowed this 100% clean solution in the first place) I hope people enjoy it and make use of it.

  
Kale's MAME WIP

rss  Subscribe this feed

Recent Articles :
Last Article :
[28/03/2012 01:53] Desastre Natural

Understood and hooked up sound HW in Little Robin, that is a weird combination of 2 DAC sound chips, the video scanline register, interrupt generation (irq lv 4 with an input port that defines the kind of irq, currently hooked up with the video frame number) and two lovely 16-bit port registers (one for each DAC) that alternates the resulting 8-bit sound index according to an external source (frame number % 16 with current implementation, as each “sound irq” happens every 8 frames). And by alternation it means in the sense of muxing between LSB or MSB of the aforementioned sound index (that is obviously pointless if isn’t a form of protection).

  
Robiza's MAME WIP

rss  Subscribe this feed

Recent Articles :
Last Article :
[22/01/2011 16:53] Fixeight e i suoi cloni

Ha richiesto molto piu’ lavoro sia in fase di decrittazione per la presenza di opcode senza riferimenti negli altri giochi (kbash, dogyuun, vfife e batsugun) sia per la presenza di una EEPROM.

Alla fine, grazie al lavoro congiunto di me stesso, Haze a AWJ, siamo riusciti a implementare il sonoro. La conseguenza per ora è stata la necessità di creare un clone del gioco per ogni paese supportato (sono 14). Questo perche’ la EEPROM per ogni gioco è differente e pur essendo generabile dal codice del gioco, non è possibile attivare quel codice senza fare saldature nella PCB (questo per l’assenza di DSWs e Jumpers).

Nel caso in cui tramite i valori presenti nella EEPROM sia possibile variare altri parametri del gioco oltre al paese, tale implementazione è scorretta. Ci sarebbero nel caso due alternative: aggiungere dump di EEPROM di cui si ha la certezza della relativa presenza in sala giochi, o implementare un qualche sistema in gradi di riprogrammare la EEPROM (simulando ad esempio la presenza di jumpers nella PCB). Vedremo. Per ora accontentiamoci del sonoro.

 
--- © 2009 EMULAB - Webmaster Simone - Adviser Ricky74 ---