Idea/Proposal: ROM Headers for emulation

صفحة 3/6
1 | 2 | | 4 | 5 | 6

بواسطة Manuel

Ascended (17466)

صورة Manuel

11-01-2021, 19:50

One idea: I would expect the data from the database that Vampier maintains could be easily exported into a very compact format that is very easy and fast to read on FPGA. But I don't know much about FPGA implementations of software.

بواسطة Vampier

Prophet (2381)

صورة Vampier

11-01-2021, 19:53

Grauw - I don't want to be sidetracked by zip files - we need a header in the MSX ROMs - let's just get that sorted out - we can look at zip files as EXTRA functionality later. The base ROM is what I am talking about - it can have any thing embedded that you want. It will greatly benefit - I don't give a flying F Tongue about using a zip file. I love to argue with you but let's stick to discussing.

بواسطة tfh

Prophet (2678)

صورة tfh

11-01-2021, 20:07

ren wrote:

(prv: @tfh: I'm under the impression you're kinda avoiding me (since that 2019 Xmas quiz 'incident')? But please correct me if I'm mistaken Smile)

Well, to be quite honest: I would have to back to that thread to see what's it actually about, because I have no idea.

But seriously: what do you think you would achieve by making such a remark? Anything positive? Please enlighten me...

/edit 20:06/
OMG... You mean about that balloon question? You must be kidding! I was never angry there. A bit surprised about your reaction, that's it.

بواسطة Kitrinx

Supporter (6)

صورة Kitrinx

11-01-2021, 19:58

Manuel wrote:

One idea: I would expect the data from the database that Vampier maintains could be easily exported into a very compact format that is very easy and fast to read on FPGA. But I don't know much about FPGA implementations of software.

Yes it can, even with something as basic as a python script. A RIFF style format is much friendlier to FPGA's than MAME style zip blobs which are really only friendly to software emulators. It's very undesirable to add additional special conditions and processing to the main binary to accommodate a software-only format, akin to what things like MAME insist on using. MAME roms create huge headaches for us in general, so I'd hate to go down that road again.

بواسطة Grauw

Ascended (9569)

صورة Grauw

11-01-2021, 20:25

If the goal is to create a format for a very specific type of FPGA, let’s just clearly state it and change the topic title to be about that.

If the goal is to create a general purpose format which is usable on all platforms including emulators, real MSX-es, 1chipMSX, MegaFlashROM SCC+ SD, etc., then:

Grauw wrote:

This is very similar to this recent topic:

https://www.msx.org/forum/msx-talk/general-discussion/new-ms...

I think it’s a great idea to have a decentralised metadata format, so it’s really nice that people are thinking about this!

But I would suggest a more extensible format than a 256 byte header. There is much more potentially useful information that could be added than would fit in a fixed 256 bytes schema.

Also, in principle it’s applicable to more than just ROM; also DSK, DMK, CAS, etc. So there are benefits to having a separate manifest file. Use a text-based format for easy editing without special tools. Zip it together, throw in some screenshots if you like, and you got nice ROM packages.

This remains usable for tools that don’t support the format yet, just unzip to get the ROM file and look in the manifest to see what mapper type to use.

So I like the idea but I also think the approach described in the other topic has benefits.

Forget about the zip file for a moment if that triggers you. The key is a separate manifest file in text based format. Extensibility, don’t you see the benefits? Multi-format, don’t you see the benefits? Text based editing, don’t you see the benefits? Authoring is super annoying without.

Just look at the binary VGM format header, it started out as a simple binary header, but grew into a complicated mess. Manipulating them also requires a ton of dedicated tools.

p.s. A simple key-value text format is not any harder to parse than RIFF.

Vampier wrote:

I love to argue with you but let's stick to discussing.

I presented my arguments, but I don’t really see any response to it other than “text, zip, yuck, FPGA”. And the ideas I presented are ignored, discarded, seem to fall on deaf ears. Well, then I guess you don’t want a discussion? Then just do whatever you want, you don’t need opinions from others.

بواسطة Vampier

Prophet (2381)

صورة Vampier

11-01-2021, 20:17

Grauw I see the pros here - there are only pros (except for having to use more storage space)

but we can also include those in the format itself and zip the file. FPGA is going to be the future of accurate hardware emulation.

Having that said - we need a maintainer for the MiSTer FPGA core right now Syntax Infinity doesn't run correctly for example.

I'll open another topic for that Smile

بواسطة Kitrinx

Supporter (6)

صورة Kitrinx

11-01-2021, 20:28

Grauw wrote:

I presented my arguments, but I don’t really see any response to it other than “text, zip, yuck, FPGA”. And the ideas I presented are ignored, discarded, seem to fall on deaf ears. Well, then I guess you don’t want a discussion? Then just do whatever you want, you don’t need opinions from others.

Okay, well, you got feedback, and now you are deriding it. I am saying that a zip file format is something we would be unlikely to adopt, while a RIFF style format would work for both applications with little overhead. The down side is that you would have to use a tool to edit the header rather than writing xml in notepad. The up side is that it would be more cleanly encapsulated, have lower processing requirements, fewer idiosyncrasies, and be more universally accepted by tools/emulators.

Beyond this decision, it is just a matter of the technical specifics of how to demarcate size and type of data.

بواسطة Grauw

Ascended (9569)

صورة Grauw

11-01-2021, 20:53

A constructive discussion would go like this: “I don’t like zip because it can’t be read on-line without a large buffer and relatively complex and slow decoder, but a text format could work, however then it should be a simple format so that it’s easy to process. Maybe something like INI files but with a properly standardised grammar. You could delimit it from the ROM by a zero byte to have it in a single file?”

An even more constructive discussion would consider use cases other than MiSTer as well.

For example, the discussion in the other thread from three days ago (that this one duplicates and ignores) also mentioned topics like including CRCs, SHA1s, patches, cheats, release info, execution information, minimum MSX generation, required extensions, native refresh rate, etc. These are useful to both emulators and real MSX-es, e.g. to present to the user prior to or during loading, as well as providing the loader with more information about how to load and execute it.

Information about the mapper type is not the only thing missing for easy one-click usage, and ROM is not the only format that is missing such information, DSK and CAS are the same. People encode CAS loading instructions and ROM mapper types in filenames, yikes.

بواسطة Vampier

Prophet (2381)

صورة Vampier

11-01-2021, 20:56

We can have a 2 part discussion here - extra meta data that can be easily edited. Extra meta data as part of the ROM.

Grauw when I tell you that I see Kitrinx as an expert on FPGA as I see you an expert on MSX and your work on the VGM player is what Kitrinx does for the MiSTer. Her opinions should not be easily discarded - we are not trying to be combative but if Kitrinx says that it will be HARD to implement that without writing a computer in FPGA that runs the MSX core (at which point why not stick to openMSX?)

I feel strongly about the MiSTer project and I've spend a lot of time in it since I got 1 a year ago.

https://github.com/MiSTer-devel/MSX_MiSTer

The most important things you get in 1 package with a ROM are the game/program data in a ROM and the PCB that goes into the MSX. The Manual is not inserted into the MSX and can be embedded and optionally accessed. The zip file can be used to reduce the file size.

Also I never claimed this was my idea - even BiFi has been thinking about this for over a decade - so have I but there was never a good reason to do this.

بواسطة Grauw

Ascended (9569)

صورة Grauw

11-01-2021, 21:04

Vampier wrote:

Grauw when I tell you that I see Kitrinx as an expert on FPGA as I see you an expert on MSX and your work on the VGM player is what Kitrinx does for the MiSTer. Her opinions should not be easily discarded - we are not trying to be combative but if Kitrinx says that it will be HARD to implement that without writing a computer in FPGA that runs the MSX core (at which point why not stick to openMSX?)

Well, I can not smell that this person new to the forum is an expert on FPGA without any introduction.

صفحة 3/6
1 | 2 | | 4 | 5 | 6