I've been working on a new front end for MAME, called BletchMAME. Unlike existing front ends, which are more "launchers" than "front ends", BletchMAME replaces the MAME internal UI.
For more info, read here:http://bletchmame.s3-website-us-east-1.amazonaws.com/
Love the concept, the internal UI always seemed a lot clunkier to use to me than MESSUI. Initial impressions:
- Options->Images seems unintuitive as the place where you have to go to actually load a disk/cartridge/etc. Maybe something like File->Load Software
- Image slot names are not very user-friendly, e.g. nes_slot, sl6:diskiing:0:525. There are descriptive names for these devices if you grep the source for DEFINE_DEVICE_TYPE so it's a matter of plumbing that out I guess.
- I wasn't able to boot a disk on apple2e, it starts up without a disk by default, then I select a disk and do a hard reset and it seems frozen
- It wasn't obvious to me that File->Stop is how you get back to the driver picker, maybe something like File->Change Systems or File->Return to System List
- Will definitely need more video settings to be a viable competitor to standalone emulators - e.g. full screen, fit to desktop, 1x/2x/3x size (I realize this is hard to do with layouts and correct aspect ratio). Resizing the window to any size is OK but it should at least lock the window aspect ratio to match what is actually being displayed inside, otherwise it's cumbersome to size it exactly right without having any black border.
Yes I agree. My focus has been on "the basics" - getting something like this working at all, before (for example) feeding human readable names from the core.
I'm also in the process of reimplementing some of the hooks into MAME as a LUA plug in, so any functionality exposed via LUA could be accessed by my front end.
This is very nice. Great!
But why Wxwidgets and not Qt?
It's not that I am a fan of Qt but as it is already used for debugger...Will MAME depend on both?
You're not the first person to ask that question.
I suppose that I just tried wxWidgets, liked it, and didn't spend a great deal of time weighing the decision. There is a possibility that had I evaluated both thoroughly, I may have made a different decision. All that said, the BletchMAME is a distinct application under <9k lines of code. If I wanted to switch to Qt, it wouldn't be difficult.
From where I'm sitting, once everything's merged into mainline in a satisfactory way, let a thousand frontends bloom.
So, if I understand correctly, BletchMAME does not replaces the MAME internal UI.
I mean that it will not be merged into MAME but it always will be a distinct application. Is not?
The idea is that it adds hooks which allow external frontends to interact with MAME's internals live, and therefore replace MAME's internal UI (but we'll still have that UI as an option because it does have its fans). BletchMAME itself shows one way those frontends can go, in a VICE-like direction.
Ah, that is even better!
Thanks for replies.
What RB said - I'm personally eager for having a VICE-like experience, but the real value comes from the next thousand front ends :-)
I've been making more progress with BletchMAME, not so much on the UX of the app itself but rather working with Mamedev to get the required hooks in MAME. I've actually implemented much of my hooks as a LUA plugin.
On Windows, BletchMAME is now distributed as an MSI, and in addition to installing BletchMAME itself it also installs the LUA plugins. The default configuration of BletchMAME instructs MAME to use both MAME's plugins directory as well as BletchMAME, facilitating the integration.
Long story short, we're making progress, but on the boring (and hard) stuff. I hope to pivot to more end user related functionality when I can get things working with off the shelf MAME.
The MSI doesn't seem to work - I go to Custom and select a directory but nothing gets installed there. WinRAR reports that the archive is corrupt.
Hah, spent a good part of the day just getting WiX working under Travis-CI and didn’t check that part of the custom install.
Could it be doing something stupid, like always installing to C:\Program Files\BletchMAME?
Could it be doing something stupid, like always installing to C:\Program Files\BletchMAME?
Yep, that's what it was.
It also forces you to agree to the GPL as a EULA which is silly....
It also forces you to agree to the GPL as a EULA which is silly....
No it isn't. GPL requires you to accept the absence of guarantees and agree that if you redistribute binaries (modified or otherwise) you'll provide an offer of matching source along with the binaries. Lots of software makes you agree to GPL when you install it.
VLC is probably the most common software to make you agree to GPL in the installer.
But it is not required. From GPL FAQ
Can software installers ask people to click to agree to the GPL? If I get some software under the GPL, do I have to agree to anything? (#ClickThrough)
Some software packaging systems have a place which requires you to click through or otherwise indicate assent to the terms of the GPL. This is neither required nor forbidden. With or without a click through, the GPL's rules remain the same.
Merely agreeing to the GPL doesn't place any obligations on you. You are not required to agree to anything to merely use software which is licensed under the GPL. You only have obligations if you modify or distribute the software. If it really bothers you to click through the GPL, nothing stops you from hacking the GPLed software to bypass this.
Yeah, it's also not forbidden.
@Bletch, I think your frontend is a great idea. What would really help me in the way I use MAME is a provision for showing the comment parts of disk image formats that have them (.TD0 and .IMD come to mind) in the dialog box to select them.
Yes that seems like a good idea; a number of other emulators do similar things. I actually really groaned when I saw the image file dialog for the first time, but (for the time being of course) resigned myself to the fact that I was exposing everything possible in core MAME.
I suspect that in practice such a feature would have to be built for MAME’s normal UI, and then exposed through hooks.
I admit I'm one of the softlist agnostics - I use the emulated CP/M, DOS or whatever machine like I would use the real thing - floppy disks (or images thereof) more or less organised, cramming them into the drives ...
It is difficult to ignore that Softlists are essentially a MAME only phenomenon; other popular computer/console emulators don’t have them. And BletchMAME is an attempt to provide a more conventional front end.
And expect that to prompt more chatter than the question about whether it is appropriate to present the GNU GPL as a click through license agreement...
Don't want to spam your thread ...
I get the situation on the console side (although I don't know the systems as such), where you can load a ROM only if the emulator knows about the correct supporting environment that comes with the cartridge to make it work.
For PCs there is definitely a need for a "curated list" or such. Take the Amstrad 1512 and 1640 that came with a set of four or five disks, or systems that need their setup disks due to a lack of a built-in setup. I think these should be identifiable/loadable in an unadulterated form. Maybe some four digit CRC that doesn't take a lot of screen estate and is human readable?
Please understand tho that with MAME the Software Lists are the recommended way for running things.
A lot of Software, especially for the consoles, WILL NOT WORK PROPERLY if you use the loose ROM loading, as it relies on the Software Lists to specify the extra hardware in the cartridges (especially custom mappers, NVRAM etc. things that we don't want to have to add a ton of ugly hack code to detect from the ROM data alone) This isn't so much a problem for tape / disk based media, but for cartridges it is important.
Non-softlist use also encourages poor dumping practices (single ROM file for multiple chips etc.) with no incentive for people to do things properly.
Furthermore, loose ROMs encourage people to keep bad dumps around, with no incentive to replace them as the software still runs them and won't report any issue with the dump (the emulation problems as a result of these bad dumps may not be obvious, this has been a problem in the console scene for years and would have been for arcade emulation had we not gone with our own database from day 1. Even when redumps have been around for years in the console scene people keep using the old bad dumps they already have, sometimes the good dumps actually fall out of circulation as a result because the emulators aren't making people aware they should replace their bad ones)
We've been heavily dissuading people from using the loose ROM loading for these reasons (to the point where I'd really like to see it locked out by default for systems with mature lists unless some 'development mode' switch is flipped in the ini file)
Softlists are a "MAME only phenomenon" because part of what MAME does is recognize where the existing scene is failing and attempts to do something about it by pushing people in the right direction to ensure a better future for everybody, even if it seems less convenient in the short term.
If your 'BletchMAME' is encouraging users to ignore Softlists, that is a problem, and is damaging to the core project and the user experience. If you champion a path of least resistance, people will take it, this is not beneficial in this situation.
Software lists are valuable for cartridge systems for the reasons Haze describes (but I'd rather improve the loose file loading than make it go away; loose files are going to be people's first attempt at trying MAME, and the fact that they don't always work has caused a lot of people to switch to RetroArch or other alternatives). They're a less-good fit for floppy disks and tapes, and can sometimes get in the way of actually using the emulated computer as a computer (they're great for the case where you just want to play games, of course).
BletchMAME should support both methods or else I'll start pulling all his hooks out of top-of-tree.
Well unless we add a reverse 'look up loose file in softlist, attempt to work out proper softlist entry' type logic it's always going to come down to really ugly hack code (that sometimes the ROMs intentionally cause to fail to fool copiers etc.) and even that kind of reverse lookup is unreliable.
and even if we add that logic, it becomes problematic as soon as you're dealing with merged roms instead of split roms or cases where the loose ROMs are byteswapped vs. the proper dumps. You start to have to check a ridiculous number of possibilities.
MAME has always favoured trying to offer cleaner code, not code full of detection hacks.
Unfortunately the scene is 'broken' in the sense they'd rather keep bad stuff because it's convenient, and do things the wrong way because it's convenient, leave the burden on the developers to have a sky high pile of hack code, exclusions with built in patches to compensate for bad roms etc, because it's convenient (for end users)... MAME has to try and encourage more positive models I think, it's what separates us in a good way even if we do get hate for it. I'm not sure sinking to the same lows is positive, even if it's more what people expect.
The scene is what it is, and we have to play along or become irrelevant. This is mostly just about NES anyway, and NES loose file parsing is a long-solved problem in e.g. NEStopia and many others.
Otherwise we'll have to re-detach MESS on the grounds nobody's using it and make a lot of the wrong people way too happy.
Never fear BletchMAME will be supporting software lists, and I would agree that they are the way to preserve these myriad console and computer software in the same way we are preserving arcade systems.
That said, the softlist approach is a bit more alien for the computer emulation world, much of which is probably not in “the” scene (or rather the “emu scene”) that wants unimpeded use of the dumps they personally made (that might be “bad” because they have the saved games they made as a twelve year old), and that will be taken into account.
I think software lists for computers will be more accepted for computers that have organized high-quality dumping projects going on, like has been happening with the Apple II. I'm just not sure how many of those are going to happen.
Last I recall, the “official” Oregon Trail Apple II softlist image had “here lies andy; peperony and cheese”.
Is that finally not the case?
I don't know if Oregon Trail specifically has been redumped, but if it is that won't be the case.
ETA: looks like mcorgtrl from the Clean Cracks list should be virgin.
Yes, we have a clean Oregon Trail dump finally, which makes ME very very happy. That's one of the things that's been missing for a very very long time.
Nice work so far on BletchMAME!
You know one thing that would be great for BletchMAME, is a machine 'profile(s)'. - These are 'recommended' working profiles for a particular machine to work 'out of the box'.
In theory, you can get realtime feedback from MAME and have this properly integrated in the UI. Rather than currently -> if you try and setup a machine you can easily get 'an error' and MAME just closes.
For example; right now if I wanted to run a 486 setup ready to go with the latest/best MAME is able to do, simply running the .exe would give no information, help, nothing. So I would need to hunt around random forums and 'tutorials' and guess my way though setting this up. (-ramsize 16M -hard1 somefile.chd, sound ? video? what else?)
So, with BletchMAME, for example, you could easily have a simple panel that says 'IBM PC 486', its interface would tick items that you might have and or something MAME can setup, ie bios rom and floppy drive and but then easily require other user input for needing a HDD, if no image is selected it will make one. It could have all the best hardware available otherwise ready. It could also link to a mini wiki with screen grabs and instructions to get it working.
CPU - 486
RAM - 16 Meg
VIDEO - (Best video card MAME can currently do)
SOUND - (for PCM, ie Sound Blaster 16)
MIDI (for music in games to sound great, ie MT32 or something etc)
HDD (make a blank one if needed or map to one easily)
So all these things are setup and visible by the UI - from the 'profile'. - It would hilite for example if something is missing, ie if the HDD is non existent, it will use chdman to 'make one'. Perhaps later, it can have a folder mapped like dosbox does.
Also things like MIDI, it can map to what ever is best in MAME currently OR even the OS directly, ie windows midi port so I can run my own soft synth.
For floppy(s) you can map to any old disk image from the softlist and/or a real floppy on the host OS or even a 'hot' folder. But not all clunky as it is now.
Profiles could be really cool in this case; Imagine right now, if someone trying to run an AMIGA that is working or 'pretty much' in MAME but has no or little info on what MAME has or is capable of, or are not sure of what is best or even what is actually available.. they would have a classic setup that is ready to go.
I do want to improve the experience of "machine setup" - it should be as easy to set up a hard drive for MAME as it is for say, VirtualBox. To me, part of the challenge would be maintenance of the profiles themselves. For instance, it makes sense to prompt people to create a hard drive for the PC driver, but that probably should not be the default for systems like the Apple II, where hard drives were an esoteric luxury.
I will say that I will happily adjust my immediate term development plans given the possibility of engaged help in the process :-)
I believe UAE has this concept; it even IIRC allows user-defined profiles.
And hard disks weren't as esoteric on the Apple II as you think, even back in the day. (Of course, they're pretty much universal now in both emulators and hardware).
Thanks for the info. I suppose UAE is going to have to join MAMEUI, MESS NewUI, VICE and VirtualBox in my list of (for lack of a better term) "sources"
An update - BletchMAME has a menu item for toggling Full Screen Display
nerd4gw, one of the things that I realized is that the hard drive setup story for MAME is utterly terrible. I was poking around and found out that there is not a good way to set up a hard drive from within the MAME UI at all. This is despite the fact that under the hood, the CHD code does support image creation and it is just a question of wiring up the right data to the UI.
I'm curious how you (and others) set up hard drives for MAME. I tried creating a fresh CHD and trying to run it with 'macse', but it didn't get recognized.
There are ready-to-boot hard disk images for the Mac in the software list for around a dozen System versions. Otherwise you have to boot a floppy, partition, format, and install, which is kind of a slog.
Yeah I was using those, but if my goal is to build a UX for creating a completely new HD from scratch, they do not help.
Wasn’t Apple SCHD Setup distributed with their system software?
Maybe go for PC or something less demanding? You can't format in the Mac driver right now, the old SCSI is too inaccurate and I can't use the new one without a cycle-by-cycle 68k.
I suspected Mac might be easier because I suspected (not necessarily with a basis of education) that it might have been better able to handle "hot" swaps. I honestly don't know what happens in DOS if you all of a sudden, mount a SCSI hard drive.
Yeup Bletch, I used a pre-setup HDD for the mac also
. I sometimes get lazy because it seems all too hard lol. Which is a shame!
Creating a blank HDD should be simpler for sure and many machines have various quirks, size, setups etc. Also from what R. Belmost said, it might not be the HDD creation itself, but some sort of specific way it needs to be 'installed' so the HDD image might even be ok etc. Hence the user/premade profile idea, but I wonder if you can get mame to extract info also from the driver?
Even more handy would be a way that bletch can read what exactly is wrong/missing with a machine, at least some sort of info. 'ie timing no 100%, sound problems, and even some other details which people would find intereseting', rather than just 'not working' .
But anyway! most machines are going to have the basics like a floppy drive, ram, hdd.. so even hooking these up easily would be handy. - oh yeah, 'swapping' disks/cd's should be much easier too.
There are fine-grained "what's wrong" controls but at this point the Mac drivers are sufficiently farked that I think NOT_WORKING is justified.
I took a look at UAE and at first glance, it reminds me very much of VirtualBox and similar virtual machine setups. Very heavyweight, fine grained configuration, lots of bells and whistles.
I'm struggling to figure out how to create a user experience that combines that approach with the MAMEUI "machine picker" approach without compromising the advantages of both sides. You wouldn't want someone browsing dozens of random arcade games to have to set up a profile for some random Pac Man clone.
Perhaps there should be a tabbed view, one tab being "Machines" and the other being "Profiles"? Right clicking on a machine could have a menu item for "Create Profile From Machine", with richer configuration? BletchMAME could even ensure that images and perhaps even saved state persist across sessions?
I guess my ultimate vision for something like MAME is closer to that tho.
Everything in MAME would be a basic 'template' that you could add to your 'collection' (a profile) and even have multiple copies of with different configurations etc.
an MS Pacman machine would be one thing
a Floppy disk would be another thing
you could even own multiple copies of the same base game cart and choose which one to insert (so that each maintains its own nvram status)
if we're going to have named virtual environments where you can add / remove machines at will and form links between them then such becomes neccessary.
of course, the basic operation could hide that in a lot of cases (eg 'mame pacman' on the commandline could automatically create an environment called pacman, add the machine known as 'pacman' from the machine templates, and basically act exactly as it does now unless you start actively adding / removing other machines from that named environment)
there is always going to be a difficult step between professional, serious software, which is the direction in which MAME is heading, and gimmicky toy software, which is the direction things like RA are trying to pull the scene. Some of the complexity can be hidden by default in some use cases, but it still needs to be there, not locked out as you get with RA.
It has also occurred to me that what I was calling a "profile" is almost what one could call a "session".
I might want to spin up a profile/session (perhaps directly from the machine list or even duplicated from an existing profile), whether it be for that long game of MULE or something else, and if save states are supported, exiting the emulation would persist the save state automatically. When I am done with that profile/session, I would then delete it. This does not preclude more permanent profiles.
I know nothing about RetroArch, but I strongly suspect it is targeted at a different type of user.
Ok, I've gotten a version of BletchMAME rushed out with very crude support for profiles.
The main view is now tabbed, with a Machine List being one tab and a Profile List being another tab. When BletchMAME starts up, it will look through Profile directories (specifiable on the "Paths") menu, looking for XML files that match "*.bletchmameprofile"
Here is an example of profile XML:
<image tag="ext:fdcv11:wd17xx:0:qd" path="D:\OneOfMyOldDiskFiles.dsk"/>
Right now, these profiles do nothing other than specify images that are loaded on startup, but I envision in the future, we could have the following:
- When emulations end, the profiles get updated with the new image list
- Save states specific to the profiles loaded on emulation start and completion
- The ability to right click on a machine a "fresh" profile for that machine
- Administrivia (e.g. - delete, rename etc)
Of course, this is extremely prelimary. Some of the basic stuff (e.g. - persisting column widths on the profile view) are not implemented, but what interests me is getting this in front of people.
I'm making progress on profiles, though the feature is not ready for prime time.
I got the basic "administrivia" of profiles working (e.g. - create, rename, delete), and the basics of a profile tab. You can launch an emulation session from a profile, and the profile has images associated with it, it will run the emulation with those images. What I do not have implemented yet is:
* Reflecting image mount/unmount back onto the profile
* Save state support (e.g. - save states associated with the profile that kick on on startup and shutdown)
* Other bells and whistles (.e.g - configuration of things other than mounted images)
Well I got a bit further:
- Image loads are now reflected back onto profiles
- Save states are now persisted with profiles. Currently this is always on and there isn't a way to control it, but overall this proves out the idea.
So, BletchMAME profiles are now in a state with some semblance of usability. I suppose my next tasks are to kick the tires for a while.