A few questions about MiSTer FPGA's capabilities

[IAmDotorg]

I'm probably not alone in learning about this project as a result of the Verge article last week. I may be a little less common in that I already had a DE10 setup I was using for another project. That had been back-burnered for a while, so I thought it was pretty interesting to check out MiSTer, since I had (at least for the simple cores that didn't need a RAM board) everything I needed.

Having played around with it, I started debating buying a second DE10 (and likely supporting hardware) to replace the fairly old MAME/MESS setup in an arcade cabinet I built seven or eight years ago. Although losing a cabinet-friendly UI isn't ideal (and I've read and understand the heated debates over the MiSTer UI and have no intention of whipping that back up again), the upsides of severely reducing jitter and eliminating an OS I need to maintain are super compelling.

That said, there's a few things, after doing a bunch of research last week, I think it can't do that I really probably need it to do. Before I burn a bunch of time trying to set it up in the cabinet, I figured I'd confirm my research is correct on these...

- There's no equivalent of MRA files for consoles? (So you can direct launch a console core with a cartridge/disk/whatever already enabled?)
- There's no eventing interface on the Linux side to be notified when a core change has happened and what core was loaded?
- There's no output device support on the arcade cores? (i.e., the equivalent of MAME outputs, so there's no way to connect the cores to physical hardware in the cabinet?)
- There's no management interface exposed in the FPGA to control the MiSTer manager code running on the ARM CPU? (Meaning, the OSD that comes up to load new cores is coming from the ARM code, via an SPI interface to the OSD component in the video pipeline, not being generated from within the FPGA? Basically, there's no way to trigger a core load from within a core?

For a basic cab, it seems very feasible, but the cabinet I've got uses RGB lighting for both control illumination (so the system needs to know what core is active, at a minimum, and highlighted when browsing ideally), and a lot of games run the button illumination "properly" (meaning special weapon buttons flash, P1/P2 start may flash depending on credits, etc)

All of my research seems to suggest there's not enough hooks to build those kind of integrations, currently? For some of it, I could add logic to the core to handle it -- it'd be pretty trivial to add a simple I2C onto a GPIO pin to announce the running core to an external microcontroller, which could reconfigure the RGB buttons, but I still wouldn't have game-specific outputs. And without an MRA equivalent for consoles, there's no way to list and launch directly into console games? (About half the gameplay on the cab tends to be NES/SNES games...)

Have I missed anything? Thanks!

[grizzly]

1, There's no equivalent of MRA files for consoles? (So you can direct launch a console core with a cartridge/disk/whatever already enabled?
2, Have I missed anything? Thanks!

I answer with what i know about which may be more or less nothing
1, Mostly no but some systems can have a rom file renamed and/or moved to a "special folder".
For example C-64 can have a boot3.rom in the Games folder and it will autoload that.
I have a Final Catridge III cart rom file named boot3.rom so that will autoload, i can not remember if other "files" worked too like .d64/t64 but other .crt files should work.

2, Probably lots! (yes i know veeeeeeeeeeerrrrryyy helpful right? )

[zorrobandito]

You might be better with a MISTerCADE which has the JAMMA pinouts built in. That would give you the physical cabinet connection you're looking for.

[zakk4223]

Main_Mister writes the core name to /tmp/CORENAME when it loads a new core. Arcade games loaded via an MRA will write the 'setname' attribute in the MRA if it exists. (So basically the rom name for almost every arcade core).

There's no easy way to tell what rom is running in console cores, nor an easy way to load a core+rom (you can kind of fake it by copying things into /media/fat/bootroms, but that's just clunky). I know it sounds like an obvious/trivial thing to have but it gets a bit complicated when some of the computer systems are involved. I tried implementing a 'boot last loaded rom' feature and it quickly got complicated beyond the trival consoles that have a single cart to load.

There is also /dev/MiSTer_cmd that you can echo a few commands into, including one that will load mra/rbfs.

Honestly if you are looking for that level of integration with a custom cab, you probably need to run a locally modified version of Main_Mister. I do this myself for various reasons and have an auto-build system setup on github that applies my patches and builds a new binary when there are new releases.

You could likely easily add something that writes to /tmp/ROMNAME when any file is loaded into a core, this would be semi-meaningless for some computer systems but you probably don't care about those anyways.

It's also not hard to add a command to /dev/MiSTer_cmd to load a rom/mount a cd image. You just need to know the 'index' in the OSD of the file load entry. I've previously done it as part of mass testing chd images.

[IAmDotorg]

You might be better with a MISTerCADE which has the JAMMA pinouts built in. That would give you the physical cabinet connection you're looking for.

The problem isn't the connection -- that's pretty trivial to deal with. Jamma support makes it easy to drop into a simple, legacy Jamma cabinet, but anything but the most trivial cabs had secondary interfaces for the non-standardized connections. Jamma is almost entirely about inputs, if you look at the specs for it. The only output puns are video and audio.

The hard problem with cabinet connections is the outputs, and from what I can tell, there's no implementation of them in any of the cores. (Or at least, I can't find any standard mechanism in MiSTer for them, so ported cores that *did* support them seem likely to not have them exposed anymore.)

[IAmDotorg]

Main_Mister writes the core name to /tmp/CORENAME when it loads a new core. Arcade games loaded via an MRA will write the 'setname' attribute in the MRA if it exists. (So basically the rom name for almost every arcade core).

