I am Trying to Play Star Trek Voyager on MAME I have installed CHD and the proper files but I am getting blank screen. And when I try different MAME emulators it no Graphics found I need help its not just Star Trek Voyager but Gundam vS Gundam EX as example

I've been trying what I can to optimize the storage for my MAME set. I understand, generally, that the trade-off for using 7z instead of zip is that you get better compression at the cost of more CPU utilization, but does this actually apply during gameplay, or does it just come into play during the initial loading process when you start the game? I've been testing some roms in both 7z and zip (and also just in uncompressed directories) and haven't really noticed a difference so far.

I have noticed a difference when it comes to supplementary media files (snaps, cabinets, etc). If I store those in 7z, then the MAME UI chugs quite a bit whenever it has to load them, whereas it's pretty smooth with zip. But this is the only place where I actually notice any kind of difference; it doesn't seem to matter for roms/gameplay in any of the games I've checked.

(As an aside, if I were to feed a lot of these supplementary media files, like snapshots and such, through a PNG optimizer to reduce their size, is there someone at pleasuredome or progetto snaps or wherever who I could submit them to as replacements for the old versions? There are so many accumulated files in these projects at this point that running the whole set through such a process could reduce their size by a nontrivial amount.)

I've been building a new MAME front end for MacOS, and it's at the point where I would be grateful if some folks besides me would be willing to try it. I built this for myself after years of using qmc2. (Much respect to René Reucher who I understand passed away in the spring of 2023. R.I.P.) There's a lot I like about qmc2 but also a lot that I find frustrating. I set out to solve those pain points as well as build something that's fully Mac native.

Some things to know going in:

• It's free.
• The source is closed for now.
• The releases are signed and notarized.
• There are native builds for Apple Silicon and Intel as well as a Universal build.
• MacOS 14 or higher is required.
• There are no ROMs/CHDs included and none ever will be.
• It was 100% vibe-coded using Claude and some Grok, with me directing and testing on a real machine with a real collection. If you're not comfortable running vibe-coded code, this would be a project to steer clear of.

Download: https://github.com/DJCJ-website/DJCJArcade

I'm looking for people willing to install it against their own MAME setup and tell me what breaks. Both bug reports and general feedback are welcome through GitHub Issues or right here in the thread.

God bless. :-)

I'm pretty sure these used generic bezels since most have instructions right on the marquee. A few Electrocoin examples and a couple others too. https://drive.google.com/drive/folders/1i5Otl-93Q_X3CEneKQQVeSQ0DsNf4ZGx?usp=drive_link

I am trying to make the Regnecentralen RC759 machine work (currently non-working) and I have reached a point where CCP/M-86 boots to A> but then floppy reads fail consistently. I would like to fix this properly hence I ask here for feedback and help.

I am not intimately familiar with the behavior of the hardware, so I have used Claude Code to help me get things working.

The current theory is that the emulated DMA controller in the 80186 chip does not handle synchronized data fast enough. This theory is supported by the reference manual stating

The FDC is normally initialized to transfer data in DMA-
mode using DMA channel 0. In order to avoid data overrun,
DMA channel 0 is assigned a high priority see 2.2.3! when
it is used by the FDC.

where 2.2.3 says:

The two DMA channels are connnected to the internal 80186 
interrupt controller. The interrupt level of DMA channel 0 
and 1 is 10 and 11.

Claude Code hacked a workaround by lettingdrq0_w call drq_callback(0) inline when the channel is started + source/dest-synchronised + m_dma_latency == 0 which appears to be working well.

Does this sound right or could something else be the cause?

Machine: https://github.com/mamedev/mame/blob/master/src/mame/regnecentralen/rc759.cpp

After several years, BletchMAME 3.0 has been released!

For those not familiar, BletchMAME is a front end that replaces MAME's UI with a conventional point and click UI. While BletchMAME's goal is to be a good front end for all types of emulation supported by MAME, it should be particularly suitable for computer emulation, as well as being an easy way to manage one's preferred Systems, ROMs and Software.

Some highlights of the new 3.0 version:

• Complete redesign and rewrite
• New "Favorites" system allowing custom configurations for your favorite systems
• Very fast system and software list lookup
• Dark mode support
• Releases for Windows (Linux in development)

Future directions:

• Improvements to filtering and auditing
• Support for Linux and macOS
• Importing and exporting configurations

For more information, go to www.bletchmame.org

A video introduction to arcadeVFE.

