Is it possible to make a MiSTer frontend via a front end core?

[KremlingKuthroat19]

I know. The dreaded "Will MiSTer ever get a front end?" question. This question isn't if MiSTer will get a front end via MiSTer main. The question is whether it's possible to make a core written in Verilog/VHDL that acted as a front-end and was written entirely in logic.

If this is possible, you could hypothetically select both MGL and MRA files and launch games similar to how you would on any emulation device front end. I know the De-10 Nano not having a GPU makes it so you can't run a front end in MiSTer main and it'd take up too many resources, but if let's say an option was built in to your MiSTer config to autoboot to this core upon turning on your MiSTer, could you display a simple front end that had say just box art, metadata, and maybe even a screenshot? The MiSTer menu would still technically be there because you'd launch it by hitting the MiSTer menu button, so it could work like an overlay for this theoretical MiSTer front end core like how it already works in all other cores.

If possible, this would be the best way to handle a front end for MiSTer imo since the community is pretty split on whether they want a front end or not. People that want a front end could use this hypothetical core, while users who see no need for a frontend could simply ignore this front end all together, and it wouldn't take up additional logic for the MiSTer UI.

Just a fun thought experiment. I don't even know if this is possible, but I thought it was an interesting idea.

[grizzly]

The MiSTer menu would still technically be there because you'd launch it by hitting the MiSTer menu button, so it could work like an overlay for this theoretical MiSTer front end core like how it already works in all other cores.

Possible or not i do see one problem with this.
And that is depending on the GUI core "FPGA size" some cores would probably be to big to be able to use the GUI core as an overlay.
Basically for an overlay GUI core you have to ruin both cores at once and if a bigger core is running there would not be enough FPGA space left to run an overlay GUI.

And now i thought about one more!
Can the DE-10 even start one core and then start/stop another core while the first core is still running and never closes?
My guess is probably not, BUT i have no clue at all so only guessing.

[onaryc]

i think you can mimic what the sd2snes use for a frontend : a program on the snes itself. You can for example take an existing core and code a frontend on it. I think you will need the mister api to launch game exposed one way or another (i think it is the way sd2snes does it)

[Mr. Encyclopedia]

Possible or not i do see one problem with this.
And that is depending on the GUI core "FPGA size" some cores would probably be to big to be able to use the GUI core as an overlay.
Basically for an overlay GUI core you have to ruin both cores at once and if a bigger core is running there would not be enough FPGA space left to run an overlay GUI.

I don't think that's what Kremling is talking about, I think what they're describing is basically an alternative for menu.rbf, which isn't the OSD but rather is the core that loads when the MiSTer starts and contains a basic framebuffer and does things like display wallpapers or generate the static background.

I don't think anyone who has ever asked for a GUI frontend has wanted to get rid of the OSD entirely, they just want an alternative to navigating text menus to get to the core you want, then loading that core and navigating more menus to load the game you want. MGL files already do a lot to streamline that, but even then you're still navigating text menus to get to the MGL you want.

A proper MiSTer GUI wouldn't have to be that complicated, just something that indexes your games folder and then visually displays what it finds. It would be able to pull metadata to let you sort your games by system or year or genre or rating, and then lay them out for you to browse the way we used to look at box art when buying or renting them.

I still find it difficult to believe that the resources to do this aren't there already, if ScummVM can run off the simple framebuffer that menu.rbf provides, then a simple GUI should be able to run too. Even a script that builds static HTML pages that you browse with a terminal browser like Carbonyl or Browsh would be a more enjoyable alternative to the current UI. It's a lack of developers with the skills and interest that's the problem, not lack of resources on MiSTer.

[KremlingKuthroat19]

Mr. Encyclopedia articulated exactly what I was trying to say. Thanks for that!

I use MGL files for all my console games and it's a MUCH more streamlined option to select games. MGL also allows you to easily create playlists. I have playlists for every peripheral for each console, years games released and things of that nature. It makes navigating the MiSTer menu a much better user experience.