Oh, that's workable relative to RGB button configuration, then. It'd be pretty trivial to monitor for changes and do a quick lookup to reset the configuration. I had looked into the Main_MiSTer code to look at how much of a pain it'd be to wire in a better eventing mechanism so I could do it as the user is moving through the core list, but I was surprised to find there's so much core-specific logic in there, and was concerned about dealing with the hassle of merging patches in code that isn't designed to be extended and, thus, more stable. The reason I asked about triggering a core/mfa load from inside a core was a thought that I could do an end-run around MiSTer by loading a frontend core at startup, and presenting a UI specifically designed for cabinet interaction, but that does mean having core-exposed interfaces for the management components.

The lack of a mfa-type capacity for console and computer cores is maybe something I could ignore, although it definitely adds to the complexity of using the system in a cabinet, but the lack of outputs is probably a blocker anyway.

I was kind of surprised I couldn't find much discussion about the lack of an output framework from the cores -- there's a few discussions about individual cores and how critical they are to the games, but no discussion about standardizing them. Without them, while the "digital" portion of a game can be discussed in the context of being cycle or frame accurate and whatnot, you can't really talk about the gameplay being accurate, because the UX isn't complete for them. (And its not a small number of games -- over 2,000 of the supported games in MAME have outputs defined!)

[Newsdee]

It should be possible to support outputs via User IO, but every core that uses them would need to be modified.

[dshadoff]

Maybe you want to take a look at what this thread holds:
viewtopic.php?f=9&t=1887

[IAmDotorg]

It should be possible to support outputs via User IO, but every core that uses them would need to be modified.

Given how most retrofit hardware is going to work, to interface with cabinet lights (either RGB or single LED for new cabinets, or higher voltage incandescent/neon/etc on original ones), you'd be basically starting from scratch. There's existing hardware for managing it via USB, so you'd really want to route the outputs back to the host process, so it can (via whatever mechanism) route it to the lighting controllers.

It took MAME a very long time to get them standardized, but when they finally did, it just meant getting the memory addresses or ports mapped properly in the ROM metadata, and they all basically just worked. The Mister core is already handling abstracting input controls via USB/keyboard/whatever, its the right layer to also abstract outputs.

[Newsdee]

It took MAME a very long time to get them standardized, but when they finally did, it just meant getting the memory addresses or ports mapped properly in the ROM metadata, and they all basically just worked. The Mister core is already handling abstracting input controls via USB/keyboard/whatever, its the right layer to also abstract outputs.

I don't think it's possible for the ARM core to just read memory addresses of the HDL side (I might be wrong), but there are mechanisms for the HDL core to send messages / trigger behavior on the ARM side. So you'd need to add a bit of logic on each core, but it shouldn't need a lot of customization per core (or, perfect world, it would be configurable via MRAs)

Most of the work would probably be in implementing the MAME standards for the first core.

[IAmDotorg]

Maybe you want to take a look at what this thread holds:
viewtopic.php?f=9&t=1887

Yeah I saw that -- and was impressed at how over-the-top/rube-goldberg it was. The LTC connector on the DE-10 is connected to the HPS and could be used to access an SPI-based (or i2c-based) OLED directly from Linux without all the arduino code. Its core process is just reading the /tmp/CORENAME file to see what is going on with the cores, too.

I was able to do something similar to reconfigure the RGB controls on the cabinet -- it was a simple bit of scripting once I knew that file was there. The core outputs is the problem now, and the launching directly into a console ROM. The latter seems doable, but the former looks to be a real nightmare.

[IAmDotorg]

It took MAME a very long time to get them standardized, but when they finally did, it just meant getting the memory addresses or ports mapped properly in the ROM metadata, and they all basically just worked. The Mister core is already handling abstracting input controls via USB/keyboard/whatever, its the right layer to also abstract outputs.

I don't think it's possible for the ARM core to just read memory addresses of the HDL side (I might be wrong), but there are mechanisms for the HDL core to send messages / trigger behavior on the ARM side. So you'd need to add a bit of logic on each core, but it shouldn't need a lot of customization per core (or, perfect world, it would be configurable via MRAs)

Most of the work would probably be in implementing the MAME standards for the first core.

No, it definitely can't because the memory only really exists as something materialized by the FPGA. The core itself would need to properly emulate the output ports on the original hardware and route the signals to something to send it back to the HDL side over the SPI interface. I've started poking through the cores to see if I can figure out if they even have shims for them, but didn't make much progress yet.

[venice]

Yeah I saw that -- and was impressed at how over-the-top/rube-goldberg it was.
...

...but it does what it should do without modifying the MiSTer Cores.

All the best

[IAmDotorg]

...but it does what it should do without modifying the MiSTer Cores.

All the best

Hey, I didn't mean any offense. Like I said, I was impressed. But doing it without additional hardware doesn't take modifying the cores, not sure why you'd think it would? Like I said, you don't need the Arduino there, you could hook the display up directly to the DE-10. Thus, rube goldberg. Like I said, its an impressive hack and its easy to miss that there's an SPI/i2c interface available on the Linux side.

[venice]

Hey, I didn't mean any offense.

All good on my side

Like I said, its an impressive hack.

Thank you.

...and its easy to miss that there's an SPI/i2c interface available on the Linux side.

I know. I am still thinking about to use I2C.
But how to access the interface with scripts as I don' want to compile anything.

Antonio Villena build Custom Boards with onboard Display and is looking for support.
If you find an easy way to use the onboard interfaces let me know.

Anyway, the USB-Serial Variant was the absolut easiest way to communicate and it works really good.

Happy Eastern

[venice]

...
Antonio Villena build Custom Boards with onboard Display and is looking for support.

Here https://github.com/venice1200/MiSTer_i2c2oled
you can find a bash script which sends data via MiSTer's i2c bus to an connected SSD1306 OLED Display.

Cheers