Core porting questions

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed May 23, 2018 6:27 pm

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
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Wed May 23, 2018 7:23 pm

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.

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed May 23, 2018 7:43 pm

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.

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.

GreyRogue
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Wed May 23, 2018 7:57 pm

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.

Some games, including Zelda, only use 8KB, but I don't think any of them care if they are used with 32KB images. I believe there are also some that use even smaller EEPROMs, but I'm not sure. There are also Japanese floppy disk games, but I'm not sure about their save sizes, and I don't think the core supports them currently.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed May 23, 2018 10:12 pm

New version has been released.

User avatar
Newsdee
Atari God
Atari God
Posts: 1227
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Wed May 23, 2018 11:10 pm

Woohoo! Been waiting long for this! Thanks a lot!

User avatar
Newsdee
Atari God
Atari God
Posts: 1227
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Sat May 26, 2018 4:22 am

How does the save work exactly?

I copied blank.sav into "ZELDA.sav" (for ZELDA.nes), but after I rebooted the save were gone.
I didn't see a menu option to save SRAM; is it done automatically?

NegSol
Captain Atari
Captain Atari
Posts: 268
Joined: Sat Dec 05, 2015 9:22 pm

Re: Core porting questions

Postby NegSol » Sat May 26, 2018 6:07 am

Works for me. Although I did press save state before quitting. Not sure if that is required but it worked. The name was saved. 8)

User avatar
Newsdee
Atari God
Atari God
Posts: 1227
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Sat May 26, 2018 8:17 am

Ah, I missed there was a Mister file that was one day older (24th). I see the menu now.

I'd suggest renaming the save/load options to e.g. "Restore saves / Backup saves", otherwise it will be confused with emulators "save states" which backup the entire RAM and CPU state.

In any case, I can play RPGs now! :)
EDIT: Fire Emblem Gaiden seems to work fine!

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Sat May 26, 2018 8:51 am

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. 8)

Yes, you need explicitly save the state before quit. Since, battery backed RAM is just generic RAM which can be written at any time, it's unclear when to save. Game can modify it thousands times per second which may result SD card to wear off if core will write to SD card every time.

User avatar
Newsdee
Atari God
Atari God
Posts: 1227
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Sun May 27, 2018 1:58 am

Would it be difficult to make it write on reset or when choosing another file? Many games actually advise to reset before shutting off, so would help remind about it.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Sun May 27, 2018 5:12 am

In current design it's impossible. Core doesn't know about new game loading - it just gets notification that new game has been loaded with new data already in place. It's just like you press the power off button and device has nothing to do.

Treat the saves as a bonus. Not as a main feature where the FPGA and ARM should run around.

GreyRogue
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Fri Jun 01, 2018 11:42 pm

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:
https://github.com/greyrogue/Menu_MiSTer

User avatar
nightshadowpt
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 110
Joined: Wed May 10, 2017 5:04 am

Re: Core porting questions

Postby nightshadowpt » Sun Sep 02, 2018 9:33 am

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:
https://github.com/greyrogue/Menu_MiSTer


This is interesting. Could it be implemented in the main branch?

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Sun Sep 02, 2018 12:08 pm

Actually there is a special option in ini to connect VGA output to HDMI scaler and get the same resolution and frame rate. It works for all cores.
Unfortunately it doesn't work for Menu core because it's compiled in LITE mode.
I will modify Menu, so it will allow to use HDMI resolutions on VGA through this option.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Sun Sep 02, 2018 1:04 pm

New Menu has been released.
you can use vga_scaler=1 in MiSTer section for all cores.
Or you can add separate section:

Code: Select all

[MENU]
vga_scaler=1

For menu only setting.
For developers: LITE versions ignore vga_scaler option and always output native core resolution through VGA.

User avatar
nightshadowpt
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 110
Joined: Wed May 10, 2017 5:04 am

Re: Core porting questions

Postby nightshadowpt » Mon Sep 03, 2018 4:03 am

Sorgelig wrote:New Menu has been released.


Wow... that was quick.

Thanks Sorgelig!

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Core porting questions

Postby ijor » Wed Oct 10, 2018 7:15 pm

I have two questions:

- Is there anyway to specify the name of an image to be loaded automatically on startup? Either by the user or by the core? I can see that MiSTer attempts to load a boot rom image that is probably designed for Arcade cores. But some platforms also need a ROM or BIOS, and sometimes even there are multiple options and versions.

- Is there a supported mechanism for the core to force MiSTer to display the menu? In many cases it makes sense because the core can't do anything useful until some files are loaded. I know I can play some tricks to emulate the OSD button. But I have some problems with that. I can probably workaround, but it might be better to have a standard method.

Thanks,

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed Oct 10, 2018 9:37 pm

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. Recently i've added composite RBF support which encapsulates the rom. This allows to use several RBF images with different rom inside but using the same common core name in OSD and all related settings. Mostly it's for arcade cores, but can be used with any other core.

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, but it's not updated yet. Do you use it in your core? If yes, then you can add rom choice there like it's done for Minimig.

Adding automatic OSD show upon loading is in my TODO list. With console cores you can rename your favorite game as boot.rom and it will be loaded together with core.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Core porting questions

Postby ijor » Thu Oct 11, 2018 2:55 pm

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.


That is a good solution for 8-bit platforms with a couple or a handful of small rom sizes. But in this case each ROM might be 192KB or 256KB. And they are too many. Can't embed all of them on the core, and the user might even provide his own ROM version.

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 ...


I know, but honestly, I don't like too much the idea of tying the core and custom code on MiSTer too much. It would be difficult to maintain. That worked nice for MIST and Minimig because the same developer maintained the core and the firmware. There might be a better option ...

One idea is to make the menu structure more flexible and allow a core to specify submenus. Complex platforms need a complex menu indeed.

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.

At the end that might be the easier way to maintain, but there is another more important reason that might need this mechanism. I have a couple of ideas for coprocessing at the Linux side. And IMHO, not sure there is any other way to implement specific Linux coprocessing that are tightly coupled with the core, without custom MiSTer apps.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Thu Oct 11, 2018 3:57 pm

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.

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
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Core porting questions

Postby ijor » Thu Oct 11, 2018 7:09 pm

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.


The code for INI configuration is not the main issue. 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.

Actually AtariST code in MiSTer is already present. Just need to polish it. Not much changes are required.


How can you say that? How you could possibly know what I need? Almost nothing that I need is already present.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3162
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Thu Oct 11, 2018 7:56 pm

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.

When these cores will start to appear there will be ability to load different ARM binaries.

ijor wrote:How can you say that? How you could possibly know what I need? Almost nothing that I need is already present.

i've thought you've ported the MiST AtariST core.

User avatar
Newsdee
Atari God
Atari God
Posts: 1227
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Fri Oct 12, 2018 12:59 am

Just to clarify, the firmware code in MiST has special handling for the Minimig and AtariST cores. i believe the Archimedes core as well but I can't remember. Every other core shares a common "backend" otherwise.

MiSTer firmware was ported from it so there is still that special handling in there, just dormant until a core.asks for it. It probably would need some.rework although the Minimig core would be a good example.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Core porting questions

Postby ijor » Fri Oct 12, 2018 2:00 am

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.


I know. But I am using a completely different interface than the original MiST core. Most of the MiSTer custom ST code inherited from the MiST firmware is useless for me. And most of what I need is not present on MiSTer at all.


Return to “MiSTer”

Who is online

Users browsing this forum: Hewhoisred and 1 guest