MGL files are basically the framework that allows for what I'm asking for to be possible. With MGL files you can load any console game from anywhere on the menu. I suppose the way this idea would work is that a theoretical core would be named something like "frontend" and that's where the games folder would be located. You could simply place all your MGL files there. Theoretically you could also name the frontend core something like "boot.rbf" and put it in root so that it boots this core automatically when starting up MiSTer like how console cores boot automatically to whatever file is titled "boot.rom". Maybe even make "boot.rbf" customizable so that anyone can make any frontend they want like how you can have any wallpaper you want as long as you name it correctly. It'd be cool too if you could hit the "Reboot" button on the MiSTer menu or just hit the physical reset button and it loads the frontend core again to easily jump back into it when you're ready to select a new game.

Btw, this is not an attempt to replace the MiSTer menu or make it more complicated or add more logic to it. I love the MiSTer menu and the system couldn't function without it. Plus, the current MiSTer menu is essential for any core. You still need to be able to adjust your core settings after you've launched your games via MGL files.

This should theoretically be able to work for all console games. Arcade games are where it gets iffy because I think MRA files need to be located in the "_Arcade" folder to work, so support for MRAs to be located anywhere like MGL files would have to be implemented down the line.

What caught my interest too is how Robert Piep built his chess core completely from scratch just using logic. I think it'd be pretty cool if some kind of front end core that features media support for text, audio, video and images could be created completely out of logic and optimized to run on the DE10 Nano.

[felleg]

This is the first thread about "MiSTer front-end" that I can behind. I think this is clever. Is it an interesting/realistic engineering challenge to connect a core with the MiSTer filesystem?

I'll be monitoring this thread.

[Newsdee]

Do you want a launcher or a front end?

A launcher that works as an alternative to menu.rbf is doable, maybe requiring some extra features in MiSTer's firmware to control launching other cores if different to what menu.rbf already supports.

Replacing the menu inside cores (an OSD), forget it. That will need recompiling every core and take up more resources away from features for the core's main system. Nobody will want to bother maintaining all that.

You cannot keep a core loaded when another one loads. The rbf reprograms the whole FPGA.

[Newsdee]

if let's say an option was built in to your MiSTer config to autoboot to this core upon turning on your MiSTer

This feature already exists, it's an INI option

[KremlingKuthroat19]

Do you want a launcher or a front end?

A launcher that works as an alternative to menu.rbf is doable, maybe requiring some extra features in MiSTer's firmware to control launching other cores if different to what menu.rbf already supports.

Replacing the menu inside cores (an OSD), forget it. That will need recompiling every core and take up more resources away from features for the core's main system. Nobody will want to bother maintaining all that.

You cannot keep a core loaded when another one loads. The rbf reprograms the whole FPGA.

Definitely the launcher options seems like the best choice. As mentioned, I don't want this idea to replace the MiSTer framework or alter it in any significant way by any means. I understand that the MiSTer UI is designed to be as lean as possible in order to not take up logic space that could be better used for individual cores. The menu OSD inside every individual core should remain completely unchanged. So yes, this is pretty much just an idea for a launcher. A front end is just a GUI for a launcher anyways whereas the MGL files would be the shortcuts launching into the cores from this proposed frontend core.

Btw, good to know that autobooting a core is already a feature in the INI file. Nice!

[Newsdee]

The menu OSD inside every individual core should remain completely unchanged. So yes, this is pretty much just an idea for a launcher.

There is this already, have you seen it?
https://github.com/nilp0inter/MiSTer_WebMenu

It allows you to launch cores and games from another device in your network (say an iPad or iPhone)

[felleg]

It allows you to launch cores and games from another device in your network (say an iPad or iPhone)

The issue what that is that it requires an Internet connection. But yes, good thinking to bring this up, at I think it should be relevant

[Newsdee]

The issue what that is that it requires an Internet connection. But yes, good thinking to bring this up, at I think it should be relevant

it works by running a local program, so a Linux based front end could do all the same features.

I fact I wonder if you could just run EmulationStation and invoke a core or load MGL files...

[KremlingKuthroat19]

