ScummVM running on FrameBuffer

[BBond007]

Thanks to the new Linux Scaler/FrameBuffer I have made some progress at getting ScummVM to run. --> https://www.scummvm.org

I picked these two games to demo because they target the early Pentium CPUs and run in 640x480x256 Color SVGA. There is really no way they would run on ao486.

The performance with native ScummVM is really awesome. No need for improvement with that. Check out the parallax scrolling in Broken Sword II around 00:40...

The color is a little wrong. I'm not sure what is going on there. Seems like too much green...

Maybe I need to recompile something using different RGB format?

Broken Sword II : Shadow of the Templars --> http://youtu.be/cC3BI4D5cgw
Monkey Island III: The Curse of Monkey Island --> http://youtu.be/coKlynUFK0o

Some people might say "Blasphemy! It's not running on the FPGA!", but I'd argue its using the FPGA as a video card and sound card and running as a native Linux APP

Anyway, thanks for all the hard work on the Scaler and FramBuffer @Grabulosaure & @Sorgelig Great feature!

[onaryc29]

Personally, i think this is fantastic. On a RPI, i was never able to have correct scanline with the correct aspect ratio and i love the mister scaler (and the mister os boot quasi instantly). Is this working with the vga analogue output?

[uigiflip]

Is this ScummVM ready for release yet?

[BBond007]

Personally, i think this is fantastic. On a RPI, i was never able to have correct scanline with the correct aspect ratio and i love the mister scaler (and the mister os boot quasi instantly). Is this working with the vga analogue output?

Yes and no... Yes its working on VGA (with vga_scaler=1). No it won't work with CRT.

I picked 1280x1024@60 mode (4) as it gives a 640x512 framebuffer.

Below 640x400 won't work.

Is this ScummVM ready for release yet?

The colors are wrong... The FrameBuffer was just released like 1 day ago...

Says in your sig you have a Vampire and Replay + 68060 Daughterboard! Play it on NovaCoders ScummVM Amiga port until it is ready

These two games would choke on my A1200/Blizzard1260/AGA but I bet they work with RTG...

[onaryc29]

Below 640x480 won't work.

ok, back in the days, i play monkey island 3 on my VGA/CRT monitor, i can not remember which resolution i use then. This was the time i was trying to have the maximum one (quite the contrary now with the game from that area )

Anyway, keep up the good work

[kitrinx]

I don't mean to diminish your port of this, but as I mentioned on discord, having software emulators running on MiSTer really dilutes the platform. It's an fpga platform, that is what it excels at, and that is what people should expect when using it. Having a fully software emulator on there is going to send mixed messages about what MiSTer is. The framebuffer and even processing power is not what MiSTer was designed around, a raspberry pi is better at these things with hardware accelerated video rendering and more, bigger cores. I would rather we didn't start on this slippery slope of introducing software emulation to this platform. It's cool if you keep this to yourself, but please, please don't put this in the official repo or updater.

[witchmaster]

Nice, good work! Personally, I would love to have this on my MISTer even if it's not purely fpga, would make my MISTer even more versatile. If it doesn't end up in the official repo, please make it available somewhere else, thanks!

[jdubs]

Pretty cool I guess but, yeah, please don’t put on the official repo.

[Sorgelig]

I don't mean to diminish your port of this, but as I mentioned on discord, having software emulators running on MiSTer really dilutes the platform. It's an fpga platform, that is what it excels at, and that is what people should expect when using it. Having a fully software emulator on there is going to send mixed messages about what MiSTer is. The framebuffer and even processing power is not what MiSTer was designed around, a raspberry pi is better at these things with hardware accelerated video rendering and more, bigger cores. I would rather we didn't start on this slippery slope of introducing software emulation to this platform. It's cool if you keep this to yourself, but please, please don't put this in the official repo or updater.

Even before the first release of MiSTer i kept in mind a hybrid emulation. Hybrid emulation is not exactly mixed together in one where CPU emulated on HPS and chipset emulated on FPGA. Some simple fully software emulators also can be a part of hybrid emulation. And there are many emulators for which performance of HPS will be enough. So why not use it?
There are always some idiots who cannot see the difference, why don't ignore them?

