Feature Request - Support for _LLAPI cores and zipped rom files

pocomane / MiSTer_Batch_Control

Simple utility to control the MiSTer FPGA from the command line

48 stars 8 forks source link

Feature Request - Support for _LLAPI cores and zipped rom files #1

Closed relay01-foo closed 3 years ago

relay01-foo commented 3 years ago

It appears core files are only sourced from _Console. Would be cool if it could also source from llapi. Also, does this support zipped files. I only tried it with extracted files so I could be wrong that it doesn't already.

pocomane commented 3 years ago

Each core must be specifically supported, and I just added the ones I was interested to. It is very simple do add new core, it needs a single line in the system_list variable definition. If you want I could add them, but it would be great if you could provide the information described in https://github.com/pocomane/MiSTer_Batch_Control#core-supports (I just added it). The "Key Sequence" is the most important since I can not test it right now.

About the compressed roms: you could run them only if the core supports the compressed format. Mbc does not try to extract them by itsown.

relay01-foo commented 3 years ago

I was able to download source and compile with a modified path. I suppose then it should be possible to add more system names that include a different core path. Perhaps it would be possible to pull this system_list variable defination via a local text configuration file so they can be added and removed and tested without the need to recompile since the key sequence is easier to contribute to by community. Either way this solution was just what I needed. Trying to use a raspberry pi 'frontend' that sends launch commands to mister via sshpass. It's working well so far.

pocomane commented 3 years ago

I hoped that the github issue system could suffice to aggregate the "Community contributions". I did not use a config file because:

The utility is very simple, probably the configuration parse would be much bigger than the rest of the code
That infos are not really a "Configuration" since they ideally must be always the same (they can change only if some internal behavior of the MiSTer change)

However I agree with you that a simpler way to test new paths and key sequences could be useful. I will try in the next days to find a solution without an explicit configuration file. I was thinking to a special System, named "CUSTOM", that will get the required infos from environment variables.

relay01-foo commented 3 years ago

Yes a CUSTOM system would be great for testing and handling outlier systems or even make more advanced key sequences like to backup SRAM, etc.. I think there is already a key sequence stream function in there I haven't tested though.

I was able to modify the source to handle zip files but I essentially needed to add another 'FODO' to the end of the default key sequence. In my testing it was also helpful to slow down the delay between each key press call so I could visualize where it was failing.

I'm still tinkering with the utility now but I'll try to submit a pull request for some documentation of my findings when I get a chance.

pocomane commented 3 years ago

I implemented the CUSTOM system, so I close this issue. Moreover, now you can set the time between keypress by env vars; as you spotted, it could be useful for testing.

If there is a menu item for load the zip (other the ones for the roms that are not compressed), then I think it would be good to support them with the "Pseudo system". For example, right now, for the Nes there are actually two system: "NES" loads the nes roms, while "NES.FDSBIOS" loads the disks images.

As I said before, I would be very happy to add the details to load another core, if you could provide them in a github issue.

In any case, thank you so much for your report!