The menu OSD inside every individual core should remain completely unchanged. So yes, this is pretty much just an idea for a launcher.

There is this already, have you seen it?
https://github.com/nilp0inter/MiSTer_WebMenu

It allows you to launch cores and games from another device in your network (say an iPad or iPhone)

Yeah I followed this project when I first got a MiSTer. It sadly hasn’t been updated in over 2 years now. It’s a great proof of concept and as another user mentioned this requires an internet connection. This was also made prior to MGL files being a thing and this idea I’ve been brewing is MGL dependent.

I know that there was a Dragon’s Lair core or Laserdisc core if you will bring developed that can run MPEG-2 video, so the idea that you can run video on a custom MiSTer core is definitely achievable. If MPEG-2 is possible within a custom MiSTer core, I don’t see how adding text, audio, metadata and images wouldn’t be possible either.

I think best case scenario is that a theoretical front end core would be able to run on any FPGA device, given that it has enough logic elements. Ideally, this front end could be backported to MiST (assuming MiST has MGL support) and could be ported to other FPGA devices on the market as a way to futureproof this front end solution.

Emulation Station is an interesting example. It’s robust enough as a front end to be viewed as a premium solution w/out being over the top like Hyperspin. Maybe it’s possible someone tries to port Emulation Station to Verilog/VHDL to see how feasible this idea is. If that front end is too complicated, maybe a more basic front end could be ported as a core first?

[Fallon]

I personally hope we keep garish front ends like EmuStation far away from Mister. Mister's UI is fine, it doesn't get in the way of the games themselves. Some people appear to love front ends more than actually playing the games. The SNES had no "beautiful front end with boxart and blurred background game images" , nor did the Megadrive, Saturn or the PSX for the matter.

[KremlingKuthroat19]

I personally hope we keep garish front ends like EmuStation far away from Mister. Mister's UI is fine, it doesn't get in the way of the games themselves. Some people appear to love front ends more than actually playing the games. The SNES had no "beautiful front end with boxart and blurred background game images" , nor did the Megadrive, Saturn or the PSX for the matter.

It’s not necessarily front ends that I’m most interested in. Frankly, I’d be happy with just box art because to me that’s part of the experience is seeing the box art like when you select a game off your shelf. If you watch a movie on a streaming service there’s box art there too so it’s just a nice QoL feature imo

[dmckean]

No, this is never happening.

Any launcher made as a core is going to end up being extremely disappointing. At least the OSD is usable.

[pgimeno]

Replacing the menu core with a custom version that switches to the Linux screen from the beginning and loads a certain script automatically at start, should be doable. This script can launch the front end. Upon selecting a core, it should be easy to load it via writing a command to /dev/MiSTer_cmd. This can be done in any language, including a shell script, for example this works:

echo load_core <core-full-path> > /dev/MiSTer_cmd

Most probably even EmulationStation can be configured to load a core this way.

Since the front-end loader would replace menu.rbf, a soft reset would suffice to return to the front-end. You can do the soft reset with a keyboard (either Shift+Ctrl+LeftAlt+RightAlt, or the other key combo configured in MiSTer.ini) or via the menu.

The normal OSD menu of cores other than menu.rbf would remain intact.

That's just an idea in case someone wants to do it. I'm happy with how things are now

[redsteakraw]

echo load_core /media/fat/_\@Favorites/Mega\ Man\ 2\ \(USA\).mgl > /dev/MiSTer_cmd

Can confirm, it works and over SSH! It works with rbf cores or mgl files no word on how to load games when a core is open other than MGL files. If you have the favorites script it will generate all your favorite games into mgl files son everything should work

kUjgmI6.jpeg (715.78 KiB) Viewed 5718 times

[KremlingKuthroat19]

Replacing the menu core with a custom version that switches to the Linux screen from the beginning and loads a certain script automatically at start, should be doable. This script can launch the front end. Upon selecting a core, it should be easy to load it via writing a command to /dev/MiSTer_cmd. This can be done in any language, including a shell script, for example this works:

