Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support for new commercial Roms 3.1.4, 3.2, 3.2.1 #567

Open
sprudel79 opened this issue Dec 12, 2022 · 6 comments
Open

Comments

@sprudel79
Copy link

Hi project team,
thank you so much for all the work spent in this great project, as a Amiga fan since the 80s your work means a lot to me!
I would like to request to support the latest available commercial Roms (versions 3.1.4, 3.2 and 3.2.1) in the Emulator setup (definitely as optional).
In my setup I've been using Retroarch frontend to use the PUAE emulator and I don't find a straightforward way to use e.g. ROM 3.2.1 instead of ROM 3.1 because in the core options shown in Retroarch the default model presets and roms are available.

Thanks in advance and keep up the good work!

@sonninnos
Copy link
Collaborator

Does even WinUAE accept them, since they don't appear to be in the known ROM list..? And how are they supposed to be named in "WHDLoad" style (kick[version].[model]) and Amiga Forever style (amiga-os-xxx-yyyy.rom)?

And I don't have the way of testing those anyway, so maybe just use puae_libretro_global.uae (which will be appended to the generated config) or puae_libretro_[model].uae (which will replace the main model preset block) to set it manually when needed? What is the benefit in emulation anyway..?

Model preset block being for example with A500, which needs to exist in entirely in the override conf at the moment:

cpu_model=68000
chipset=ocs
chipset_compatible=A500
chipmem_size=1
bogomem_size=2
fastmem_size=0

But I guess that should be changed at some point to also do append like the global one, which will just overwrite the ones that are actually changed..

@sprudel79
Copy link
Author

Thanks for your reply. I was able to do a quick test yesterday and I have used the approach via puae_libretro_[model].uae to override the kickstart rom to be used (in my case model A1200).
The benefit you had mentioned for emulation is only if you want to use e.g. a HDF with the latest Workbench 3.2.1 that requires such a rom. For classic games via ADF/WHDLOAD it's of course not required.
I am not sure how WinUAE treats the latest ROMs since I am a Linux user but I am able to use them in FS-UAE.

@sonninnos
Copy link
Collaborator

FS-UAE uses pretty much the same known ROM list as WinUAE, but those won't prevent using custom ones.

The problem here is how the custom ones are supposed to be allowed to be selectable in the core option menu, since either

  1. We would have to know the hardcoded names of the files
  2. Scan available "known" ROMs to the list

And since Kickstarts are currently placed in global system, scanning everything and/or based on extension is out of the question. So they would only have to be kick* or amiga-os-* that get appended to the Kickstart option list.

@sonninnos
Copy link
Collaborator

sonninnos commented Jan 5, 2023

Okeydokey, with the latest change you only need to define kickstart_rom_file= in the model override uae conf.

Edit: Aaargh, it still gets replaced, whoops.
Edit2: Now it should work.

@sprudel79
Copy link
Author

Thanks @sonninnos , this will simplify things for me.

@a8bit
Copy link

a8bit commented Aug 30, 2023

Version numbers for the modern kickstarts are

46143 = KS3.1.4
47096 = KS3.2
47102 = KS3.2.1
47111 = KS3.2.2

So allowing the following files would maintain the naming convention and allow the new roms to be selectable.

kick46143.A500
kick46143.A600
kick46143.A1200
kick46143.A4000
kick47096.A500
kick47096.A600
kick47096.A1200
kick47096.A4000
kick47102.A500
kick47102.A600
kick47102.A1200
kick47102.A4000
kick47111.A500
kick47111.A600
kick47111.A1200
kick47111.A4000

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants