> MAME 0.260

How large is a full ROM set these days, I wonder?

Looks like > 1tb

a full set for 0.258 is 1073gb (CHDs + ROMs + Extras):

https://archive.org/details/mame-chds-roms-extras-complete

It’s 2.5tb for the software archive alone.

But for games 1tb is roughly correct. Assuming no deduplication

What are ROMs vs. CHDs vs. extras?

It sounds ike CHDs are hard disk images -similar to vhd files? While ROMS is semi-obvious (game images or firmware), "extras" can probably mean just about anything ...

I've gathered that the ROMs are the firmware that runs on the "hardware" to create the computing platform inside the arcade machine or console, which was similar or the same across many games (essentially the computer inside the cabinet). Therefore it's separated out to prevent massive duplication. The CHDs are the game-specific material that ran on the platform to present a particular game.

Huge, if you include all the laserdisc games!

Compressed (and so sizes are approximate):

74GiB for the arcade ROMs

83GiB for the software ROMs (which used to be for MESS)

937GiB for the arcade hard disk images

2.6TiB for the software hard disk images

BitTorrent makes distribution less painful these days, since you can point your client at your existing roms folder and it won't bother to re-download things you already have. Only a small percentage of the set changes with each version.

What’s the difference between arcade ROMs and arcade hard disk images? Do these cover different games?

Yes, although some need both. ROMs are images of physical ROM chips. The hard disk images are called "CHDs" and are usually hard disk images but can also be laserdiscs.

I didn't know they used hard disks in arcade games... were those games implemented on some sort of embedded PC hardware?

Virtually all arcade games made since the 2000s (ish) run on standard PC hardware.

Maybe, but Konami "djmain" (first-gen Beatmania series) didn't. Neither did their "Twinkle" hardware (Beatmania IIDX series). Nor did their "Firebeat" hardware (Beatmania III series, Pop'n Music series, Keyboardmania series, Para Para Paradise series). Neither did their "GQ" board (Crypt Killers). Also, Taito's "Type Zero" board (9 games, look it up on System16). Oh, and Atari/Midway/Williams's Seattle, Vegas, Denver, Atlantis, Phoenix, and Flagstaff boards (SF Rush, SF Rush 2049, NFL Blitz, Gauntlet: Dark Legacy, Gauntlet: Legends, others). Incredible Technologies' "Eagle" board (Golden Tee Fore, Big Buck Hunter, Virtual Pool).

I have omitted quite a few.

Basically hdd arcade games are PCs or similar (occasionally customized console hardware) with HDDs attached.

Pretty much anything made post 2002 is that. It started a few years earlier tho.

Before that: custom roms (or at least some custom Roms on standard arcade platform hardware for that company)

Famously games like Dragon's Lair from the 90s require a CHD for all of the full motion video.

While MAME does support some Laserdisc-based games - Firefox, Us vs. Them, Mach 3, Cube Quest, and Time Traveler, along with a couple of others - Dragon's Lair is not among them. It's complicated.

Yeah, they’re originally laserdiscs so a bit of a special case, but same basic idea.

However it famously doesn’t support Dragons Lair! Not properly (it can play the video but that’s about it). Tho work has been ongoing.

Daphne is the only emulator of Dragons Lair I know of

CHD's also represent optical media, not just HDD's. For example the SEGA NAOMI arcade hardware was based on the Dreamcast. As such, GD-ROM was one medium for games. the GD-ROMs are dumped as CHD's.

CHD (compressed hunks of data) They represent a CD DVD or hard drive.

Now for most items in MAME you will need both some ROMs and CHDs. The ROMs usually in that case are the firmware of the device that loads up the CHD. The arcade platforms basically ended up being fairly beefy PCs or in some cases retooled game consoles.

At one point the ROMs for those devices were split out into their own torrent. They usually represent something like an playstation. With the CHDs being the CDs. It is also used in places like the Atari platform that runs some of its hardware that has basically different hard drives and some roms to switch out the board being the same between all the arcade games. It is also used for laserdisc games but those probably will change in the next few years as the doomsday project gets its preservation setup the way they want it. In the laserdisc game it would represent the console the arcade game used to load up the disc.

