Sorgelig wrote:What exactly saved in Legend Of Zelda?
I guess it's not like Action Replay memory dump/restore when you continue play from exact saved state?
This save is some kind of legal save from Nintendo as i guess. So what is saved? Hall Of Fame?
As I see from the code, the saved memory has fixed size and only up to 32KB which can be greatly simplified using BRAM. So i want to optimize this part.
GreyRogue wrote:Save data is only updated when you create/name a character or when you select save from the menu. To bring up the menu you can either die or press start to bring up the inventory screen and press up+a on controller 2 from the inventory screen. Inventory and number of deaths will be saved. The easiest way to test, though is just create a new character and then verify the name is remembered after power on.
Sorgelig wrote:Thanks for tips! I didn't know how to save in the game.
Is it OK to assume that any game will save and restore 32KB? Just for simplification. With fixed size, it will be possible to implement saving slots later.
NegSol wrote:Works for me. Although I did press save state before quitting. Not sure if that is required but it worked. The name was saved.
GreyRogue wrote:I noticed the MiSTer menu.rbf only supports 50Hz resolution, which doesn't work over VGA on my monitor. I multiplied the four horizontal numbers in menu.sv by 5/6, and it changes the resolution to 60Hz and shows up in my monitor (if slightly off center). I'm not sure if this is useful to anyone or if there is a good way to send desired frame rate to the menu core (I put in a wire for the setting to switch between 50Hz and 60Hz, but nothing is driving it). If anyone cares, it's in my fork of the Menu:
Code: Select all
Sorgelig wrote:Currently only single boot.rom can be loaded at startup. Usually if some computer has different configs with roms, then all these roms are included in boot ROM and then using OSD options you can let the user to choose the config. Like it's done in ZX, Amstrad and many other cores.
If you are talking about Atari ST core then originally this core had support on ARM side (same as Minimig) and general core rules are not applicable as it's backed by custom code. MiSTer still has AtariST code inside ...
ijor wrote:But perhaps a better idea might be if you would support custom MiSTer branches maintained by the core developer. It could work something like this. If the user selects core "ACME" and there is a MiSTer-ACME app present, then you "exec" that custom MiSTer instead of calling "exec" for the standard MiSTer as you are doing now. Once the user is done with that, the custom MiSTer would exec the standard one.
Sorgelig wrote:MiSTer is developed with this option in mind. It's just not fully implemented yet.
Actually, once core's features are set, there changes in MiSTer ini are rare. It's not a problem to fork MiSTer and then provide pull request time after time.
Actually AtariST code in MiSTer is already present. Just need to polish it. Not much changes are required.
ijor wrote:As I said, there are other aspects, like coprocessing, that need much heavier customization of MiSTer. Not sure it is the right way anyway. Coprocessing (and hybrid emulation) is not a lightweight feature. Once multiple cores implement these features, not sure I would like to merge all of them in a single MiSTer.
ijor wrote:How can you say that? How you could possibly know what I need? Almost nothing that I need is already present.
Newsdee wrote:Just to clarify, the firmware code in MiST has special handling for the Minimig and AtariST cores ...
MiSTer firmware was ported from it so there is still that special handling in there, just dormant until a core.asks for it.