PlayStation Core Full Savestate Support

[Xbytez]

Amazing! So much talent! Robert you rock!

[FoxbatStargazer]

If there's enough FPGA resources to have save states on the PS1, it suggests that nearly every core could support them with enough effort.

Almost enough to make me crawl through the Genesis code.

[FPGAzumSpass]

In retrospective i can say that the costs for savestates on the PS1 are about 25%.
This is only for the core, not the framework.

So i wouldn't try it on any core that is above 65-70% logic usage already.

[Caldor]

In retrospective i can say that the costs for savestates on the PS1 are about 25%.
This is only for the core, not the framework.

So i wouldn't try it on any core that is above 65-70% logic usage already.

The savestate feature alone uses 25% of the FPGA logic? I figured the PS1 core would on its own be close to using the full logic space of the DE10-Nano?

Wont the sound then be a problem when it comes to having audio and the savestate feature in the core at the same time? Unless you already reserved the required space for it or something. Although I do not know how much of the space you already used.

[MostroW]

Robert just keeps on speeding along progress at high speed.

[FPGAzumSpass]

The savestate feature alone uses 25% of the FPGA logic? I figured the PS1 core would on its own be close to using the full logic space of the DE10-Nano?

Wont the sound then be a problem when it comes to having audio and the savestate feature in the core at the same time? Unless you already reserved the required space for it or something. Although I do not know how much of the space you already used.

25% for the core, nothing for framework, so about 20% of the FPGA, yes.

There is still ~20% of the FPGA left.
Biggest modules currently are GPU with 14%, GTE with 10% and CPU with 9%.

So the chances are quiet good for SPU to fit in, as i would assume it to be around 10% max as well.
CD might need another 5% for supporting Audio CDs and Memory Cards another 1-2%.

Overall it's tight, but i have good hope that i don't need to remove the savestate feature to fit everything in.

[hiddenbyleaves]

Unbelievable!

[NinjaWarrior]

Indeed good news!

[Phoenix]

Not really related but I'm not sure if my question deserves a topic on its own...

So if I understand correctly, ps1 core won't use 100% of DE10-Nano capacity, does it also mean that there is no risk of overheating?
Because that's my most fear about "3d" cores, I don't know if it could cause overheating because of the charge needed to run those games...

[RalphJB]

The savestate feature alone uses 25% of the FPGA logic? I figured the PS1 core would on its own be close to using the full logic space of the DE10-Nano?

Wont the sound then be a problem when it comes to having audio and the savestate feature in the core at the same time? Unless you already reserved the required space for it or something. Although I do not know how much of the space you already used.

25% for the core, nothing for framework, so about 20% of the FPGA, yes.

There is still ~20% of the FPGA left.
Biggest modules currently are GPU with 14%, GTE with 10% and CPU with 9%.

So the chances are quiet good for SPU to fit in, as i would assume it to be around 10% max as well.
CD might need another 5% for supporting Audio CDs and Memory Cards another 1-2%.

Overall it's tight, but i have good hope that i don't need to remove the savestate feature to fit everything in.

STOP!
I can only get so erect!

[Chris23235]

Not really related but I'm not sure if my question deserves a topic on its own...

So if I understand correctly, ps1 core won't use 100% of DE10-Nano capacity, does it also mean that there is no risk of overheating?
Because that's my most fear about "3d" cores, I don't know if it could cause overheating because of the charge needed to run those games...

Even if a core utilises 100%, it does not lead to overheat. The FPGA part of the DE 10 always runs cool. The heat comes ftom the ARM CPU running at fullspeed all the time.

If you use your MiSTer you always reach maximum temperatures because of the ARM, regardless of the core you use.

[ToothbrushThreepwood]

Not really related but I'm not sure if my question deserves a topic on its own...

So if I understand correctly, ps1 core won't use 100% of DE10-Nano capacity, does it also mean that there is no risk of overheating?
Because that's my most fear about "3d" cores, I don't know if it could cause overheating because of the charge needed to run those games...

Even if a core utilises 100%, it does not lead to overheat. The FPGA part of the DE 10 always runs cool. The heat comes ftom the ARM CPU running at fullspeed all the time.

If you use your MiSTer you always reach maximum temperatures because of the ARM, regardless of the core you use.

And these heat levels are harmless, even without heatsink and fan. Worst case, a few cores with imperfect timings may bug out due to elevated temperatures, but there is zero risk of frying any hardware.

