x68k_flop.xml: add 11 dumps from original disks

[rzero9]

New working software list additions

Armored Trooper Votoms - Dead Ash [krugman]
Die Bahnwelt [krugman]
First Crisis - Ma-Jin no Toubou (v1.00) [krugman]
Gaudi - Barcelona no Kaze [krugman]
Hanafuda Hourouki [krugman]
Knight Arms - The Hyblid Framer [krugman]
Star Cruiser [krugman]

New not working software list additions

Continental [krugman]
Laplace no Ma [krugman]
Video Game Anthology Vol. 2 - Atomic Runner Chelnov [krugman]

Software list items promoted to working

Die Bahnwelt (cracked) [crazyc]

Replaced software list items

Pretty Doll [krugman]

All of these are copy-protected except First Crisis (it's a doujin release) and I have checked that all the working ones crash or complain if you try to run them from a copy made with DISKCOPY (the Votoms protection trigger is actually pretty funny, it replaces all the graphics with silly sprites), so I'm reasonably sure that MAME is emulating everything needed for the protection, at least for those.

About promoting Die Bahnwelt to working: I have tested it in old versions and indeed it didn't work at all (didn't recognize its own system disk). I haven't traced the exact commit, but it got fixed between 0.236 and 0.237, so I'm pretty sure that it is b8cd4f0, since I haven't found anything else related to the 765 around that time.

[cracyc]

Chelnov has two sector headers in the gap one on side 0 and one on side 1. The side 0 check has the string "CHELNOV" followed by some weak bits that it overreads and expects to be different. The side 1 check is simple and passes. I don't think that the mfm format can handle the side 0 check and if it's similar to the fm towns columns or dos lemming, mame might not currently be able to handle it at all. Continental is similar except on cyl 1 rather than 0 and the string which is "010-001" contains the weak bits. Laplace also similar, on cyl 0 and the string is "HPR-0107".

[cuavas]

So if these games use copy protection that can’t be supported by the format the dumps are in, should they just be rejected as bad dumps? It doesn’t seem productive to include dumps that we know don’t represent the content of the media adequately in the first place. That’s just propagating bad dumps.

[cracyc]

If it's true that mfm can't properly represent this protection (again I'm not certain of that), then we should figure out what can. The columns fmtowns that came from rzero9 for example was converted from a kryoflux stream file which diskblitz was able to use to understand it. Mame can't load kryoflux stream files but I don't know what to convert it to that mame can load and can support the protection.

[AlKossow]

Can't .mfi represent this? OG?

[AlKossow]

Just was talking to Tom (TD-Linux) about this since he is familiar with the protection. He and OG should probably talk. They are both on the Applesauce discord

[cracyc]

Was wrong about laplace. The copy protection is almost the same except it doesn't check for weak bits it only checks the string so it passes. It's not working because the data disk has to be copy protected or it rejects it and same for the game disk. Mounting it read-only doesn't work, disk image has to be read-only on the host filesystem.

[rb6502]

Copy-protected disks requiring themselves to be write-protected is common enough that we should probably support it in software lists somehow.

[einstein95]

Aren't images loaded from inside zip files (which is how most people store software list items) mounted read-only by default?

[rzero9]

Just to address a couple comments:

If the HxC MFM format can't represent that kind of protection, and there's no alternative, I'm OK with removing the Chelnov dump for now. The original SCP flux files are available, so they can be re-converted at any time if/when we figure that out.

As for write-protecting disks, as far as I can tell from experience, MAME treats softlist entries as "writing is allowed, but any changes you make to the virtual disk are not written back to the files on eject/exit", while mounting loose files read-only is actually supposed to be read-only from the perspective of the emulated system. But in this case, even extracting the files and specifically mounting them read-only doesn't work.

[angelosa]

As for write-protecting disks, as far as I can tell from experience, MAME treats softlist entries as "writing is allowed, but any changes you make to the virtual disk are not written back to the files on eject/exit", while mounting loose files read-only is actually supposed to be read-only from the perspective of the emulated system. But in this case, even extracting the files and specifically mounting them read-only doesn't work.

Correct: for all purposes they are in a mixed mode where the lock is off and writing is allowed, until you disk swap it out so that image writes never happens. This approach doesn't always work in places where the lock is expected to be on, i.e. it happens in Robocop for ST and The Return of Ishtar for PC-8801, and should probably be ticketed in an actual issue.

[rzero9]

I have removed the Chelnov entry for now to avoid confusion. By the way, I also tried to convert it directly from SCP to MFI with Applesauce (I think it's the only way to convert from other flux formats to MFI), but the X68000 boot ROM just gives me an "unreadable disk" message, so no luck there.

[rzero9]

It's been a while since I opened this, so I added a couple more dumps that have showed up since then. Gaudi and Hanafuda Hourouki are the original protected versions, both working fine as far as I can tell; Pretty Doll is a replacement because it contains exactly the same game data as the existing dump, but the third disk has a different sector structure for the "empty" parts of the disk, after track 61, that the DIM format couldn't deal with. It probably doesn't change anything in practice, but it represents the original disk better.

If there's anything else I need to address in order to merge this PR, please let me know.