In Menu core, there is nothing happening on FPGA side, so HPS is pretty much free to do some usual CPU tasks. Probably it's possible to make a special tweak of MiSTer for Menu core where it won't use poll often and thus will free CPU core for other tasks.

[Sorgelig]

Simple change of one line frees both cores - see my latest commit.

[kitrinx]

Even before the first release of MiSTer i kept in mind a hybrid emulation. Hybrid emulation is not exactly mixed together in one where CPU emulated on HPS and chipset emulated on FPGA. Some simple fully software emulators also can be a part of hybrid emulation. And there are many emulators for which performance of HPS will be enough. So why not use it?
There are always some idiots who cannot see the difference, why don't ignore them?

In Menu core, there is nothing happening on FPGA side, so HPS is pretty much free to do some usual CPU tasks. Probably it's possible to make a special tweak of MiSTer for Menu core where it won't use poll often and thus will free CPU core for other tasks.

"Hybrid Emulation" is like a harry potter word. You could say a PSX emulator on my PC is hybrid emulation because it is using the hardware in the video card. When somebody ports DOSBox and Visual Boy Advance and ePSXe, then MiSTer starts to get confused with a slower Raspberry Pi. What about if someone releases a real core of these things? Then we have software and hardware emulators of the same thing? Will the users know which is better to use? It makes a very confusing platform. It will give MiSTer a bad name. It's not a good precedent to set.

[Sorgelig]

I think the main criteria is how precise it emulates the real HW. So why need to divide it? If it works well on HPS then why not?
Also impriving the HPS part gives more chance for real hybrid emulation to appear where some parts of soft emulator will be converted to FPGA. Without improving HPS part, the jump to hybrid emulation will be always too big to start.

Also i'm curious how fast is HPS and which emulators are possible to run with decent speed.
Who will port ScummVM to FPGA? no one.. So why not run it on HPS then?

[brNX]

I think the main criteria is how precise it emulates the real HW. So why need to divide it? If it works well on HPS then why not?
Also impriving the HPS part gives more chance for real hybrid emulation to appear where some parts of soft emulator will be converted to FPGA. Without improving HPS part, the jump to hybrid emulation will be always too big to start.

Also i'm curious how fast is HPS and which emulators are possible to run with decent speed.
Who will port ScummVM to FPGA? no one.. So why not run it on HPS then?

I don't feel about this as strongly as @Kitrinx, but still think this "change" can lead to some confusion if not handled right. I agree with the term "hybrid emulation" getting thrown around as a way out (not saying that you would do that @Sorgelig, read it on some parts of the internet that have a bad reputation now among other places, yes I look at you polymega).

On this topic what are your thoughts on the way forward? Are you going to share a buildroot config to facilitate having development environment? (Saw the weston inclusion in the latest update and I like the idea)

Just wanted to give my 2c

Cheers

[NegSol]

Thanks to the new Linux Scaler/FrameBuffer I have made some progress at getting ScummVM to run. --> https://www.scummvm.org

Thx to all involved esp. to Sorgelig and BBond007. I love the idea of improve the MiSTer using all resources available. Even when I can understand purists not getting it. In my view more is more - simple as that. please keep it up

[Sorgelig]

Are you going to share a buildroot config to facilitate having development environment? (Saw the weston inclusion in the latest update and I like the idea)

development doesn't require the buildroot config. I don't want different linux builds to pop around.
I would like to see HPS apps as self contained apps installed preferably in separate directories.
While it's good to add more functionality i don't like idea to add a lot of heavy frameworks with services starting at boot. So i definitely not going to make another RPi with X-Windows.

[brNX]

development doesn't require the buildroot config. I don't want different linux builds to pop around.
I would like to see HPS apps as self contained apps installed preferably in separate directories.
While it's good to add more functionality i don't like idea to add a lot of heavy frameworks with services starting at boot. So i definitely not going to make another RPi with X-Windows.

ok, thanks for clarifying that.

I agree and understand why.

[MartinW]