echo load_core <core-full-path> > /dev/MiSTer_cmd

Most probably even EmulationStation can be configured to load a core this way.

Since the front-end loader would replace menu.rbf, a soft reset would suffice to return to the front-end. You can do the soft reset with a keyboard (either Shift+Ctrl+LeftAlt+RightAlt, or the other key combo configured in MiSTer.ini) or via the menu.

The normal OSD menu of cores other than menu.rbf would remain intact.

That's just an idea in case someone wants to do it. I'm happy with how things are now

Thanks for the explanation. My goal with this thread was twofold: 1) to see if what I was proposing was theoretically possible and with your explanation, it certainly seems so and 2) to gauge interest if it’s possible.

I’m content with my MiSTer setup. The only things I’d like is for the OSD to be potentially expanded because there just aren’t enough characters to display game titles well, especially regarding CD based games, and two having box art be visible when selecting a game (but that’s more of a “nice to have” not a “need to have”).

Part of the reason I suggested this method of making a front end is because it’s a completely seperate way of navigating the MiSTer menu than the standard way. Front ends are polarizing in this community so if this were to ever be implemented, those not interested in front ends could simply ignore it and it wouldn’t affect them at all. Most users don’t use MGL files. I do and have seen how much more robust and customizable your MiSTer setup can be with them so it’s an option for power users if that makes sense.

Lastly, there’s a good amount of people who don’t like MiSTer bc there’s no front end. I’m not one of them, but it’d be a nice option to have to bring in more people to the community

[HerrBerzerk]

I always liked mameinfo.dat where you could see the history of a game with button description, sometimes strategies and all interesting stuff.

[PistolsAtDawn]

I've used frontends and not used them too. Mostly I like them, but they are very frequently just another thing to have to setup and manage. As I get older, I don't wish for additional chores attached to gaming, which is why I almost never bother with scraping box art on any frontend setup that isn't on a powerhouse device.

The RetroPie project (and other EmulationStation-based GUIs) are great and flexible options, but mostly my experience with getting box art setup on them is that - for large collections anyway - you'll need to step away from them while they work to scrape all your games from on online database. As far as I know, you can't set that task to work while you play a game. I'm talking about on devices like Raspberry Pis or those inexpensive ARM-based handhelds, not regular PCs.

I recognize that's a minor complaint, but when we only get so much time to spend playing games, I don't want very much of that time going to maintenance tasks. I'm pretty picky about what I'll spend time customizing even on a device like the Steam Deck. I do have EmulationStation setup on mine, but I don't think I've bothered with box art. I prefer to browse my collection from ES rather than use RetroArch's file browser even without box art.

What I appreciate about the MiSTer OSD is the simplicity and performance. It doesn't slow anything down, ever. Box art for huge collections has definitely slowed down various frontends I've used.

The devil's in the details. If a MiSTer frontend were to be made, I would hope that it wouldn't tax the relatively weak CPU (or whatever FPGA implementation is used). I would definitely give such a thing a shot at least.

[Mr. Encyclopedia]

I would like to stress, yet again, that the only people asking for this are asking for an entirely optional alternative to the current mister menu. If you're not interested in wasting time scraping game libraries and building databases, that's totally fine. No one wants to force you to do that. No one wants to replace the current OSD, or alter the framework loaded into every MiSTer core.

All people want is a menu that shows the games you have in a slightly friendlier way. I have kids who would love to play on my MiSTer more, but they're completely uninterested in navigating menus full of text lists of games they've never heard of. They have fun when I show them games I think they'd like, but I already don't have a lot of time to play games so I certainly don't have time to be their game sommelier too. A simple menu similar to MegaAGS would go a long way to helping younger generations explore the wealth of games hidden away on a fully loaded MiSTer.

I've looked at Mister WebMenu before and it's a nice proof of concept, but it's years out of date and very much a "I'm a web developer so I will come up with a web developer shaped solution" kind of project. There should be a menu like that which can run on MiSTer alongside the current OSD menu. There's already native linux software that scans and organizes your games, I find it difficult to believe that nothing built on libretro could ever run on a MiSTer.

