with reference to this thread....
http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=44666&page=58

There's about a dozen SCV games known to man-kind. Same for the A'Can. Can we hard code those and be done with it? One of MESS's big fall-downs is lack of hard support for _known_ titles.

Yes I know we've talked about this before (well Haze and I have), everyone else seems to be scared of the idea for some reason. It works for MAME, it can work for MESS too. At least for systems with just a few games and/or cartridge systems where it's extremely unlikely to be running non-genuine software.

Before anyone says it _could_ run other things like homebrew etc, who would write such a program for this feeble and rare system? The answer is no one. If someone did write a program who would run it? Maybe 1-2 people. That's hardly justification for not documenting the software that was released officially.

In any case, the system is flexible enough to allow loading 'unknown' (i.e. homebrew etc) software if required. Let's hard code the known software so we know where we stand and have a road map to refer to.

I guess there will be either no replies or all negative replies and nothing will be done. As RB said in another thread, 'MESS has little if no adult supervision'.
This also suggest lack of quality control and lack of usability from a user-point-of-view. So what you get is really a mess. That's bad.

If the MAME principles are applied to MESS, it can become like MAME. I know that promotes pokerom collections etc, but that is _exactly_ why MAME thrives so well (well MAME has more complete emulation and probably better games too which also helps). There was another thread where someone searched long and hard and finally found some (hoarded or rare) software to test one of the new drivers. Yet another message said he wanted to test and bug-fix some issues in a driver but couldn't find any software for the system so nothing was done. If the games were hard coded you wouldn't have to search long and hard, you would just download it from one of 100,000 places.

Before you go on about piracy etc, let's not kid ourselves here.... everyone that uses ANY emulator is a pirate at the lowest level. You downloaded a ROMset to play a game you didn't pay for. What we should strive for is to wipe out obsolescence by having every piece of software in tens of thousands of locations all across the planet, so things are not lost. Everyone who supports MAME and MESS already knows that, or should. So please don't open that can of worms here, thanks.

Now think about it..... emulation is useless without software and software makes emulation popular. One example is the Model 2 emulator by ElSemi. There are people creaming their pants when a new version is released. Sure it's a very nice piece of software and highly enjoyable but nevertheless it's just an emulator and it was made popular by *software*. Software makes hardware popular too. For example I bought a PS2 just so I could play Time Crisis 2 with a real Namco gun and I'm sure plenty of people bought an XBox360 just so they could play some killer title that only runs on that system. Software is the key to success.

Now MESS has support for some systems that no one else emulates so it has some pulling power for old school systems, but most people don't even know what MESS is. We all want MESS to be more popular. This can be achieved by getting the emulation more accurate (which is always Work-In-Progress of course) and by documenting the software that ran on those systems so that they become more popular. More importantly documenting which game/software(s) work and which don't so emulation bugs can be ironed out. The emulation part is coming along nicely and is much improved over previous versions. The software support is a BIG let-down.

In favor of it.....
1. Documents known titles per system.
2. Documents exactly which titles work and which don't.
3. Promotes collections (this is good believe me) so titles are easier to find, allowing testing of more titles and bugs to be found and fixed. Any dev already knows a system with 1 game is harder to bug-fix than a system that supports hundreds of titles.

Against...
1. Some work involved adding code to the drivers although most are already known via the GoodTools lists so it's mostly a copy/paste affair plus a bit of glue logic.

I don't see any other issues but let's discuss it in more detail than before. Like let's try to work this out and make it actually happen *this year*.

Maybe 2010 can be the year MESS got serious about support for software :-)

The issue with this is that it's a slippery slope. While at this juncture it would be theoretically possible to have a known-good list and call it quits for things like the A'Can and SCV, it'll cause an endless amount of grief for people with respect to more popular systems.