I don't have an opinion of ScummVM one way or another because frankly, I've never been a fan of the games like Monkey Island, DOTT etc. that it is so well known for (assuming I'm thinking of the correct thing!)

BUT, yeah, I'm confused already. According to everything I can find out, ScummVM is software so where does the excitement come from it being on the Linux side of an FPGA development board? Which core is it running on or using?

That said, as long as it doesn't increase the boot time of the mister, is entirely optional and doesn't bloat the rest in any way then I guess it doesn't matter.

For a bit of context to my thoughts, I was at an Amiga gathering last weekend. The MiSTer drew quite a bit of attention and almost everyone that looked at it had concerns about how quick and transparent the Linux side of things would be when starting up. Everyone without exception was thoroughly impressed at how fast the boot process was and how it didn't detract at all from the main core of interest - in this case the Minimig. Sure, some other stuff like maybe Amstrad, ZX81 etc. might be slower than the real thing because the real thing is pretty much instant on but for anything that has a boot process like the Amiga, the Linux side doesn't really slow things down in the slightest, it's all very impressive indeed.

[BBond007]

I don't mean to diminish your port of this, but as I mentioned on discord, having software emulators running on MiSTer really dilutes the platform. It's an fpga platform, that is what it excels at, and that is what people should expect when using it. Having a fully software emulator on there is going to send mixed messages about what MiSTer is. The framebuffer and even processing power is not what MiSTer was designed around, a raspberry pi is better at these things with hardware accelerated video rendering and more, bigger cores. I would rather we didn't start on this slippery slope of introducing software emulation to this platform. It's cool if you keep this to yourself, but please, please don't put this in the official repo or updater.

First, I really consider ScummVM to be more of a game engine (similar to OpenBOR) than an "emulator" and nowhere on the projects homepage or in the FAQ to they even use the term. In fact, the second paragraph in the Wikipedia page implies its not an emulator. --> https://en.wikipedia.org/wiki/ScummVM

I will honor your request not to put it in the official repo or updater as I'm not even in control of those things.

I do consider asking me to me to "keep this to myself" a totally unreasonable request for you to ask.

When it is ready, it will be made available on my personal github. Sorry you feel if that it "dilutes the platform"...

[BBond007]

development doesn't require the buildroot config. I don't want different linux builds to pop around.
I would like to see HPS apps as self contained apps installed preferably in separate directories.
While it's good to add more functionality i don't like idea to add a lot of heavy frameworks with services starting at boot. So i definitely not going to make another RPi with X-Windows.

ScummVM needs a lot of libraries... I have done a new compile with the 2.0 version have tried to make everything link static. It still requires a lot of libs..

I really don't want that stuff bloating the minimal Linux either.

What I have done is make a scummvm.img that gets mounted with a shell script. The only part of the Linux image I modified is add "/etc/ld.so.conf" (and generate /etc/ld.so.cache) to allow all those libs to be found.

Maybe there is a better way to work with those libs?

In Menu core, there is nothing happening on FPGA side, so HPS is pretty much free to do some usual CPU tasks. Probably it's possible to make a special tweak of MiSTer for Menu core where it won't use poll often and thus will free CPU core for other tasks.

Not necessary at this point to limit the MiSTer task, but definitely a good idea Running the most demanding SVGA games I'm only seeing up to 25% CPU usage.

[ghogan42]

I wonder if we can decide on a good way to organize things like this and show them to the user.

Because right now how will you launch different apps? Running scripts works but it could be nicer.

Maybe we can have "Software" or "App Launcher" fpga core that you can run and it provides the framebuffer + linux audio interface. And then a menu (console or gui with the framebuffer) to select from installed software. I know that it's not "needed" because you can launch apps from the scripts menu, but it might help separate the "Software" from the "Hardware" for people that think that it's important.

[Sorgelig]

it's too early to tell.
I will add script execution starting from OSD but executing in frame buffer.
This should be enough for the time being. Later will see. You also can launch some app selector as a script - so it can be a central hub for installed games/emulators.

Also it clearly distinguishes FPGA cores from soft emulators and won't confuse

[BBond007]

it's too early to tell.
I will add script execution starting from OSD but executing in frame buffer.
This should be enough for the time being. Later will see. You also can launch some app selector as a script - so it can be a central hub for installed games/emulators.

Also it clearly distinguishes FPGA cores from soft emulators and won't confuse

Sounds good. Definitely don't want to confuse or dilute the experience for people

I put in a PR for a very minor change to the Linux FrameBuffer code.

This is a redo of my previous videos with the changed kernel:

Broken Sword II (Redo) : Shadow of the Templars --> http://youtu.be/cvAkbFFmFOU
Monkey Island III (Redo) : The Curse of Monkey Island --> http://youtu.be/2H59sGAmZKI

[Locutus73]

My two cents on the topic:

• We can safely say MiSTer is already hybrid right now, and it's hybrid in the best possible way: emulating/replicating the gist of the original hardware in FPGA being cycle accurate and lagless, leaving some perimetral aspects to software, where they are best implemented, i.e. consolidating input devices and accessing media using different protocols. Minimig using USB mouse and keyboard accessing an HDD image on a network share is a marvelous example; NES using a Wiimote as a Zapper is another great example.
• ScummVM is not a software emulator, at least not as in software emulation of a retro hardware (i.e. MAME). SCUMM (Script Creation Utility for Maniac Mansion) games were always made-up of scripts and assets on one side and a software engine running those scripts using the assets on the other side. You could swap scripts and assets between different hardware platforms using the native engine back then. ScummVM is an open source implementation of the engine which runs native on ARM and executes the scripts, using the assets just like the original old game engines did. We can think to SCUMM games as a docx document: you can open it with Microsoft Word, but you can use Open Office too.
• ScummVM, as any other side project, can be easily self contained in a directory. @BBond007 you can put all the executables and libraries in a directory, i.e. /media/fat/ScummVM and tell the system to search for libraries there through export LD_LIBRARY_PATH="/media/fat/ScummVM". Ideally, IMHO there should be a single scummvm.sh which first checks if all needed files are there, when not found it downloads and extract them, then it sets up LD_LIBRARY_PATH environment variable (you can use PYTHONPATH for python libraries too) and then launches the main executable. So you have a single self contained script for installing and launching ScummVM and a single self contained directory which can be deleted leaving no traces...
  You can take a look to this code too https://github.com/MiSTer-devel/Scripts ... #L253-L296 for easily downloading and extracting DEB armhf repositories: maybe you don't need to compile and host executables and libraries at all; I use this trick whenever I can.
• Personally I'm always open to (free) options, especially if self contained and well performing. But I see there is some controversity here so I'll leave the final word on including a self contained scummvm.sh in the updater to Sorgelig.
  The options are:
  a) including it, so the updater will download and update it (I mean just the script, not installing the whole ScummVM which will require actually executing the script)
  b) including it, but commented; it will be up to single users uncommenting it (in the future there will be a dialog based GUI for that)
  c) not including it at all
  It's up to Sorgelig the final word.

Regards.
Locutus73

[Locutus73]

This should be enough for the time being. Later will see. You also can launch some app selector as a script - so it can be a central hub for installed games/emulators.

Indeed... as I wrote in a previous post a single script can handle installing (when not installed) and launching whatever software in a self contained directory including all needed dependancies and libraries.
Scripts directory can (I'm thiking to that since time) organized with subdirectories... it's already crowded, maybe single value ini scripts will be moved to the superseeded repository dir (which won't be downloaded), but I'm open to any hint/idea.
We can even have a script which acts as a front end, but personally I think it's useless, Scripts menu is already a front end for browsing and executing files.

Regards.

Locutus73

[jayp76]

I would like to see ScummVM on the MiSTer. It's not like putting a NES emulator on the MiSTer. I find it also easier to use instead of DosBox to play the classics. There seems to be interrest on ScummVM, so why not. I like that there is a discussion on these topics, so i am pretty sure that the MiSTEr won't be watered down by flooding it with software emulators. I think that won't happen. The MiSTer is not only an FPGA, it is also a HUB of Games and Systems. That's why i think ScummVM is welcoming addition.