[PistolsAtDawn]

I would like to stress, yet again, that the only people asking for this are asking for an entirely optional alternative to the current mister menu. If you're not interested in wasting time scraping game libraries and building databases, that's totally fine. No one wants to force you to do that. No one wants to replace the current OSD, or alter the framework loaded into every MiSTer core.

I don't think you need to stress, even once, anything at all. I said that I would try it, but that I hoped it wouldn't tax the system having thousands of box art pictures downloaded. Scraping usually only needs to happen once, but performance of the GUI needs to be good enough to be useable. That has not always been my experience once all the art is downloaded, which then makes for another task in tweaking that to make it useable.

[KremlingKuthroat19]

I would like to stress, yet again, that the only people asking for this are asking for an entirely optional alternative to the current mister menu. If you're not interested in wasting time scraping game libraries and building databases, that's totally fine. No one wants to force you to do that. No one wants to replace the current OSD, or alter the framework loaded into every MiSTer core.

I don't think you need to stress, even once, anything at all. I said that I would try it, but that I hoped it wouldn't tax the system having thousands of box art pictures downloaded. Scraping usually only needs to happen once, but performance of the GUI needs to be good enough to be useable. That has not always been my experience once all the art is downloaded, which then makes for another task in tweaking that to make it useable.

You make some good points. IMO in terms of media, front box art and maybe a screenshot is enough media to make a browsing experience pleasant for every user w/out feeling overwhelming. Maybe just a little bit of metadata like year released, players, and controller type would be enough metadata too.

I agree that having too much media and metadata is overwhelming, creates paralysis by analysis, and could create unnecessary performance issues. There’s likely a happy medium though.

[Bas]

Totally different tangent: a web API on MiSTer that you can control from your phone? No GUI, just control API's and a method to inventory your ROM's remotely. Frontend could be a web thing on the MiSTer itself but also a phone app or something completely different like a hook into your home assistant or whatever..

[redsteakraw]

Well you could ssh in do a ls or tree command parse and then do all the metadata from a phone app or external PC then control the MiSTer through ssh. If that is a problem write a frontend or adapt emulation station UI to the MiSTer and keep the OSD and add enter launcher on the OSD so you can go back and forth as you would want the frontend to close on core load and to open the launcher from OSD when you want to go back. MiSTer menu is needed as it is light weight on the FPGA and able to be open on any core.

[jfml1974]

I know. The dreaded "Will MiSTer ever get a front end?" question. This question isn't if MiSTer will get a front end via MiSTer main. The question is whether it's possible to make a core written in Verilog/VHDL that acted as a front-end and was written entirely in logic.

If this is possible, you could hypothetically select both MGL and MRA files and launch games similar to how you would on any emulation device front end. I know the De-10 Nano not having a GPU makes it so you can't run a front end in MiSTer main and it'd take up too many resources, but if let's say an option was built in to your MiSTer config to autoboot to this core upon turning on your MiSTer, could you display a simple front end that had say just box art, metadata, and maybe even a screenshot? The MiSTer menu would still technically be there because you'd launch it by hitting the MiSTer menu button, so it could work like an overlay for this theoretical MiSTer front end core like how it already works in all other cores.

If possible, this would be the best way to handle a front end for MiSTer imo since the community is pretty split on whether they want a front end or not. People that want a front end could use this hypothetical core, while users who see no need for a frontend could simply ignore this front end all together, and it wouldn't take up additional logic for the MiSTer UI.

Just a fun thought experiment. I don't even know if this is possible, but I thought it was an interesting idea.

And a program or core that works as a game and shows a list of games in a small photo or similar...? I don't know, maybe just a fantasy, but seeing the progress of programming and programmers with great ingenuity ...someday something will appear

[dickhardpill]

I don't know if this idea has been floated and I have no idea the feasibility-

would it be possible to make an html/css/java 'menu' core and utilize the remote API?

[Longtime4321]

I believe it's 100% possible, but the only way it will happen is if someone with the ability to make it wants to.