Front end swap?

[kamshaft]

I've google this subject and found basically a tug of war discussion over at... atari-forum

Let me explain the reason why I would want to swap out the menu with something nicer.
I'm looking at buying a MisterCADE. https://www.youtube.com/watch?v=9-212r6kKC8

I have a Ms.Pac-man machine and would like to replace my 60-in-1 PCB with a mistercade board. But the thought of using the text menu....well....

I'd rather this thread doesn't become a tug of war discussion. This front end would NOT need to be a Hyperspin thing either.

A black background and a graphic, maybe one line of text, left and right to scroll to the next title, that's it.
Simple.

Personally I just want this for the arcade cores. I don't want to put NES/SNES stuff on my arcade machine.

Thoughts?

[zakk4223]

Ignoring all the back and forth over the actual frontend itself being a good idea or not:

The implementation isn't really a simple 'swap one component'. The UI you see is is a combination of components that run both on the fpga and on the ARM side. They're pretty intricately entwined, so trying to make a big change in one is going to cause big changes in the other.

The problem here is the ARM side (called "Main Mister') provides a bunch of other support functionality to cores that they require. (Such as, processing all input and button mappings...) So anything that tries to replace it needs to replicate all that functionality, and keep up with any changes/additions/etc that are made to the 'real' Main_Mister code.

It's not impossible to do; but it isn't a trivial amount of effort and as of today no one has really stepped up and been (openly) willing to take on that effort. Even if someone did, they'd effectively be maintaining a fork of Main_Mister and having to keep up with updates etc. Also keep in mind that the OSD also has a 'sys' component that's part of every core; that may come with limitations as far as buffer size and what it can actually render to the screen.

[Lisko]

It was already discussed even on this forum and the amount of work to expose a simple interface to control mister cores from another app/frontend isn't that much. The problem is that sorge doesn't want to add or even accept a pr for this for his reasons and so a new unofficial fork should be made and this is enough to discourage even those who would like to see and put the efforts for another frontend.

[zakk4223]

If you wanted to do just an arcade focused front end, Main_Mister already has a way to tell it to load cores via a unix socket, and you can load an MRA that way. There's no concept of 'exiting' a core though, so I don't know how you'd ever get back to the frontend, unless you were willing to do a web-only frontend.

[Sorgelig]

It was already discussed before. It's not that i don't want. You guys simply don't understand how things on MiSTer are working. MiSTer has no GPU (and no video card at all), so if you think it will look slick with smooth scrolling and overlaid on original video of core then you are wrong. It will look ugly without transparency. So either it's fully linux screen or core. And on Linux screen - no 2D acceleration with high CPU usage, so core may miss important event while menu is opened and ARM CPU is busy with some "nice" graphics drawing. At the end you will end with primitive UI from 90x with little gain over current overlaid OSD.

Since MiSTer is about FPGA emulation with core's video as a main part, it provides enough menu to change the settings or load another core.
If you want 2D/3D menu with smooth nice graphics then you need to look to Raspberry Pi. Probably you don't understand what is MiSTer for.

[Sorgelig]

And while i'm not a fan of VGA output, i'm still doing my best to support VGA output at reliable level. It means a wide range of resolutions. Some cores output as low resolution as 256x224, while typical HDMI output is 1920x1080. Which UI could look nice on both of these resolutions? And there are arcades with vertical modes..
If you put all together you will come back to a simple OSD as now. Which looks good on any resolution and displayed at the same time on 2 different resolutions.

[jlancaster86]

I'm fine with the OSD as it is, but how practical would it be to allow MiSTer to accept control commands from an app or web browser on another device, as something like Kodi or Plex allows? Users could then run their flashy frontends on their PCs or phones.

[alanswx]

I have a patch to put a web server into mister. But I haven’t found a good use case.

I also hacked mister to change the background each time you moved to a new selection. But it was slow. I would need to think about how to speed it up.

But Sorg is right - it makes it slower and my background hack only worked on hdmi anyway. Not sure there is a great answer.

We should probably build the UI completely as an NES cartridge.

Alan

[zakk4223]

You can already load cores via writing a command string to a unix socket. You can't tell it to load a rom this way, but I was able to trivially add that and disk image mounting when I was automating some testing. You have to know the proper 'rom index' to use (which is core dependent) but whoever is writing a front end like that will just have to maintain a database of which indexes are what.

I think I even managed to kinda fake it via some MRA trickery, but I'd have to re-visit how to do that.

If you got really desperate you might be able to inject keyboard events via the linux /dev/uinput, but I've never tested that.

There's probably enough functionality that exists today to write a linux-side server to load games, but you'd have to do a lot of the content discovery yourself.

[Sorgelig]

MiSTer isn't really good at multitasking. More side tasks you add - more problems MiSTer will have. MiSTer needs one CPU core to work solely for MiSTer binary to provide all required data for core in time. Another CPU core is given to linux system tasks, but being a single core it's easy to overload it.
If you load it harder, it may work for your specific setup and needs but may have problem for other users. Input lag can be greatly increased with more tasks.

[redsteakraw]

You can have a Linux UI frontend that loads the core then closes its self out, but you still need the OSD as is and simple. You would also need to either use the OSD to switch games or reload the UI again. Retroarch is coming to the DE-10 nano just you could port the retroarch UI code to be able to launch cores and there you would have it. Just don't know how smooth or good the UI would be given that there is no GPU and the CPU is underpowered compared to the raspberry pi. Again it would be best to close out that UI once the core is launched as you don't want it taking up resources and causing any slowdowns or choking of the USB handling. Linux is used to forward the USB controls to the cores if it chokes you will have laggy and clunky controls and no one will be happy.

[NightShadowPT]

What about using an external device like a Raspberry Pi?

Would it be possible to interface with the Pi (where all the fancy front-end things would run) and use the MiSTer for the really important stuff (i.e.: running the cores)?

If this is possible, it may be easier to adapt an already great frontent like Emulation Station to just interface with the MiSTer and vice versa.

Is this a pipe dream, or possible?

[zakk4223]

You would have two things that need to get input from the controller(s), and two things that need to output to the same screen. So no, that's not really going to work in any feasible way

[grizzly]

What about using an external device like a Raspberry Pi?

Like Zak said.
Plus you probably would need to use command string to a unix socket to control the mister.
And as said earlier in the tread you can ONLY load MRA files (as in load a core), but not load any roms using that.

[zakk4223]

What I would say to anyone with ideas regarding this: there's currently enough functionality in MiSTer that you could write a proof of concept frontend that would allow you to load arcade games and work though the mechanics of how to re-launch the frontend etc. If you were willing to create some filesystem symlinks and write temp MRA files you could even load some console cores with games.

Showing that even a simple frontend is viable and won't compromise performance is the first step to getting changes done to Main Mister that would make things easier. Without that proof this isn't likely to go anywhere. I should be clear though: a PoC doesn't ensure MiSTer will get changes to make frontends easier to write, but it's a better chance than just talking about them

[kamshaft]

Hmm.. Would it be possible to create a core based on an existing machine, like an Amiga with RTG? Then have the ability to drop out of that core and load any other core from there? (This is spoken from a person not knowing FPGA basics.)

[Gskerit]

What about using an external device like a Raspberry Pi?

Like Zak said.
Plus you probably would need to use command string to a unix socket to control the mister.
And as said earlier in the tread you can ONLY load MRA files (as in load a core), but not load any roms using that.

Why not emulate a keyboard on the pi? The menu is simple enough for any launch sequence to be translated as a series of keyboard inputs, which could be sent by a frontend living completely outside the mister.

[Xzarian]

Here is a project that used a web server running on mister arm to control cores

https://github.com/nilp0inter/MiSTer_WebMenu

You could use the interface on your phone and the core would load. I don't think there was anyway to load a rom into a console core though.