openMSX wish list

Paladin (709)

07-01-2021, 19:45

Emulation of ZX Spectrum would help a lot when porting ZX games to MSX.... We could use all the benefits openMSX has to debug / analyse the ZX code.

Por ren

Paragon (1932)

07-01-2021, 20:49

I agree, a .dsk database would be pretty nice actually (keeping the clutter down)

Although (I don't know if such an idea has been discussed before?) personally I'm more an advocate of a self-contained (g)zipped package, that would combine a description with dumps of anything belonging to that release (a ROM, a disk, multiple disks, rom+disk, rom+tape, whatever). It could have it's own file extension.

It would be (very) nice if such a package could be read by a PC emu/tool, as well as e.g. SofaRun.

For descriptors I prefer Yaml. It could look something like this:

vspec: 1

title: Night Knight
type: game
abstract: You're playing Sir Bernard ...
date: 2019-05-..

credits:
  code: Juan J. Martínez
  gfx: Juan J. Martínez
  sound: Juan J. Martínez

package:
  rom:
    size: 32k
    mapper: normal
    filename: nknight.rom
    sha1: 42f79da674a8f5533abf6d85be116dc11cdd4114
    crc32: 3a7965de

msx:
  gen: 1
  ram: 16K

audio:
  support: psg

video:
  mode: [480i, 576i] 
  preferred: 480i 
  notes: (576i should be fine too ;-))

www:
  product: https://www.usebox.net/jjm/night-knight/

release:
  ver: 1.0.3
  date: 2019-05-18
  publisher: usebox.net
  notes: fixed minor bug

run:
  cart: rom

ico: R0lGODlhEAAQAJEAAL1pUMzMXAAFAAAAACH5BAAAAAAALAAAAAAQABAAAAIylI95ABb/lGAQBelmABe71ngGx3AiZYoT41EJ+5oVjFUq9DTdseF5yqN0ejtHkafCFAAAOw==

;-)

For PC use, it would be nice to have screenshot, box covers etc. as well, those could go in an 'extra' package. (Too big for MSX use obviously, unless brought down in size..)

What say you? :hannibal:

Por Grauw

Ascended (10713)

07-01-2021, 21:16

That’s a pretty nice idea I think. Also for ROM files. A decentralised manifest (descriptor).

That way, if I share a build of a game I could just release it in this format and I wouldn’t need to rely on either wonky autodetection, manual selection by the user, or a 3rd party database that is updated infrequently. People could just drop the zip on the emulator and it would read the mapper type from the manifest.

If the information would be used by and presented in emulators, I could imagine some people starting to make collections in such a format. Not only selecting mapper type, but also for example auto-selecting a suitable machine and extensions.

Por ren

Paragon (1932)

08-01-2021, 09:50

Cool → New MSX archive format (proposal / idea)

Por gdx

Enlighted (6116)

20-03-2021, 10:20

OpenMSX would be much nicer to use if it would save the last type of mapper entered manually when the Rom is not yet listed in its database (based on the file name not the checksun). Thereby newer Roms and those in development would be automatically detected subsequent launches. It should also be able to delete this temporary database.

Por sdsnatcher73

Prophet (3851)

20-03-2021, 10:39

Hmm nice idea! Privacy issues aside (which could be handled correctly) this data could also be uploaded to a central location and used to improve the database.

Por Manuel

Ascended (19316)

20-03-2021, 10:47

Gdx, as a workaround you could insert the ROM in the console, specify the mapper type there and use the history (hit up key) to quickly repeat that when the file is updated. Or do the same from your OS command line.

Por gdx

Enlighted (6116)

20-03-2021, 12:04

sdsnatcher73 wrote:

Privacy issues aside (which could be handled correctly) this data could also be uploaded to a central location and used to improve the database.

For this additional database to be efficient for the user, the type of mapper should be associated with the name of the file and not the cheeksum because for example when developing a Rom the cheeksum is different at each compiling/changes. So centralizing this data is not useful. Even more so, if you do not know the origin of the file.

Manuel, this method comes quickly tedious when you have to do several tests and especially also with other cartridges during several days.

Por wouter_

Champion (508)

20-03-2021, 12:35

@gdx: I can see why this could be useful. Though it's a niche feature, intended for developers. And IMHO this feature can be better (more flexibly) be implemented outside of openMSX.

As a developer you probably launch openMSX from some terminal (not from catapult). That terminal likely has built-in search capabilities. For example in bash type <CTRL>+<R> followed by mygame.rom and this gives the last command line which contained mygame.rom. Likely this was the openMSX command line which launched the ROM with the correct mapper type. As a bonus this will also select the correct MSX machine and extensions (if those are relevant).

Or alternatively, as a developer, you should have no problem withing a small shell script (or batch file?) that launches openMSX exactly how you want. Possibly even based on this database idea you had.

Por gdx

Enlighted (6116)

20-03-2021, 13:22

wouter wrote:

Though it's a niche feature, intended for developers.

I gave an example for developing but it would be useful for other situations. When a new Roms is released, people complain that the Roms is not recognized. You always have to wait for a new version of OpenMSX and remember the mapper type while waiting. Also I can't use the latest versions on my Mac. Same problem to translate a game or fix some bug. The people who do this are not necessarily developers. I use catapult and NekoLauncher and mainly blueMSX to debug because the interface is more user-friendly. I am a Sunday developer. I think this is a simple feature to add that will be of use to anyone who often tests new games. It's not a niche feature.