[Phoenix]

Thanks a lot for your answers, what a great community!

[held]

Brilliant

@FPGAzumSpass: Just an idea: send bugreports with savestate from the OSD ?

[FPGAzumSpass]

No bugreports for now please, but when the core gets more stable, providing a savestate BEFORE a bug happens (not when game is already crashed) is the prefered way.

[Caldor]

The savestate feature alone uses 25% of the FPGA logic? I figured the PS1 core would on its own be close to using the full logic space of the DE10-Nano?

Wont the sound then be a problem when it comes to having audio and the savestate feature in the core at the same time? Unless you already reserved the required space for it or something. Although I do not know how much of the space you already used.

25% for the core, nothing for framework, so about 20% of the FPGA, yes.

There is still ~20% of the FPGA left.
Biggest modules currently are GPU with 14%, GTE with 10% and CPU with 9%.

So the chances are quiet good for SPU to fit in, as i would assume it to be around 10% max as well.
CD might need another 5% for supporting Audio CDs and Memory Cards another 1-2%.

Overall it's tight, but i have good hope that i don't need to remove the savestate feature to fit everything in.

That is great to hear Amazing work.

[held]

No bugreports for now please, but when the core gets more stable, providing a savestate BEFORE a bug happens (not when game is already crashed) is the prefered way.

Let me clarify what I mean, because I did poorly in retrospect.

Is it possible to add two functions to the core menu:

• update option, to download and install the latest version of the core
• bug-report option, to file a bug report *in the future*

This means for us users:

• we can easily send a bug report *in the future* from the couch
• we don't have to think about what information to provide to the dev except maybe a comment such as: "open left door", "pick up 5 stars", "when the timer expires" and the like.
• this prevents mistakes being made on our side

and this means for the dev:

• dev has 100% control over when bugs are reported (by dis/enabling the bug-report option)
• dev has 100% control over how bugs are reported, what information is send/needed (bios version,disc serial,core version, snapshot)
• bug-reports are always made with the latest core (at the time) or the bug-report option is disabled
• chance of reproducibility is high because users are less likely to make mistakes

[Cebion]

Why would such a thing ever be in a core?!

[RealLarry]

Is it possible to add two functions to the core menu:

• update option, to download and install the latest version of the core
• bug-report option, to file a bug report *in the future*

[sarcasm] Great idea! Additionally a full blown KDE setup and Thunderbird for mailing the bug reports! And a flux capacitor!1!! [/sarcasm]
No, boy, nice intention, but nothing for a core.

[MostroW]

i'm guessing if Robert (or any other core devs) really want some user input about core features they will query people for this?

[Caldor]

Is it possible to add two functions to the core menu:

• update option, to download and install the latest version of the core
• bug-report option, to file a bug report *in the future*

[sarcasm] Great idea! Additionally a full blown KDE setup and Thunderbird for mailing the bug reports! And a flux capacitor!1!! [/sarcasm]
No, boy, nice intention, but nothing for a core.

Also, once the core has been released it will become part of the normal "update" flow for the MiSTer that updates all the cores. Well, that is how it usually goes at least. As long as a core is beta, we have to be happy if we can get core updates without having to build it ourselves, and this core now has nightly builds, on the official Discord MiSTer server group. I think there is a link on the forums somewhere, or maybe in the FB group.

When it comes to bug reports, that will probably be done on the GIT and there will probably be some guidelines on how to do bug reports.

[FPGAzumSpass]

A proper bug report requires a thinking user, that's nothing that can just be automated.

For this year, i have enough open bugs. When i start a new bugfix phase next year, I will open a thread and ask for specific bugs and tell what info is required.

It's great the community wants to help, and I'm more than willing to take this help to make the core stable and working as fast as possible.

[held]

@RealLarry:
Who said anything about email?
I like constructive feedback, but if you start answering your own made up sarcastic hypothetical question by not reading properly, and then start insulting people by calling them boy: "you are not helping anyone".

@Caldor:
I am familiar with the update_all script, but the daily's aren't included. And to download it every day through a terminal, I though to be kind of cumbersome. So I thought: automation. Oh well.

@FPGAzumSpass:
Thinking users?, I did not know the requirement was that steep I still think it was a great idea, but there is hardly a point in arguing with a dev.

[Neocaron]

