Feature Request: Instant Play, Instant Resume

[Akuma]

I saw the CRT conversion of C64 ROMS, to reduce loading times. Now lately I'm catching myself using the 1st save-state slot in the PSX-core for instant loading. But it still requires two steps and you lose the use of one of the slots.

So I would like to request:
1. Instant Play feature: an extra save-state slot for instant loading
2. Instant Resume feature: autoload a certain save-state when selecting a game

Comments thoughts ?

[held]

Do you want to skip all the intro's and loading sequences?

[Akuma]

Apparently its only me who likes this idea, ohh well.

[FPGAzumSpass]

It's not really feasible to do these things in the core, it would need to be a special handling from HPS.

I also do this when testing games and have e.g. main menu at any savestate slot, but it's kind of hard to justify the effort and complexity to have a special handling there.

[Caldor]

It's not really feasible to do these things in the core, it would need to be a special handling from HPS.

I also do this when testing games and have e.g. main menu at any savestate slot, but it's kind of hard to justify the effort and complexity to have a special handling there.

Maybe instead of a new special save slot, it could be an option to load save slot 1 when booting the game, or if possible, the newest save? I guess both solutions would require some HPS and also while it would be a nice feature... its not really that many clicks it requires to manually load. If its something you want to do every time it adds up I guess.

At any rate its a nice to have feature.

[Akuma]

It's not really feasible to do these things in the core, it would need to be a special handling from HPS.

I also do this when testing games and have e.g. main menu at any savestate slot, but it's kind of hard to justify the effort and complexity to have a special handling there.

I cylce a lot through games too, so you bump into the load times automatically. Unless I want to experience that again for some reason, my default in slot 1 is main menu. It seems I do not understand, how things are working between the core and HPS. So I thought about it for a couple of days, would this be doable:

After loading, when waiting on user input: could a savestate automatically be triggered for slot 1 when its empty?

Maybe instead of a new special save slot, it could be an option to load save slot 1 when booting the game, or if possible, the newest save? I guess both solutions would require some HPS and also while it would be a nice feature... its not really that many clicks it requires to manually load. If its something you want to do every time it adds up I guess.

That would also be really nice

[aberu]

It seems I do not understand, how things are working between the core and HPS.

The Cyclone V System on a Chip processor that is on your DE10-Nano has a "Hard Processor System" (HPS) on one side an a Field Programmable Gate Array (FPGA) on the other side.

The HPS has a Dual Core ARM Cortex A9 MPCore processor with on-chip memory, pll, interfacing and support components, and an SDRAM L3 interconnect, as well as a flash memory controller and a few other things.

The FPGA side has the logic cells (what FPGA are known for), pll, a control block, direct connections to the DE10-Nano's GPIO, and some transceivers (transmit/receive) to send and receive data back and forth with the HPS system.

A game is loaded off of your MicroSD card and into the DDR3 memory on the DE10-Nano by the HPS system (as instructed to do so by the Linux image and the Main MiSTer binary that runs on it). The FPGA core gets signals from the Main MiSTer binary that it reacts to, which allows it to communicate with that DDR3 memory through the HPS.

Currently the FPGA core gets loaded when you select and load the PSX.rbf file, the Linux system and the MiSTer binary work together to feed that data to the FPGA's system in order to program the FPGA's logic into the correct design. Now the FPGA is behaving as a simulation of a PSX's logic, so-to-speak.

Then the HPS side of things allows the FPGA to look to the right cd_bios.rom file in /games/PSX, and once it's loaded that into SDRAM (I think this goes in SDRAM? can't remember, Robert would know, but doesn't matter too much), then the PSX core knows to boot. Then it's like a PSX, it needs a game inserted, so you load a CHD, which loads the CHD file into DDR3 quickly, HPS tells the FPGA it's done and it trickle-feeds the data from the virtual image of the CD-ROM to it, as needed and requested by the FPGA.

The problem, from what I can tell, is HPS would need to remove and automate a lot of the user feedback, the core might not need any rewriting at all to do what you are asking, it would have to be someone like Sorgelig substantially rewriting how the cd loading, bios loading, etc... all works, and then would have to add a way to tell the core to load the savestate automatically instead of manually.

This seems like a lot of work all for the sake of someone pressing a few buttons, but I think that software emulators make it seem so "easy" that people naturally wonder why it can't easily be done on the MiSTer as well. For one thing, I don't think it's that easy in software, but it is certainly harder in hardware design languages combined with the huge amount of C code that goes into the MiSTer binary doing what it does so well already.

Sorry to anyone reading this if it's not perfectly accurate.

[Akuma]

The problem, from what I can tell, is HPS would need to remove and automate a lot of the user feedback, the core might not need any rewriting at all to do what you are asking, it would have to be someone like Sorgelig substantially rewriting how the cd loading, bios loading, etc... all works, and then would have to add a way to tell the core to load the savestate automatically instead of manually.

This seems like a lot of work all for the sake of someone pressing a few buttons, but I think that software emulators make it seem so "easy" that people naturally wonder why it can't easily be done on the MiSTer as well. For one thing, I don't think it's that easy in software, but it is certainly harder in hardware design languages combined with the huge amount of C code that goes into the MiSTer binary doing what it does so well already.

Thank you for that detailed explanation. I appreciate the time you put in to write it. As I see it now, the request would require some custom "scripting language".That's way too much effort to automate some of my frequently used button sequences.

Shelving the request