I honestly don't think that there's any hope of ever getting people to properly redump and hard-code thousands upon thousands of NES, SMS, TG16, SNES, Genesis, Game Boy, Game Gear, N64, GBA, VHS, YMCA, NAACP and EFTPOS cartridges, not only because of the gargantuan financial constraints, but because of the monumental time soak it would be as well.

At this point, I'd say the best course of action is to shrug and go for pints.

Well like I said, a lot of negative replies will come out of this simply because it's too hard. It's not too hard. It just requires thought and some work.

I don't recall saying we should have a known good list and call it quits. The list is always open.

I also don't recall mentioning redumping. We should just support what's out there in whatever format it's in until such time as something better comes along (the MAME philosophy strikes again). If nothing better comes along then fine.

In any case we can start small. The APF M-1000 has a pretty complete list of properly dumped cart titles that would be well suited to a hard coded list.

At this stage the negative argument is pretty weak ;-)

Well, the only other real question I have is whether or not you're proposing locking out homebrew entirely. MESS has a pretty spectacular debugger, and it would be mildly lame if you couldn't use it to debug your own stuff. For instance, the N64 driver is the only LLE-based N64 emulator around, so it's the only one with relatively guaranteed street cred as far as testing your stuff against hardware. Why not let people throw whatever they want at it? Throw up all sorts of red flags, but let 'em do it, they'll figure out a way to do it anyway.

Quick response:

We need the concept of software lists added to the framework. Drivers can pick which software lists they support and software lists can be reused by several drivers.

Why the seperation? Take a look at the MSX computers. Most had 2 cartridge slots; some had 1 cartridge slot. Same games behaved differently when they had a certain other games inserted in the 2nd slot. Going the 'driver-per-title' route you'd end up with #of MSX driver * ( number of MSX cartridges ^ 2 ).

MAME could also benefit from software lists; the neogeo driver could then become drivers for the base hardware (1 slot, 2 slot, 4 slot, 6 slot boards) and software lists for the several cartridges. Then it would really emulate the system.

Imo, the 'software list' should not only support cartridge but also floppy and cassette images in the long run.

I've been playing with this idea for a while already, I just haven't been able to do any serious work on it.

Drivers would of course have some indication whether they allow mounting "unknown" images or not. Which you'd typically turn off for MAME, but on for MESS.

I've already addressed homebrew. It can be flagged as 'unknown' with a message 'run this at your own risk, it may not work' etc
this is akin to stupid governments putting up signs at beaches to say 'Don't swim here because you might be eaten by a shark'. Then someone swims there anyway and loses a leg and then sues the government. But the government is covered because they had the sign.
You can run your homebrew, just be aware we don't support it and it may not work and that it's not our problem if your computer crashes and burns and you die in the fire.

Unless the homebrew works on the real thing; then we have a bug of course

If somebody had the time to compile lists of games and their details, fine. But people must be allowed to run whatever else they like. No other non-arcade emulator places restrictions on what you can do. It smacks too much of big brother control, like what the current-gen consoles do.

On loading a title, MESS simply looks up a CRC32 (etc) on the list of titles supported by that system. If it's not found the message can say 'This is unsupported software. The MESS team does not offer support for unofficial software other than allowing it to be loaded. It might work or it might not. Run it at your own risk.'

Robbert:
Please (everyone) can we drop the big brother lock-out replies. Read the first post. I already addressed homebrew. Not locked out. Sheez.

Plus 90% of the lists are already compiled via the GoodTools lists. Also listed above.

When people reply here can we actually read all the posts starting at the top first? Thanks.

Perhaps the use of .hsi files could be plugged into the UI, instead of just the Windows frontend (MESSUI) somehow. This way, you can get a list of software, as is already set up for a number of systems.

Good* isn't always the best source for original software, either. For example, the vast majority of GoodCPC titles are protection hacks and/or have trainers added. Very little, outside of CPC+ cart games, are original images. Not to mention that GoodCPC doesn't cover tape games, either.