@RealLarry:
Who said anything about email?
I like constructive feedback, but if you start answering your own made up sarcastic hypothetical question by not reading properly, and then start insulting people by calling them boy: "you are not helping anyone".

@Caldor:
I am familiar with the update_all script, but the daily's aren't included. And to download it every day through a terminal, I though to be kind of cumbersome. So I thought: automation. Oh well.

@FPGAzumSpass:
Thinking users?, I did not know the requirement was that steep I still think it was a great idea, but there is hardly a point in arguing with a dev.

I think you overthink it. Up until this point this was not necessary for any core, and it never stopped the bugs to be squish. So don't worry too much about it. Once the core is almost done, people will leave feedback the way they always do and the core will be nice and shinny. The thought was still good, but it's just not applicable for the Mister project in general. Cheers!

[RealLarry]

@RealLarry:
Who said anything about email?
I like constructive feedback, but if you start answering your own made up sarcastic hypothetical question by not reading properly, and then start insulting people by calling them boy: "you are not helping anyone".

@Caldor:
I am familiar with the update_all script, but the daily's aren't included. And to download it every day through a terminal, I though to be kind of cumbersome. So I thought: automation. Oh well.

@FPGAzumSpass:
Thinking users?, I did not know the requirement was that steep I still think it was a great idea, but there is hardly a point in arguing with a dev.

I think you overthink it. Up until this point this was not necessary for any core, and it never stopped the bugs to be squish. So don't worry too much about it. Once the core is almost done, people will leave feedback the way they always do and the core will be nice and shinny. The thought was still good, but it's just not applicable for the Mister project in general. Cheers!

Copy that, thanks for these wise words and sorry to @held if I've pissed you off - but there were these [sarcastic] tags for that, meaning Don't really take my words seriously.
I'm co-authoring and co-developing hard- and software for the MiSTer project and we love and need feedback from users, but there are "the usual channels" like this forum and github repos for that, therefore no need for Extrawurst

[Caldor]

@Caldor:
I am familiar with the update_all script, but the daily's aren't included. And to download it every day through a terminal, I though to be kind of cumbersome. So I thought: automation. Oh well.

Why through a terminal? I download it on my computer and copy it to my MiSTer through FTP.

[held]

I think you overthink it. Up until this point this was not necessary for any core, and it never stopped the bugs to be squish. So don't worry too much about it. Once the core is almost done, people will leave feedback the way they always do and the core will be nice and shinny. The thought was still good, but it's just not applicable for the Mister project in general. Cheers!

I did not mind the idea being turned down, only the sarcasm that came with it.

.. and sorry to @held if I've pissed you off - but there were these [sarcastic] tags for that, meaning Don't really take my words seriously.
I'm co-authoring and co-developing hard- and software for the MiSTer project and we love and need feedback from users, but there are "the usual channels" like this forum and github repos for that, therefore no need for Extrawurst

Accepted

I figured an external call from a core to a local git client would be a practical solution.
Preventing all the manual labor and errors that come with that.

Moving on

[held]

@Caldor:
I am familiar with the update_all script, but the daily's aren't included. And to download it every day through a terminal, I though to be kind of cumbersome. So I thought: automation. Oh well.

Why through a terminal? I download it on my computer and copy it to my MiSTer through FTP.

That's fine too. I download it directly to the place where it needs to be by using the terminal. If there was a link to the latest version, it could be added to the user script. There is hardly a point in downloading it every day manually (although I really appreciate that its pre-compiled). I just want to turn on the MiSTer and it grabbing the latest test core, so I don't have to.

[Caldor]

@Caldor:
I am familiar with the update_all script, but the daily's aren't included. And to download it every day through a terminal, I though to be kind of cumbersome. So I thought: automation. Oh well.

Why through a terminal? I download it on my computer and copy it to my MiSTer through FTP.

That's fine too. I download it directly to the place where it needs to be by using the terminal. If there was a link to the latest version, it could be added to the user script. There is hardly a point in downloading it every day manually (although I really appreciate that its pre-compiled). I just want to turn on the MiSTer and it grabbing the latest test core, so I don't have to.

I think you might be able to use this to download updates by script, but you need to make the script yourself I guess:
https://github.com/MiSTer-unstable-nigh ... older.json

Its a json file with a list of all nightly releases and Peips MiSTer PS1 core was added to this afaik.

image_2021-12-11_155518.png (24.83 KiB) Viewed 18801 times