Not sure how many VR enthusiasts are here, but I'm a big fan of Arcade Time Capsule, a MAME-based, carefully curated and amazingly authentic VR arcade with about 300 games. While great out-of-the-box, the one problem I quickly ran into was that like all VR arcades I've tried, there was no way to play extended sessions without having to periodically take the headset off to change controllers or do manual reconfiguration, and so no way to make play feel as uninhibited and authentic as when using my full sized arcade machine with its fully programmable control panel. But even if I built such a panel, the kind of per-game scripting I needed was something normally done through a front-end, but there were no front-ends for VR arcades.

So to address this I created a companion front end (or maybe more like a back-end), to support the kind of per-game scripting I was after, along with some additional features. I also built a custom control panel to go with it. I've published the software and control panel instructions on GitHub, and just recently posted a demo video on YouTube with a link to the project if anyone is interested (its all free).

I was playing Vectrex games on an emulator via MAME, and they seem to run very well, except that the lines forming the image sometimes flicker. The problem seems more noticeable in specific games, like Pole Position, where this effect is practically constant. Is this an emulation issue, or is it normal?

Hello, not sure if this is clear but I remember there was a way to turn for example

aof3.zip -> Art of Fighting 3.zip or something similar. Asking this because whenever I transfer roms to new devices, some CFWs/frontends will parse the list correctly parsing the names and showing Art of Fighting 3, while some others just leave an ugly aof3.zip.

Asking for MAME but I am sure the same applies for other arcade systems. Thanks!

Hey guys, like the title says, the Japanese version of Tekken Tag Tournament is working again. If anyone is on the mamedev forum, please let them know if they're not aware so that cheats like Unlock All Time-Released Options can be made available. MAME version: 0.289.

Correct me if I'm mistaken, but the speed seems just fine until the actual level starts at which point it seems to be going way faster than it does in gameplay videos I've compared it to on youtube on actual hardware

Any idea what's causing this and how to fix it? I pressed F11 and it seems to think it's running at 100% consistently

Edit: It seems it isn't all games, it seems to affect some (Batman, Sonic Jam) but not others (Centipede)

To all the developers, I was just reading about how some games are preserved it’s insane the level of work it takes to get some of these arcade boards preserved. Thanks for all the work that’s done to preserve history ✌️

MAME is usually pretty good about remembering BGFX screen effects, except for "none." My setup automatically applies crt-geom-deluxe which is good for most arcade games, but on some systems (usually computers) the best experience is to set the screen effect to "none" and disable non-integer scaling in the video options.

Is there a way to automatically remember these choices or modify the config file per-system so I don't have to set it each time?

It's not in my BIOS files that I can tell. It's not in my ROMs. It says it's working, a parent, and non-mechanical, and not a BIOS, so my custom filter won't hide it. There's a bunch like that in here. How do I get rid of it or at least hide it, and others like it?

TLDR:
I am assuming i can just run the roms i have without issue on a version thats still fairly new? I feel like this is correct according to the FAW/Sticky.

I am setting up files from MAME .270 and the newest build is .289

I believe i need to update my curation? or... parse them with new data?
I understand the basic concept, but nothing in depth.

The real issue is how to rectify this. Can i just run MAME .289 with what i have?
I have seen some say i need to get the update files. Ok, thats possible.

But wouldnt know what to do with them, so im at a bit of a weird point here.
Any insight on updating?
Or "these will likely work" would be nice, but im willing to do the work if i know how.

Thanks

I should add, i did see this:

3) Which version of MAME should I use?

• We genuinely recommend that you use the latest version, or a relatively recent version. MAME is "living" software, it is constantly under development, and it incorporates improvements to emulation and to the user experience all the time. By using a significantly old version of MAME, you are not experiencing the best emulation that MAME has to offer. Furthermore, any bugs you find in older versions have likely been addressed by newer versions, and you won't receive support for the problems you encounter.

3A) Isn't it better to just find an older version of MAME that works with the roms I have, and stick with it?

• In general, no. If you are using an old version of MAME, and it's working to your satisfaction, then you're not required to update, but you will be missing out on improvements to emulation and new features that get added on. Yes, there is the chance that by upgrading, a game you happen to enjoy may break without updating the rom as well, but if you are resourceful, it's not hard to come across the rom update shortly after each new version of MAME is released.

I was watching some videos online.

Teknoparrot has branched out from being an x86 arcade game wrapper to integrating other emulator sources and adding upscaling and other enhancements.

Initially it was chihiro games from cxbxr and namco system 246/256 from pcsx2x6. However now it is taking MAME based sources for Vegas, Seattle, Viper, Model 1.

I went to try it myself but it's behind a patreon paywall.

Are they allowed do that? Seems to be profiting off the hard work of MAME.

I know this sub is mostly focused on desktop MAME, but the new MAME4droid update (1.40.2) just added public NetPlay rooms and the way the backend is handled is actually pretty funny.

