Setting up currently requires a couple of steps to make a clean database and load (I intend to streamline this at some point):
The script uses minimaws.sqlite3 in the working directory as the name for its database unless you override it with the --database option. Loading the database may take a few minutes, but query performance is good. Note that you'll need to provide an actual path with a slash in it if MAME isn't in your PATH (exec treats names with no slashes as commands from somewhere in PATH).
Code: Select all
rm minimaws.sqlite3 sqlite3 minimaws.sqlite3 python minimaws.py load path/to/mame
There are a few query commands that work much like MAME's auxiliary verbs, but case sensitive and with better glob behaviour. You should be able to work them out. To run in web server mode, use the serve command:
By default it serves HTTP on TCP port 8080 (you can change the port with the --port option). The server is implemented as a WSGI application, so it could also be used in a WSGI container (e.g. Apache mod_wsgi), and it uses cacheable GET requests so it will work behind a caching proxy (e.g. Apache mod_proxy, nginx, or squid). You could theoretically turn most of the pages into static files too, but that would be unwieldy with tens of thousands of files in some directories. While I think I've made it resistant to directory traversal and SQL injection attacks, I open the database in read-only mode if Python 3.4 is available, and I've tried to avoid common sources of vulnerabilities, the code hasn't been audited and may not be completely secure. You probably shouldn't run it directly on a public web server.
Code: Select all
python minimaws.py serve
If you know the short name of a machine or driver, or you know the path to a source file with device/system definitions, you can jump straight to it with a URL (note that src/mame/drivers is elided in source file paths for historical reasons). You can also get a list of all source files with device/system definitions, although it's a large page and may perform poorly. Pages are interlinked pretty well - you can jump to any device used by a system/device, or any system that uses a device, or parents/clones systems. You can jump to any device defined in a source file, or the source file that defines a device. Example URLs you could start from include:
- http://localhost:8080/sourcefile/src/de ... 68kcpu.cpp
Although there aren't any in that example, unemulated/imperfect feature flags are shown for devices where applicable. Command-line flags for MAME to produce the selected configuration are shown, including elision of default choices. You can see it in action with any slotted system, for example:
The live slot selection is mostly done in lib/assets/machine.js with a bit of help from the web service. It works as follows:
- The only trick in the slot info web service (lib.wsgiserve.SlotsRpcHandler.data_page) is to filter out slots that come from default devices in other slots. This can be done lexically, there's nothing difficult about it.
- Once all the slot information has been gathered, the slot UI is populated (populate_slots).
- When a slot card is selected, any subslots are added to the UI (in the callback generated by make_slot_change_handler). This uses the same add_slot_items function that populate_slots uses to create the actual controls and apply defaults.
- When applying defaults, remember to walk from the topmost level inwards - defaults specified at a higher level take precedence.
- The command-line flag preview is updated in update_cmd_preview after any changes.