Added new roms and comments to M20 hash file

[eberhab]

Added more game roms to the M20 hash file. This should now be a more or less complete list of all the games that are available for the M20.

Also added a comment about a common issue with some of the already existing bootable system roms and how to fix it.

[ghost]

are the disk images in question bad 'missing track 0' or actually just not bootable disks, that instead require you to boot from something else first?

if the former, any idea how that happened? it seems a remarkably specific problem, rather than one I'd expect to see repeated multiple times.

[eberhab]

Yes, it is indeed a specific problem with this system, which uses mixture of FM/MFM encoding on the floppies. Usually PC controllers could not read the FM encoded first track, resulting in the 4kiB to be skipped during imaging. This is actually the case for the majority of the images. Floppies with a missing first track do not boot or boot only partially. More details can be found in the cited article in the comment. I have tried to write this down in even more detail here: https://github.com/eberhab/m20/blob/master/emulation_with_mame.md#the-anatomy-of-m20-floppies-and-mame-images

The new roms added with this PR do not have this problem. They all have an intact first track which was created using MAME itself.

Apologies for the second commit. The xml seemingly worked in Mame. I did not realize that there was a validate function. A few issues have been fixed. The file should now be in working order.

[cracyc]

A little more discussion of this can be found at https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=100146#Post100146 .

[eberhab]

Thanks for the questions and comments. I have added the link to the forum discussion to the comment about the track0 issue, since it is the original source. Anything else I can do to improve this?

Thanks for considering the addition. From my end this would be good to go.

[eberhab]

I have removed all the new game disc creations for now since they were not original floppies and I think in hindsight not suitable for the official sofware list. The main work of this PR is now:

• Imaged a few more original floppies, including the FM track
• Checked existing images and indiviually mark them as good/ bad/ missing FM
• Add some more individual comments about differing formats and if the disk is bootable or needs separate pcos

[cuavas]

Why have you changed the sizes of data areas? It’s ignored by the “file” loaded used for floppy formats, but required to be at least as large as the size of the media image file for validation. The convention is to set it to the actual size of the file.

[cuavas]

There’s no need to add disambiguation text if there aren’t multiple versions.

[eberhab]

The olitest.img with crc 7519913c does exist. What's the recommendation here? Should be added or ignored?

[eberhab]

Concerning the file/ are sizes, are these conventions written down somewhere? The only guideline I could find does not contain info about the sizes, nor about the baddump and/ or info fields: https://docs.mamedev.org/contributing/softlist.html

I had changed the dataarea sizes to match the actual raw-sectors size. Will change the dataarea size to match the file sizes.

[eberhab]

Again thanks for the thorough review. Updates:

• Converted comments into usage info tags
• Improved alt notation for consistency
• Changed dataarea size to match rom size
• Use bios version by name instead of number

Open questions:

• How to deal with (checksum-)identical images in different formats (e.g. imd vs. imd). Add both or only keep the (suspected) original?
• What qualifies a "working" image? Should we list images based on their current state, or assuming that the user has fixed the track0 issue?

[cuavas]

How to deal with (checksum-)identical images in different formats (e.g. imd vs. imd). Add both or only keep the (suspected) original?

I think in general it’s fine to keep just the best-quality dump when there are two dumps of identical disks.

What qualifies a "working" image? Should we list images based on their current state, or assuming that the user has fixed the track0 issue?

It should be based on the current state.

[Tafoid]

@eberhab
Seeing as this has been accepted, the images should be made available to the dev team (or probably should have earlier).
In any case, please provide the data (or links to the data) so that this software list submission can be verified - using the email detailed HERE.

Thanks for your contributions!