UME is the complete/combined version of the MAME / MESS project.
0.154ex1 is built from SVN revision 31598
There were still a number of issues with DCS sound in the 0.154 MAME release causing some games like Carnevil and the 3D Gauntlet games to lack music, these have since been resolved so it is recommended you use this build instead. Some other issues such as missing sound in the Eolith titles have also been resolved, in addition to a number of other bugs that were caught after the 0.154 release. Assuming no new bugs have been introduced this should be considered a more stable build than 0.154.
I have specifically built against SVN rv. 31598 rather than the more cutting edge ones because the revisions immediately after 31598 do nothing but destroy the human parsability of some areas of the source. Assuming the team has any common sense these changes will be quickly reverted so I’d rather not inflict them on my users due to it being unlikely they’ll appear in a final build, it would just result in confusion.
UME 0.154ex1 Windows binaries – 32-bit, 64-bit and all tools
UME 0.154ex1 sources
Here is the 0.154 to 0.154ex1 SVN log
Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.154ex1 Windows binaries – 32-bit, 64-bit and all tools
(SDL binaries might come later)
Points of Interest
Fixes as mentioned above, Music Ball as shown below, some other stuff I’ll write a bit about soon.
Thanks for your efforts, Haze.
thanks for keeping us warmed about bad changes in mame but I think never be reversed because developer too arrogent
They just keep on going. Some get fixes as they go. Now be warn not everything will be working like those should when mark as working. I ran into some that doesn’t work or having an issue. Most of those will work. Same for the SDL builds.
Unfortunately I think you’re right.
I’ve been bordering on actually saying enough is enough for a while (and it’s very rare that I won’t sync something into UME) but once people start destroying the actual documentation value of MAME by making the source more difficult to read then I think it’s enough to actually push me over the edge.
This is human readability 101, if a rom label is so generic that you have same name different hash collisions then the BEST solution is to give it a unique, but easily identifiable name to avoid that, not tell the users to suck it, and make the source more difficult to read by making the only note of that a tiny comment at the end of a line, that’s how mistakes.
Most people making driver cleanup modifications will look at the ROM NAMES not the checksums, we’ve seen it plenty in the past. As a human you scan read, parse left to right, the leftmost human readable entry in any structure is the one you notice and pay most attention to, in the case of MAME that is the filename. As in 99% of cases there are NO collisions and 99% of the time the same name means the same hash it’s a fair assumption for anybody reading the source to make as it saves a lot of time in reading; that’s why we added the ‘(__xxx)’ bits to some filenames because you know immediately that the rom is specific to that set, when otherwise the names would collide and an incorrect assumption would be made. Removing those and having a comment hidden away on the very right hand side (the place you’re least likely to notice when quickly parsing something) to indicate the collision does not help because it won’t be noticed, enforcing unique names ensures the difference IS noticed immediately and that NO mistakes can accidentally be made when updating things because that fact was missed.
It also means that in some instances the likes of MAMEUI will *silently* load the wrong set because if you don’t have the right one but the filenames in the parent zip are now the same.
The standard we were using was agreed on by a good number of devs because it represented the best solution, easiest to read, most maintainable, least likely to result in bugs / errors, easiest to identify, and most logical. What’s been done to a whole bunch of source files is nothing but destructive garbage in the name of some dumb ideology that lacks common sense and only has drawbacks. Things were as they were for good reason (and that reason was not Clrmame, Clrmame was just handy for warning us about such cases so that we could fix them)
‘Filename’ = ‘Rom Label.position’ is a very good guideline, but there are times (like with anything) when following it religiously is just dumb; we’ve see Korean boards with no labels or IC positions at all for example, all filenames on those sets are completely fabricated. Common sense is better than any strict rule.
It pains me to explain these things because they should be so obvious, and it really feels like an uphill battle to stop MAME decaying most of the time as people forget the good reasons certain things were done, or make changes without testing anything properly, and that’s not good at all.
left-to-right-reading? I reckon you’d complain as much, maybe even more, if i’d put the “sldh” comment next to the romlabel string.
“developer too arrogent” Thanks for the compliment but nope that is not the reason.
“destructive garbage in the name of some dumb ideology that lacks common sense and only has drawbacks”. “ROM_LABEL.PCB_LOCATION”, It is not a dumb ideology and it does make sense!
As for rom labels that haven’t been verified yet: How do you know it’s not verified already?
And take cps1.c, where rom labels were verified almost everywhere, yet we still had to have (__x) in them??
could you not edit your reply after someone’s reaction? :P it’s confusing and you lose credibility, like suddenly thinking anyway that “‘Filename’ = ‘Rom Label.position’ is a very good guideline,” after i point it out.
we’ve seen things get munched for similar reasons in the past, people seeing the same rom names and copy+pasting a single definitions they’d cleaned up without checking the checksums.
It was very annoying (I’ve had to fix up a few cases like that over the course of the project) and one reason I supported adding some kind of unique identifier in those cases.
it was a harmless, and neat way to address a genuine problem where manufacturers sometimes failed to use unique labels. Trying to force MAME to copy ideas that were bad / lazy ideas in the first place is not a positive, especially not when we can better document what the actual roms are by providing a more useful filename (eg revision date) within the (__ section, with the (__ clearly showing that it’s part of a name we created to improve documentation, rather than something on the chip.
The change just made was a destructive change with more disadvantages than advantages, plain and simple.
I always edit posts as I’m writing them, even with the articles, everything here has about 20 drafts as I proofread, and reword things to try and make my point clearer, I hadn’t seen your reply until after all the edits.
I would not be opposed to a OPTIONAL secondary NAME field for such cases to make it immediatly obvious that despite the same base filename the rom in this set is actually different eg.
instead of
ROM_START( misncrft )
ROM_REGION16_BE( 0x100000, "user1", ROMREGION_ERASE00 ) /* Hyperstone CPU Code */
/* 0 - 0x80000 empty */
ROM_LOAD( "prg-rom2.bin", 0x80000, 0x80000, CRC(04d22da6) SHA1(1c5be430000a31f21204fb756fadf2523a546b8b) ) /* Version 2.7 */
ROM_START( misncrfta )
ROM_REGION16_BE( 0x100000, "user1", ROMREGION_ERASE00 ) /* Hyperstone CPU Code */
/* 0 - 0x80000 empty */
ROM_LOAD( "prg-rom2(__version_2.4).bin", 0x80000, 0x80000, CRC(059ae8c1) SHA1(2c72fcf560166cb17cd8ad665beae302832d551c) ) /* Version 2.4 */
we could have
ROM_START( misncrft )
ROM_REGION16_BE( 0x100000, "user1", ROMREGION_ERASE00 ) /* Hyperstone CPU Code */
/* 0 - 0x80000 empty */
ROM_LOAD( "prg-rom2.bin", "version2.7", 0x80000, 0x80000, CRC(04d22da6) SHA1(1c5be430000a31f21204fb756fadf2523a546b8b) )
ROM_START( misncrfta )
ROM_REGION16_BE( 0x100000, "user1", ROMREGION_ERASE00 ) /* Hyperstone CPU Code */
/* 0 - 0x80000 empty */
ROM_LOAD( "prg-rom2.bin", "version2.4" 0x80000, 0x80000, CRC(059ae8c1) SHA1(2c72fcf560166cb17cd8ad665beae302832d551c) )
which could then be used by something like clrmame to build a unique name.. this solves both problems, especially if MAME looked for “prg-rom2.bin_version2.4”
I also wouldn’t oppose label and ic position becoming separate fields.
what has been done however solves nothing in a good way.
with the name / location split idea you could also have substitute macros for cases where there is no name or no location eg.
ROM_UNLABELLED
ROM_NOPOSITION
this would allow us to accurately document such cases and output that information.
yup, some good ideas there, but who’s going to implement it (cleanly so it fits well into the MAME core)
I dunno, how about the same people who changed the last implementation, making things more difficult to read?
I dug thru it earlier looking at it to see what you were on about :)
I was going to suggest exactly that. I am not a fan of smashing 2 bits of information into one field. More often than not it creates hassles later on. My rule of thumb is one bit of data has one meaning. In this case it is 2. Usually a sign that something is not abstracted enough. Removing the data is even worse. There should at the very least be some sort of comment. All of that data is hard won battle scarred data. Throwing it away seems wrong.
all this fuss for a 99% harmless change instead of pointing out the additional accuracy of msx floppies that now work much more closely to the real system ;)
As a result the vast majority of people just think no more development is going on in the emulator, except for the addition of a bunch of bootlegs and other clones…
I think that, at the very least, the recent changes should be reverted while we try to figure out a better way of doing it.
Then, once there’s some kind of consensus, anyone of us who feel confortable with doing so can make the effort to implement whatever new scheme we come up with.
here is an open copy of the mail sent to mamedev regarding these issues.
IMPROVING SOURCE DOCUMENTATION
————-
our current form is
ROM_LOAD( “5.ic16”, 0x000000, 0x080000, CRC(9bb675f6) SHA1(c3f6768cfd99a0e19ca2224fff9aa4e27ec0da24) )
I’m proposed complete form is
ROM_LOAD( “5”, “ic16”, 0x000000, 0x080000, CRC(9bb675f6) SHA1(c3f6768cfd99a0e19ca2224fff9aa4e27ec0da24) )
this would show that we care more about documentation than the filename.
if the chip is confirmed to have no label / ic position we could use
ROM_LOAD( “5”, NO_POSITION, 0x000000, 0x080000, CRC(9bb675f6) SHA1(c3f6768cfd99a0e19ca2224fff9aa4e27ec0da24) )
ROM_LOAD( NO_LABEL, “ic16”, 0x000000, 0x080000, CRC(9bb675f6) SHA1(c3f6768cfd99a0e19ca2224fff9aa4e27ec0da24) )
when we know it should have a position / label but we don’t know it then it should have
ROM_LOAD( “5”, UNK_POSITION, 0x000000, 0x080000, CRC(9bb675f6) SHA1(c3f6768cfd99a0e19ca2224fff9aa4e27ec0da24) )
ROM_LOAD( UNK_LABEL, “ic16”, 0x000000, 0x080000, CRC(9bb675f6) SHA1(c3f6768cfd99a0e19ca2224fff9aa4e27ec0da24) )
in case of UNK_POSITION and UNK_LABEL MAME could generate a warning on startup (like the NO_DUMP) one saying that we need that information verifying.
all .bin roms would become ‘UNK_POSITION’
this could be 100% transparent as far as our existing -listroms go, with MAME simply building the filename out of the 2 fields, so “5.ic16” as usual, or “5.unkpos” etc. if the unknown position macros were used.
HANDLING SAME NAME DIFFERENT HASH CONFLICTS
————-
I also propose a 3rd OPTIONAL field to use in cases where there are same name different hash conflicts (cases like Brian has pointed out where there’s no distinguishing factor on the ROMs or PCB)
for example mission craft could become
ROM_LOAD( “prg-rom2”, UNK_POSITION, “ver2.7”, 0x80000, 0x80000, CRC(04d22da6) SHA1(1c5be430000a31f21204fb756fadf2523a546b8b) )
and the clone (identical name/position, different hash)
ROM_LOAD( “prg-rom2”, UNK_POSITION, “ver2.4”, 0x80000, 0x80000, CRC(059ae8c1) SHA1(2c72fcf560166cb17cd8ad665beae302832d551c) )
and MAME could simply generate the filenames with that information. (it could even still genate the (__x) form we’re used to without it being specified in the source.
This means we would be encouraging the LABEL/IC to a greater extent (near enforcing it) but can also handle cases where manufacturers were too stupid to label their chips, by using the 3rd optional field for documentation of what the content of the chip actually is.
CONCLUSION
—–
What I’m proposing boosts our documentation, doesn’t throw away information in any cases like the current change, adds a system for alerting people to cases where we need extra documentation on PCBs, remains easy to read (clear fields, no chance of copy+paste mistakes) etc.
It would probably take a little getting used to, but if we really want to encourage people to do things properly, and highlight that factual PCB information is more important to us than a random filename then we should take these steps.
in addition we could have something like
DEVICE_POSITION
for device roms, so that the actual position could be passed in elsewhere, right now that is a bit of an issue because device roms can’t have any kind of position because the name is 100% hardcoded in the device, with no knowledge of the board.
That would be more work, but could be something to aim towards.
Even later we could start replacing the sizes with the ROM types instead for common types (because the rom type implies a certain size, and it would be better documentation) Right now ROM_CONTINUE cases make that impossible and such things would need to be reworked however.
To keep you going you could take it a step further. CHIP_PINS or something like that. Describe where each pin is tied down to? It may take building a second structure of ‘LINE’ or something like that. You could describe is something tied to ground or a voltage or some databus or some other chip? Pretty much 99% useless for emulation (i think). But if you wanted to rebuild a schematic out of the thing it could get interesting? You could even describe physical position (related to pin one maybe?). Unfortunately tons of this information would not exist and would be a massive undertaking.
Also I like your idea of ‘rom types’. To take it a step further you could even describe the different memory types characteristics. As each chip also has particular characteristics. Such as full/half duplex speed of read/write etc. Or things like ‘only read from this chip every other cycle’ (timings). Those things I could see playing back into the emulation to get timings correct and may make some squirrely behavior that exists now fall out simplifying parts of the code. You could then maybe use the pin stuff I described above to get ro behavior by looking to see if the r/w pin is tied down etc… Instead of some sort of generic rw flag?
ya :p
I feel a bit guilty saying this, but how about adding some more “Points of Interest”. Like how MESS is the 1st emulator to support TI CC-40 and TI-74 =)
Is there a good WIP thread for them anywhere? A lot of the best progress is hidden because aside from people who owned the systems the codenames mean very little.
Unfortunately I can see more people thinking we removed support for the msx than improved it with the ‘generic’ models gone too, I can’t name a single MSX or MSX2 model off the top of my head, so unless the ‘best guesser’ is going to make some suggestions I’ll end up having to dig through source files to find them.
That type of information could become important later when it comes to waitstates and the like I guess, also we know for a fact some PCBs only function with certain speed ROMs (eg. if you use slower older roms on a Model 2 it won’t boot)
Possibly something we could work towards, but initially it would be nice to see a movement towards my first suggestions, which would hopefully in turn encourage people to make note of things like IC positions, because at the moment too many people still neglect to do so and there are many, many drivers lacking such information. Far better to build a filename from factual information than specify a filename directly.
That’s one reason I like to post a summary and screenshots for interesting improvements – it makes it easy for Haze to show in the summaries here.
I don’t know anything about TI calculators or MSX floppies, and there was no mention of them on bannister, so I’m as much in the dark as Haze :)
Center Court has unpopulated EPROM sockets (the ones in positions A2, A3, A5 and A6). I gather this info from the picture in your recent blogpost. It would be good to have a way of documenting that in the source as well.
I guess that if someone would develop homebrew games to run in these boards it would be desireable to be able to use these extra sockets if needed and it would be handy to have it all clearly documented and mapped to the propper memory addresses.
Even if the original game did not use these sockets, they are part of the hardware that needs to be documented.
Any wip news on Nebulas Ray & Photo Y2K 2 ?