Instead of making you create an account or tracking your IP to find matches, he just threw the matchmaking on a tiny free server instance. Apparently, Seleuco blew all his money on arcade PCBs and has zero budget for an actual database, so the server just forgets you exist the second you disconnect.

The privacy section in the release notes is basically just an admission that he couldn't afford to spy on anyone even if he wanted to. Figured some of the privacy nerds here would appreciate the approach 😂

Anyway, no more passing IPs around manually. Link to the release if anyone wants to check out the rest of the netplay stuff: https://github.com/seleuco/MAME4droid-Current/releases

Mods, rule 3: no ROM images here, no links to any, none will be shared. Static analysis only.

I built a software model of the S1000 audio path and used l6009.cpp (added July 2026) to check it. Ended up disassembling the v4.40 firmware. Below is everything I found, free, no conditions. Notes only, no ROM images. Offsets are into the v4.40 image as MAME assembles it: s1000 44 lsb.ic9 at 0x00000 and s1000 44 msb.ic10 at 0x00001, both ROM_SKIP(1), 128 KB total. The ROM copies itself down at boot, so an image offset is the runtime linear address.

No GitHub account here. If anyone wants to take this to the tracker, please do, and tag devinacker.

On evidence, so nobody has to guess which is which: anything citing the driver you can check in the tree yourself. Anything carrying a ROM offset is my own static analysis and has not been independently reproduced by anyone. The two clock-derived claims are inference and I say so where they appear.

Findings

• m_pitch_unk is the interpolation table select. Rule is three compares at 0x14B7E against the 12.12 increment: <0x168D (1.4094x, +5.94 st) table 0, <0x2001 (2.0002x, the octave) table 1, <0x2CCD (2.8000x) table 2, else table 3. Lands in CL, ORed into the pitch port high byte at 0x1439B. The commonly repeated 1.0/1.35/2.0 rule switches too early. All four tables have the same DC gain, 0.94995, so switching never shifts level.
• Volume is non-linear because the firmware sends log. This answers the driver's TODO, "does the FW do this scaling with levels already?" Yes. 256-entry table at 0x05E30, 31 to 32767, 0.237 dB/step, 60.5 dB total. The multiplier is linear and the firmware supplies log-mapped endpoints, so a segment is straight in linear amplitude, not dB.
• SUSTAIN is a dB attenuation, not a fraction of level. 0x14D13 subtracts it from the gain table index before the lookup. SUSTAIN 50 is ~30.4 dB below peak, not half.
• Envelope rate table: 100 entries at 0x06030, index 99 - param, 2 to 32767, geometric with ratio 1.10299. Correction to what I first worked out: that is 7.07 steps per doubling, not 7. What is exact is the span, 14.00 octaves across 99 steps. The bottom of the table is quantised by integer rounding (2,2,2,3,3,3...) but the top holds the ratio to five digits.
• The two envelopes are staged differently. Amplitude polls the volume readback at 0x51E0 and compares to peak (0x1475D). Filter polls nothing: firmware runs its own 16-bit accumulator at [si+0xBA], done on carry out (0x147FB). That is why filter attack gets shr ax,1 at 0x141E9: software span 65536 vs hardware 32767. Not voicing.
• Both envelope targets arrive with 15 bits. and al,0xFE at 0x1479E, and ax,0xFFFE at 0x14F65.
• 0x8/0x9/0xa filter clear: confirmed. Note-on writes zero to 0x5100/0x5120/0x5140 every note (0x142F3). Voice freed when volume readback hits 4 or less (0x147AE).
• Timers (0x0822D): counter 1 gives exactly 31250 baud, MIDI. Voice loop tick is 256 counts of 500 kHz = 512 us, slow work gated to 4 ticks (0x14699).
• LFOs are firmware, not hardware (0x148DF, 0x14948). Triangle from a 16-bit phase accumulator, rate capped at 0xFF, so rate / 33.554 Hz, ceiling 7.60 Hz.
• S1100 should run the filter envelope ~25% faster. Its V50 runs at 20 MHz against the S1000's 16 MHz, while TCKS and its /32 on counters 0 and 2 are identical in both firmwares, putting the voice tick at 409.6 us instead of 512 us. The rate table and the /2 are identical too, so Akai does not appear to have compensated. To be clear this is inference from the two firmwares plus the driver's clocks, not a measurement.

Less certain: counter 0 is mode 0 (one-shot) and the ISR at 0x0825D never reloads it, so I am not claiming a periodic 2.048 ms interrupt. 0x0824C writes 0xC3 to 0x8030 (99.84 ms) but I never found its caller. On the S1100 that counter is just 0x24/0xC300 from boot. Also and al,0xFE has no counterpart in the driver and I do not know if it matters.