Many of the emus out there are adopting the CHD format for CD/DVD support.

Using bit torrent to do partial downloads is nice but it will not remove deleted or renamed files. Over the years, specially if you update each release, you will end up with lots of files that shouldn't be there. You can of course have some kind of script that checks file lists for each set and delete anything not in there.

I use qBittorrent, and all I have to do is tell it to "Move" the torrent after the download is complete.

It only moves files in the torrent, and leaves redundant stuff in the old directory.

I read the parent post to imply that there were ROMs or hacks distributed previously that are no longer distributed as part of the set because the hack is no longer needed.

I'm not sure how your "move" would resolve this if it was already copied in a previous release.

If you point the current torrent at the same rom directory, wait for it to finish, and then tell the client to move the downloaded files, it won't move anything that is no longer part of the current torrent.

Unless Im really missing something, it would have already been moved by the previous torrent?

Yes, into the directory you're moving the files from...

Torrent check is really what you want it will remove any no longer needed files. It can put them into a folder for safe keeping if you like.

The method here works as well. You basically run the new torrent over the old files (so you start half way done). Then move the data folder. In the old folder will be any files that are no longer part of the torrent. In the new folder will be only the files for the new torrent.

This is a nice solution.

Back in the days I used an awesome utility called TorrentCheck ( https://pleasuredome.miraheze.org/wiki/TorrentCheck ) developed by the Pleasuredome user "blackpudd".

I miss that community so much.

A lot of them moved to Discord, as perhaps you know. https://discord.gg/zQyAgSAd

(I don't like Discord, personally, but when a community moves en masse, there's not much you can do about it.)

I'm aware of that, thank you, but I don't like it either. The magic for me is lost.

Yeah the discord chats there are pretty dead. Usually only getting a bit of traffic once a month around release. The exo board is a LOT more active.

They should break it up by year. I've had it all downloaded and installed and working in several ways over the years, but I only really care about stuff released before, say, 2000.

Wow

I can kinda understand. I'm looking at MAME (again) because I'm seeing people here say it emulates synths and because I'm interested in some older systems it emulates that simh and qemu don't quite (eg SGI, though qemu may do that one now?).

So it would be nice to be able to pick by category (game,arcade,instrument,computer ...just a for instance) and by year (nothing after 2000, for instance).

I'm looking at the torrents but I don't know what I need to just have the complete arcade collection and the software to run it.

Right now I'm downloading the ROMs torrent, which does add up to 74 GB. But what else do I need for arcade emulation only? Thanks for any insight!

The "arcade hard disk images" torrent, too. Lots of arcade machines weren't purely based on ROM chips.

Thanks. I think I'm clear on it now. Looks like I gotta commit a full terabyte for the complete collection!

MAME supports Casio CZ-101? My favourite synth? I thought MAME is for arcade emulation.

Anyway, I need to try it, I love it'đ sound, I wonder how close it is to original.

MAME absorbed MESS and became a more generic multi-system emulator. It aims for 100% accuracy in emulation, even at the expense of speed, and so it is quite resource hungry for a lot of things.

I remember I have started using MESS (because I care more about computers than games) before the merge. One thing I notice in many drivers (the "plugboards" where various emulator parts are connected) is that they could, with some work, be compiled to some HDL.

Would be quite a thing.

Speaking of which, see also Bintracker. A Chiptune Audio Workstation that uses MAME as emulation backend.

https://bintracker.org/

Recently discussed on HN about 49 days ago. https://news.ycombinator.com/item?id=37377529

MAME stopped being "just arcade" long ago. It's basically an "emulate every hardware thing ever made" project :)

Even Tamagotchis, plus Casio assistants, even that one which was made for girls.

MAME can even emulate Nintendo Game & Watch!

They spent a lot of time getting the artwork correct too.

It can even emulate a Sonic the Hedgehog popcorn machine:

https://www.neogaf.com/threads/mame-can-now-succesfully-emul...

It also emulate home consoles. It’s got the best Sega Genesis emulator to my knowledge. Usually, emulators have issues with its sound hardware. But not MAME.

It’s usually got the “best” everything emulator. As long as by best you mean most accurate.

It may not be the fastest (usually never is) and may not be the most compatible (because it may not be complete vs hacks in other emulators) but what it does emulate is usually pretty close to perfect & will converge on that at least.

It’s Genesis emulator is a great example of that: about as perfect as non-hardware can get… but definitely not the fastest or most fancy

Nah, there is a whole cadre of emulators who have pushed emulation to the next step in the early 2010s, kind of spearheaded by Higan. They achieved cycle-accurate emulation of systems by eliminating the use of shortcuts. Behaviours are adequately reproduced, performance comes second. MAME has never held the crown of most acurate emulator, except in its field of expertise, the arcade.

MAME of course has gone in the same direction, but the project is known for its portability. So it means it has many emulation options to use less cycle accurate methods to run on RaspberryPi for example. From my limited experience, those far older emulators filled with performance-focused shortcuts are the default in MAME. So if you want the most acurate emulation, MAME isn't really it.

This is literally just wrong. Are you confusing MAME with RetroArch? Because that's a completely different project.

They definitely are thinking of RetroArch. It’s mame cores suuuuuck too! So it’s compounding their confusion it seems.

The rest of their post is about as accurate too

He's right, having been in the MAME source myself, it was designed as hardware documentation, not necessarily the most accurate emulator.

Just look at the source for most any 3d polygon rendering platform. Take the gaelco stuff or the Midway V platform. The CPU might be well emulated (enough), but the GPU is very frequently only simulated at the highest level. Someone might look at the displaylist generated by the CPU and pick out the vertex format, then they copy-paste a generic triangle rasterizer in its place and try to implement whatever features can be figured out. Attention is only paid to things such as interrupt timing and DMA timing, Fifo timing and so on only to the extent that is blocks operation or crashes the CPU.

This is not to dismiss the incredible work in MAME. It is frequently the first and only source of documentation at all. But parent is correct that it's common for more specialized emulators to go dig up more details and get more things correct than MAME.

Yeah, I confused MAME with retroArch. MOVE ALONG, NOTHING TO SEE.

You appear to be highly confused. None of what you said is accurate

That's not actually correct. MAME intends to be as accurate as possible (we emulate the actual microcontrollers running the actual firmware inside the keyboards for PC, AT, and PS/2 keyboards as one example) but it's not always there.

Sega Genesis is a poor example; MAME runs the entire commercially released library fine, but some homebrew stuff that seeks to stretch or break the hardware doesn't do well (notably the Titan demos).

On the other hand, MAME's 8-bit Apple II emulation is cycle-accurate and you can raster-split mid-scanline by counting cycles (as some people crazier than me have done). So it really depends on the specific driver.

You can't be serious. MAME's Genesis driver is far from perfect and most definitely less accurate than BlastEm.

mametesters.org/view_all_bug_page.php?filter=125692

BlastEm is great but—despite is vaunted accuracy claims—is buggy as hell too.

It plays more games but that’s not the same thing as accurate.

MAMEs emulation is incomplete, that’s why there are bugs.

Try playing Lightning Force aka Thunder Force IV — it’s famous for its heavy metal soundtrack. In Higan it does not work, in Genecyst the sound is crappy (on older emulators on Windows I also were out of luck). In MAME it runs just fine w/o tweaks. Haven’t tried BlastEm though.

I don't know where you're getting your info, because MAME is most certainly not the best Sega Genesis emulator. BlastEm and the up-and-coming Nuked-MD are currently the most accurate, while Genesis Plus GX is the most compatible.

I was surprised to learn it is the most capable emulator for SGI machines: https://sgi.neocities.org/

I guess the hardware is similar enough.

Apparently SGI emulation is very slow. I'm not familiar enough with MAME, so I wonder if this is expected performance for such a complex system in MAME or it can be significantly improved in the future.

I am running Mame as a SGI Indigo on a Pinebook Pro (an ARM based laptop) It is slow. But it a SGI Indigo on my $200 laptop. I was so thrilled to see that’s possible :-D

I'm super impressed that someone has emulated the CZ-101's sound generation LSI!

Lots of people use MAME as an emulator to help reverse-engineering vintage synthesisers. I only recently discovered this too. Since most 80s synths were built mostly out of 'off the shelf' components, it's not too difficult to build a MAME driver which is capable of running the synth's firmware. The actual sound generation is another story though.

I wrote a MAME driver for the Yamaha DX9 while working on this project: https://github.com/ajxs/yamaha_dx97

I wrote a little bit about the project here in case anyone is interested: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

Haha the pitch modulation noise sounds like LFSR white noise from an 8-bit console...

I wrote my own CZ-101-like synth (it's not an emulation, more like "based on", as it has some unique features), I've tried various CZ-like VSTs but nothing beats the original. So I'm really interested what MAME has to offer. Even if the synth is digital, its waveforms do not look like anything you would expect from some simple digital emulation, so emulating CZ properly isn't that easy as it would sound. Thanks for the links, I'm definitely going to check your DX9 emulation. As a proud owner of FB-01 I really dig that 4-op sound.

At some point, MAME combined with MESS (Multi Emulator Super System), so now MAME is just a multi purpose emulation framework & it doesn't focus solely on arcade emulation.

I wonder that I am only one enjoy with reading of changelog files. Hahaha.

For example: whith mame, for years ago I have the same bunch of favorite games (that run fine from years ago) but it is a party for me each new version of mame because there is new changelog.

About this, I have a old frontend for mame in python2 (and old pygame):

https://gitlab.com/tres-14159/pyretro

More or less in 2011 we made a arcade cabinet for a public social center and I was looking for a frontend for mame for public spaces (not home or private spaces), unsupervised. I did not find one. Well I thought "I am going make a new mame frontend" and yes, I made it (but now it need a lot of work for update to python3 an pygame3).

PyRetro has the next features:

- the users can not the config of frontend by the joystick or buttons. For example, in others frontends a naughty boys (or adult person) can delete games of the list or change something.

- you can manage the frontend (and other things of GNU/Linux) by webpanel. For example, there is a bad boy (or adult person) greedy playing and he does not let another person play to the arcade. You can force exit the game and return to frontend or restart all cabinet.

- it has as screensaver mode when nobody plays it.

Firstly, kudos for the project.

If I may ask, as python3 came out in 2008, why did you choose python2 for the frontend in 2011?

python3 in 2008 was practically unusable. It was incompatible, none of the libraries on pypi supported it; and it was extremely hard to write a code base that was compatible with both python2.6 and python3.0 at the same time, so almost none of the library authors bothered to add python3 support.

In 2010, python2.7 was released, backporting a bunch of python3 features. In 2012, python3.3 was released, fixing a bunch of needless incompatibilities. This finally made it viable to support both 2.7 and 3.3 in the same code base. For the most part, the migration of the Python library ecosystem only started in/after 2012.

python3 wasn't really a viable choice for application development until most libraries were ported (2014? 2015?).

I think a lot of people forget this long, slow rollout. Even after most major libraries were ported, it took even longer to be able to count on every dependency having a Python 3 version available. RHEL didn't default to Python 3 until RHEL8 was released in 2019, for example.

It's hard for me to forget just from how much bullying and grief people were given for why they hadn't switched to Python 3 yet. Some of the steps that people took were wildly uncharitable and behavior that turned me off to the Python community entirely.

So much so that I had a visceral reaction to reading the GP's question about why this hadn't been done. My default reaction was to read it as accusatory rather than a genuine question.

Still running some containerized 2.6 and 2.7 workloads and there are no engineering dollars to justify doing anything about it. Dead code can still be running code and can hang around for _decades_.

Due to Reasons, I am still stuck on Python 2.7. Should be an interesting jump.

I didn't start using Python 3 till 3.6 was released, so not until 2017. I've been writing Python since 1.5.2. I just didn't find Python 3 compelling/usable till 3.6. I recall f-strings being a really nice ergonomic improvement.

I always appreciated them for calling it Python 3000[1] at its inception to signal to users that it was going to be very different and take a long time to fully land.

It is a great example of how to do it, and I say that as somebody who used to write a lot of Perl 5 and kept wondering when Perl 6 was going to be available.

[1]: https://peps.python.org/pep-3000/

It took a long time for projects to begin using Python 3 due to it being backwards incompatible. Django 1.5 for example, the first version that had Python 3 support, came out in 2013.

Is the versioning scheme only in .001 increments? I know version numbers aren't indicative of progress, but I still find it fascinating that a 26 year old project is just releasing 0.260

Yes. Although some numbers were skipped. 0.32, and 0.38 through 0.52 don't exist.

ah yes they skipped because there were a ton of releases from .38 to .52 that where basically .39 v6 (fixes something). So they figured out how many then added it.

Their idea is that v1 is when all machines they support are perfectly emulated.

So… it’s asymptoticly approaching v1 you could say.

Of course they keep adding more machines… so…

Yep. In fact, the first releases of MAME had 0.01 increments. Not sure when they went to finer steps, but it is pretty much a given that they'll do it again when the current revision gets too close to 1.

Version numbers don't work like that :)

MAME just has a permanent "0" major version, and the minor version continues to be bumped up forever. It's not a decimal number, so "close to 1" doesn't really make any sense.

Ehhhh… while there’s no particular decimal cut off, “closer to 1” is always going to be a higher minor version.

It’s not incorrect as such

I remember the good old times when I could compile mame with a simple C compiler...

Huh, it doesn't compile with GCC anymore? That's weird, as someone contributing for the past 20 years, I could swear I just compiled it yesterday with GCC.

simple C compiler, not gcc and its languages.

Did you try to compile mame with cproc/qbe, simple-cc/qbe or even tcc?

only 74 years left before MAME 1.0 releases with the current versioning

Who says 0.999 won't be followed by 0.1000?

Is there a modern name fronted for Linux?

Even after all these years I still get back to my territory outdated version of mame32++ wine.

It's not a perfect setup but the alternatives, that I am aware of, suck even more.

It comes with a mostly text but technically graphical ROM selector. It's not the most pretty, but it is quite functional. Given the size of the project it is almost inevitable that the interface feels like a database front end.

It's only been an year since I've tried it. There have been massive improvements over the years but I still prefer dealing with the above setup.

They do have autofire, saves, art, snapshots, etc. but I got tired of having to configure my joypad cfg after every restart. Maybe time to give it another try

could someone explain to me why the ROM set changes with every release? it makes me think the developer is an idiot.

Sure: They don't, and the people who imply that they do are the idiots.

A full set of ROMsets consists of tens of thousands of archives, each containing a set of files where one file holds the contents of one programmable device: a ROM chip, a GAL/PAL, a microcontroller with internal firmware, and others.

99.9% of these individual sets do not change from version to version.

When a given set does change, it's because a previously incorrectly-dumped chip's data has been replaced by a newer - correct - dump, or a chip that was never dumped previously has now been dumped, or (rarely) the set was renamed.

What you're probably doing is finding full-set torrents per version, posted by some independent group, and assuming that that somehow means that every one of tens of thousands of individual sets within that larger set has changed.

So, hopefully this clarifies which individual is an idiot here.

Just to state the obvious, in addition to correcting old rom sets every MAME release also adds new rom sets for newly supported games (either variations of known games like hacks, prototypes, foreign versions, special editions or completely new work). Typically, there are enough changes to actually disrupt a very large portion of the segments of any full set torrent.

> As requested by users, you can finally use delta CHD files for clone systems and software items. This allows for major disk space savings in some cases when you have multiple versions of a system or software item.

FWIW, this is commit https://github.com/mamedev/mame/commit/d1172bf710f2a7b1777ed...