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.
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_.
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.
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.
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.
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 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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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.
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.
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).
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
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.
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.
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.
> 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.
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
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.
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.
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.