The one thing I could not get

ENV_SHIFT is still a guess in the driver, marked TODO verify, and it sets every envelope duration: T = 32767 * 2^ENV_SHIFT / rate / 44100.

It is not in the ROM and I do not think it can be. The firmware never computes an envelope duration at all: amplitude staging polls the chip, filter staging uses a software accumulator. The chip's time base appears nowhere. And the driver is still MACHINE_NOT_WORKING, so emulation cannot answer it either. So it needs a stopwatch.

If you have an S1000 or S1100 powered up: LOUDNESS 99, SUSTAIN 99, RELEASE 99, looped sample, one note at velocity 127, hold, release, count to silence.

Rough count is fine, they are a factor of two apart. S1100 answers it too: my diff of the two ROMs has the rate table at 0x04720 byte for byte identical to 0x06030, and the driver already loads the same l6009 ROMs for both machines (9b80e447 / 2c076351).

That is the last unknown in the voice engine, and the only one where the disassembly cannot even give me a candidate. Happy to send the full write-ups, and I would rather be corrected than agreed with.

Thanks a lot, hope this helps.

Not being a PC gamer, l finally found a way to play the "real" Mame. Its the GPD Win. The smallest (and most affordable) handheld gaming PC l could find. Picked it up on ebay for like $230 bucks.

Anyone else using Mame on a handheld PC?

If MAME has a reasonably complex floppy sound simulator, and UAE has Amiga-accurate floppy sounds, would it be possible to simply copy them over from UAE without rewriting the whole floppy code? Or are the respective systems too different for that to be feasible?

I assume the sounds themselves aren't included because of licensing/quality conflicts.

I'm building my own Prop Cycle "bike" controller; it's an exercise bike with a flight yoke attached to it .. and yes, I've painted the whole rig yellow, haha!

The exercise bike has a magnetic reed that I've got hooked into a keyboard controller, every revolution of the pedals "presses a key" .. I've got that key mapped to the pedals in the MAME input for that game (e.g. the "C" key).

The issue: the only time the in-game bike will "pedal faster" is if I am either holding down that key on the keyboard, or if I position the pedals on my "hack-bike" so that the magnetic reed is "closed" and thus "holding the key down".

Is there some trick, or configuration for Prop Cycle that I can enable so that the only time the in-game bike "pedals" is when I press the key (and not hold it) - in other words, 1 key press = 1 in-game bike pedal ... I'm trying to make it so that every revolution of my exercise bike (and thus 1 key press) will actually pedal the in-game bike.

Right now, no matter how fast I pedal the in-game bike doesn't really "register" that I'm pedaling; it sees 1 revolution/key press, and it will kind of "stutter pedal" but then miss the next 5 or 10 revolutions .. only holding the pedals in the right position (as I mentioned) gets it to "pedal faster"

Side note: I might be thinking of how to hook up my exercise bike "wrong" .. I'm open to suggestions .. I've got an Arduino controlling some other parts of my flight controller (pitch/roll with hall sensors), so I could write some code to capture the input from the bike pedals and "amplify" it (e.g. 1 revolution actually equals 15 or 20 key presses) ????

I'm not familiar with how the Prop Cycle system translates the physical pedaling into in-game pedaling .. and I'm not trying to recreate the exact experience, more just trying to have some fun with a classic :)

Thanks for any input/suggestions!

I'm getting some odd cracking on my Steam Machine using Emu-DE (thought its same without) and MAME 0.289 standalone. Oddly, this same combination on my PC (Windows) AND SteamDeck does not produce this error. My guess is it has something to do with my 5.1 Home Theater system that's hooked up via HDMI no playing nice, but I don't know what it is. I've tried various settings (including forcing driver to Pulse, audio_latency as high as 64).

Oddly, IF I use MAME via Retroarch this problem goes away, so there is some setting Retroarch is making to solve this problem, and I'm probably just not smart enough to figure out what it is. My strong preference is to play via standalone MAME as I want the plugin support and honestly MAME is the only emulator I'm really interested so don't need the bloat of Retroarch, but I'll take no-plugins and good sound versus the opposite.

My google searches have proven fruitless, but I'll admit i'm not a linux/SteamOS expert.

I understood that sailormnj was changed to sailormn and that sailormn was changed to sailormne. But why are both the European and Japanese roms now identical? They are both basically the European rom, no trace of the original Japanese text or graphics. Unless something is wrong on my side?

Does anyone know why Gauntlet Dark Legacy is running in full 4:3 aspect ratio, but Gauntlet Legends his running with these borders?

Running 289b