There's always going to be gaping holes in the software support lists. That's because MAMEDEV didn't create it ;-)
Like I said, we go with what we have and it can be improved later. It's just a text list after-all. It's not like it's hand written in assembler or something ;-)

Should only officially released titles be included, or should all known software be listed (homebrews, hacks, etc.)? There will definitely be cases where it's hard to draw the line as to what's official or not (though admittedly something like the SCV isn't one of them). I'd be inclined to document everything known (except perhaps bad dumps), with a field to indicate what its origin is.

Is something like the current hashfile system (with perhaps better exposure and definitely more comprehensive lists) good enough for what you're wanting? Here's the APF M-1000 hash file (and I can see right away it's out of date, since it doesn't have the Space Destroyers checksums):

<hashfile>
<!-- apf m1000 -->
<hash crc32="6baad95f" sha1="b63ad3a60b59aad9b4605ff96f77839565144278 " name="Catena">
<cartnumber>MG1001</cartnumber>
<chip></chip>
</hash>
<hash crc32="5d03a812" sha1="29db4ca3c8b76c413b84b6d2bfd3499a70eccd3d" name="Catena">
<cartnumber>MG1001</cartnumber>
<chip>MG1002</chip>
</hash>
<hash crc32="e58a5d5b" sha1="205d659db0e0ab0292d33b5b4a9c2b46ca9d1dd5" name="Hangman/Tic Tac Toe/Doddle">
<cartnumber>MG1003</cartnumber>
<chip>MG1003</chip>
</hash>
<hash crc32="cca5836b" sha1="4ff1c4ffa46c543bbf48a519a4285b5d2c697ae3" name="Bowling/Micro Match">
<cartnumber>MG1004</cartnumber>
<chip>MG1004</chip>
</hash>
<hash crc32="bc1f5b8b" sha1="3e2f1e93501cd0dd2c9b747c594b784360e5b175" name="Brickdown/Shooting Gallery">
<cartnumber>MG1005</cartnumber>
<chip>MG1005</chip>
</hash>
<hash crc32="1fb354b7" sha1="2c93d8e764b1e1dfdc1bde7888b385cc28064f86" name="Baseball">
<cartnumber>MG1006</cartnumber>
<chip></chip>
</hash>
<hash crc32="38faa709" sha1="1a99f4781ce4604a550f4ec9d8559e3456303464" name="Blackjack">
<cartnumber>MG1007</cartnumber>
<chip>MG1007</chip>
</hash>
<hash crc32="811c6269" sha1="f820334bb6df9b856f54f1957b60a5e70bdd6d7e" name="Backgammon">
<cartnumber>MG1008</cartnumber>
<chip></chip>
</hash>
<hash crc32="21d5f63f" sha1="fa34ebdb799ccd2bff9f63ce4189a4ee690706fa" name="Casino I: Roulette/Keno/Slots">
<cartnumber>MG1009</cartnumber>
<chip>MG1009</chip>
</hash>
<hash crc32="0504d667" sha1="6e33593f9e7a4551bc31b347741d9ff87ce618ca" name="UFO/Sea Monster/Break It Down/Rebuild/Shoot">
<cartnumber>MG1010</cartnumber>
<chip>MG1010</chip>
</hash>
<hash crc32="3f4b8c83" sha1="1f5bca6e96777ccbe830d1143a3549f51a3e386e" name="Pinball/Dungeon Hunt/Blockout">
<cartnumber>MG1011</cartnumber>
<chip>MG1011</chip>
</hash>
<hash crc32="7121f8b1" sha1="e7ae8571b496444ded77aaaa3c1d5f5ee97c651f" name="Boxing">
<cartnumber>MG1012</cartnumber>
<chip>MG1012</chip>
</hash>
<!--
<hash crc32="" sha1="" name="Space Destroyers">
<cartnumber>MG1013</cartnumber>
<chip></chip>
</hash>
-->
<!--
<hash crc32="" sha1="" name="">
<cartnumber></cartnumber>
<chip></chip>
</hash>
-->
</hashfile>

Just thinking loud now. Think this is issue MESS and MAME could benefit of each other. I am not aware about other hardware but guess there are more arcades like NeoGeo that use carts as well, as already mentioned on messdev and mamedev lists I am working on some more merging of code between MAME and MESS, think rewrite of image as MAME device could help in this. If we just use it for mounting any external images (like carts, floppies, cassettes, ...) we could use this one device to support "good" software collection lists. For MAME it could be used too, a various machines would be shown same as they are now, but on MESS we could display it in "software" tab we already have on ui, and also we could make a new selection screen after initial driver selection, on which we could select software (if we mark driver like that).

There are some old computers having quite small amount of software available, I know about few I only have some disk/cassette images, which I am trying to spread. So this could help specially some obscure systems.

Supporting carts if quite straigt forward, but think that supporting other things (like cassettes, floppies,...) should be think of more, since those are not autoloaded in all cases, so question is should we in those cases make driver itself type in load command or not (it should not be a big problem to add I think, specially if natural keyboard is supported).

For MESS I suggest making structure like:
- roms
driver1.zip
driver2.zip
- software
driver1\game1.zip
game2.zip
driver2\game1.zip
game2.zip


Will do my best to support this. First things first image.c to device.

Micko

yes, the hash files could be a good starting point. But it's too complicated and not easy to read.
I was more thinking of a simpler list. Again referring to MAME we use something like the GAME macro used in MAME where the 'columns' are known and the ROM loading format.

So for the hash file you listed it could be something like....
game ( archive_name )
Year, Manufacturer, Description
Filename, Memory_Load_Location CRC, SHA1
Filename, Memory_Load_Location CRC, SHA1
etc.
(/game)

i.e.
game ( catena )
"1981", "APF", "Catena (MG1001)"
"mg1001.bin", 0x00000000, CRC(5d03a812), SHA1(29db4ca3c8b76c413b84b6d2bfd3499a70eccd3d)
(/game)

and/or the same way MAME shows the game info screen when you load a game but incorporating the ROM loading macro too. But it's got to be simple, probably using macros so it remains readable.

The above is for auto-loading images/carts. For floppies/tapes you merely insert the image into the device and then you load it into the computer using the keyboard commands. The memory location is skipped by putting a zero there (I'm not a programmer so I don't know the correct convention?)

So perhaps for a C64 game floppy you would have.....

game ( rmc )
"1983", "Commodore", "Revenge Of The Mutant Camels"
"rmc.d64", 0, CRC(12345678), SHA1(1234567812345678123456781234567812345678)
(/game)

then you would have basic instructions like...

To list the files on the floppy type LOAD "$",8
then type LIST
To load the first file on the floppy and load it into the correct memory area type LOAD "*",8,1
To run it type RUN.
Additionally in some cases it will auto run instead if it auto loads at 0x8000 (i.e. 32768) -----from memory I think
To load a specific file on the floppy and load it into the correct memory area type LOAD "rmc",8,1
then type LIST to see the contents of the file (not always visible), or type RUN to execute the file (or SYS32768 or whatever SYS location the game runs from.. to always easy to know)

This will get most people not familiar with the system up and running hopefully.

You can probably tell I'm a C64 guy ;-)

for carts they will autoload since they are inserted before power-up. Just like real hardware. Floppies and tapes etc are usually inserted after power on. so we do the same. we just 'insert' it into the memory. it's up to the user to know what to type after that to make it load. But I had already suggested somewhere else that we should have a simple text file for each system that explains how to load something and run it as part of the distribution package. Already several people (even devs) have asked how to test some systems because they didn't know how to get the old school computer working. We can solve that with a basic instructional text file for each system.

Agree this is mostly not a problem on well known system. But there are some computers using quite strange commands to load, so maybe it would be enough to define texts per image type per driver, so for example for galaxy driver you would have:

"To load game type command OLD and then return key after driver startup"
Maybe even support additional messages per game, since some could have different loading methods. Like those used on computers having only monitor, there in most cases you had to enter after load some command to jump on specific location, which could be different per game.

Most of that information is already up on the wiki. It has been suggested before to compile that information back into the sysinfo.dat. Another option is to supply it as a set of html files with the distribution.

Can't we just reuse the already existing ROM_REGION macros for that? We just need to attach those to the drivers then, or create lists of rom regions.

If any of this happens I'll add a -nocargocult switch so those of us who don't believe MAME's success has anything to do with it's incorporation of a giant piracy database can work in peace.

And as far as who'd write new programs for obscure systems, meet plgDavid.

What, you mean you actually have ~500 Konami arcade games in your basement?
Piracy = Success. Napster and .torrents are proof of that.
Anyway, we're not including any software. Just like MAME we document it's existence, it's up to the public to collect it for us and store it for us so it can be found easily.
Just like MAME

I'm aware of plgDavid. But he's a crazed psychopath who wrote a hack to dump out the internal ROM. Regular people don't do that.

Regular people also don't own half a dozen EPROM readers, an SMT rework station, and a stack of socket adapters. We're all crazed psychopaths

I see that as a good point. You wouldn't have been able to work on Namco S10/11/12/22/SS22/S23/SS23 otherwise
Oh, I forgot to add, can I come over there one day and check out your ~200 Namco arcade machines collection too?

If it weren't for MAME and ROM dumpers there would be no classic arcade titles for XBox/PS2 etc. All of those used the ROMs from MAME. The Konami Classics Collection that runs on System 573 used old ROM dumps from before MAME existed, probably coming from the tant archive. The zips are on the CD and even include the dumper's notes....
So piracy is also profitable for the game companies when they regurgitate that stuff into a 'classic' release.

and this is exactly *WHY* MESS should start documenting this stuff. To ensure things are correctly labeled, and give incentive for things to be done properly. Most CPC stuff didn't even ship on disks, but tape->disk tools were common, sadly, as you point out, practically no original tapes are dumped.

Of course, with Computers and Consoles there would have to be a more active 'artwork' support project, many of the computer games used manual based protection, so it would be even more important that those get scanned etc. if the original images are used (people wanting to bypass it could just use the pirate versions, but there is always a risk of extra bugs there)

There are multiple angles to this, and it wouldn't be an overnight change (although the common systems could easily be batch converted over, as I did with HazeMD / TinyCDI, and fine-tuned later)

I still think improvements could be made to the way in which CHDs for CD based games are created, especially if MESS does start documenting the software; ideally you want offset-correct *reproducable* dumps, which is significantly extra work. Likewise, for disk-based systems you've really got to look in the direction of SPS for 'how to do things' Of course, for now you just have to support what's available, but I'd hate to see things become badly preserved because the dumping / inclusion guidelines for MESS weren't as rigorous as some of the other projects.

Cart based systems are easier because at the end of the day they're 100% digital data, you don't have to worry about them using physical properties as protection like you do with CDs + Disks.

But yes, Guru gives a good example, and a database of what's available, and how well it works can only help increase awareness, and thus aid development. Even with more common systems like the PC88 / X11 stuff Kale was looking at before are currently a nightmare to work with because nobody REALLY knows what's dumped, what's original, what's hacked, what's available, or how well it currently works, and as a result images get lost because they drop off the internet and people simply don't care.

You've only got to look at how difficult figuring out some of the gambling stuff in MAME is, and how many of the dumps just turn up on random FTPs with any dumping information already stripped out to see what happens if you just ignore things, and don't document them.

Multi-disk systems etc. or ones where you have to install the software (PC-based stuff) will again present their own challenges (I guess you could have default DOS / Windows 3.1 / Windows 95 installs which get mounted along-side the images to make things easier) Games which require you to have save disks... Hardware with endless configuration options will also be difficult (WinUAE has years of work dedicated to just that)

Anyway, yes, I can list various cases where such a system would be difficult to implement, but I think the fact that right now things are so inadequately documented, and preseved should be an over-ruling factor here. Likewise, accessibility, as suggested. The games and software are as good as dead if nobody knows how to actually load them, or the procedure is too difficult.

As I've said, console stuff will be easy, and would make a good starting point. I'd suggest something like the following

"MESS genesis ghouls"

it would also be nice if a software library could be associated with multiple systems, so that I could do

"MESS megadriv ghouls"
or
"MESS megadrivj ghouls"

or typing

"MESS megadriv -file homebrew.bin"

could load an external file, outside of the database.

maybe

"MESS genesis" could load a simple front-end like the MAME one with all the genesis stuff listed

or

"MESS ghouls" would tell you which systems the title 'ghouls' was available for.

of course, you'd have to be careful to make sure systems / software didn't have the same 8-letter name in that case

I think as a bare minimum MESS should have a -listxml and -romident functionality, that lists all the known software for each platform (including both computers consoles), even if it doesn't use it for a specific platform at this time, that would at the very least give people an actively maintained database to compare against, and identify any dumps they might have.

That would all be fine, if somebody actually implemented it in a way which worked. Personally it saddens me to think there won't really be any forward-movement in this direction, but all I can say is that I don't like what I'm seeing at the moment. I have a feeling it's going to take somebody splitting the project to get any of this done tho, and there are a lot of challenges involved, but the longer it's left the worse the situation is going to get.

Needless to say, while they're different projects, MAME wouldn't have got very far with the MESS philosophy. At least with Vs. Net I know that the only known dump of the gfx roms are bad now, and I can mark them as such, and I know it's not just me trying to fix problems with a bad set which was redumped 2 years ago without my knowledge. Kale still comes to me with megadrive emulation bugs which aren't bugs at all, simply because he's using MESS with unverified, bad, ROMs. HazeMD would have made it quite clear they weren't the expected sets. (of course, he also comes with some legitimate ones which I should fix :-)

I'd say if there is an existing format or method already there that can make additions easier and everyone agrees then why not use it. Or use that as a base and expand on it for MESS-specific extras (tape/floppy etc)
However MAME does support tapes (think DECO Cassette games) and floppies (think Sega System 24 games) so that is covered. I really don't see why MESS can't load a tape like MAME does or at least in a similar way. It's the same end result.
The only difference would be instead of autoloading it, the user must type a command to make the emulated computer load it. The MESS load part merely shoves it into some kind of temporary memory area that would be defined as a device like a floppy drive or tape drive. The emulated system would still load it slowly in real time, just like MAME does with (for example) DECO Cassette games. If it's not already done, MESS can add MAME's speed up method (pressing and holding the INSERT KEY) to speed up the loading. Or something.
In a real world the end user of the emulated system must suffer the same fate as the end user of a real system did 20+ years ago. That is, wait while the 1MHz system loaded it in PIO mode at 1 byte per second etc. hey, 30 million C64 users did it so they can't be wrong

Once I got the BIOS dumped I was able to develop my hardware test/analysis homebrew direclty inside eSCV, which allowed me to easily program my joystick/menu system, which would have been a pain to debug with EPROMs alone. Later I was then able to run that on the real thing in order to get more info on the sound internals. (still working on that, will publish what i learn of course)

So until a system is 100% accurately emulated, I would vote (i dont claim i have any voice at all though) to have homebrew available. I dont care if theres a warning saying that rom has not been tested, and frankly i think the idea is sound.

[edit] we all know that some recent demo writers keep finding new tricks on the old consoles/computers which push the boundaries of what we think is 100% emulation. Are 'we' in to 100% support known games or 100% emulate/document the hardware is the issue imho