Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07279 Crash/Freeze Major Always Apr 10, 2019, 14:50 Apr 13, 2019, 18:45
Tester StHiryu View Status Public Platform MAME (Unofficial Binary)
Assigned To Edstrom Resolution Fixed OS Windows Vista/7/8 (64-bit)
Status [?] Resolved Driver amstrad.cpp
Version 0.208 Fixed in Version 0.209 Build 64-bit
Summary MESS-specific 07279: cpc6128: Fatal error when loading some disk images
Description This message appears when you mount some .dsk images (Comando Tracer (S) (1988) (CPM) [Original].dsk from Cpc-power):
Fatal error: Device 3" single-sidded floppy drive load failed: Incompatible image format or corrupted data
Steps To Reproduce 1-Launch cpc6128
2-Load image with |CPM
Additional Information Worked in 0.207
Regression Version 0.208
Affected Sets / Systems cpc6128
Attached Files
There are no relationship linked to this issue.
User avatar
Apr 10, 2019, 21:48
edited on: Apr 10, 2019, 21:48
Not sure how to resolve this. The error is supposedly correct and was added with this commit:
MAME crashed if user was trying to load a dsk image with more heads or tracks than disk device supports.
Now the error 'Incompatible image format' is raised.

Now, if I load this image with a 35ssdd device, it loads as before.
> mame64 -upd765:0 35ssdd -flop1 "Comando Tracer (S) (1988) (CPM) [Original].dsk"

Hopefully some Dev can clarify as default drive states for machines are sometimes hard to define. It is possible that 3.5" images are the default now and if you want 3", you need to change the slot device settings.
User avatar
Apr 10, 2019, 22:10
Just take a look into the amstrad cpc6128. At least in mameui 0.208 it comes with two devices. One in the slot 1 (3ssdd) throwing the error, and other in the slot 2 (35ssd). As you said the second slot loads fine. My question is why two flopply drives of different type? Should be two slots of 35ssd or two of 3ssd I suposse. As far I can tell, the floppy drives for the amstrad should be 35ssdd.
User avatar
Apr 10, 2019, 22:23
edited on: Apr 10, 2019, 22:31
The first floppy drive on any Amstrad CPC is always 3", the second can technically be 3", 3.5" or 5.25". While hardware mods are available to flip the drive order around, there will always be at least one 3" drive. Disk software is typically sold on 3" disks.

This being said, a quick glance at the image doesn't suggest that it is not 3"
User avatar
Apr 10, 2019, 22:23
Thanks for reporting, I forgot about this: some original 3" disks has one additional blank track (43 instead 42) as protection scheme. I'll fix it.
User avatar
Apr 11, 2019, 20:55
The excess track is not the protection scheme but because the dumper has used a DD drive dumping too many tracks to fit on an SD floppy. The protection is usually on track 40 or 41, eg the 41st or 42nd track. I checked the tracks on these images just for fun and indeed only the one you used has 43 tracks:

./comando tracer (s) (1988).dsk: Size: 40 Cyls, 1 Head
./comando tracer (1989)(dinamic software)[t +2].dsk: Size: 40 Cyls, 1 Head
./comando tracer (1989)(dinamic software)(es)[cr two mag][t two mag].dsk: Size: 40 Cyls, 1 Head
./comando tracer (uk) (1988).dsk: Size: 40 Cyls, 1 Head
./comando tracer (s).dsk: Size: 42 Cyls, 1 Head <-------- this one loaded fine
./comando tracer (1989)(dinamic software)(es)[cr edr soft].dsk: Size: 40 Cyls, 1 Head
./comando tracer (s) (1988) (cpm) [original].dsk: Size: 43 Cyls, 1 Head <-------------- this one
./comando tracer (uk) (1988) (patch cpc+).dsk: Size: 40 Cyls, 1 Head
User avatar
Apr 12, 2019, 00:30
That is because the image used is the only original. All the rest are unprotected versions.
You always find 43 tracks on original software, not on cracked/unprotected versions.
User avatar
Apr 12, 2019, 21:02
Interesting, I have a few PCW original floppys here, just need to get my SD drive working so I can verify that. I have also ran some statistics on the images I got so far, of about 180 PCW images there were:

22 with 43 tracks, all made by CPCDiskXP v1.6
16 with 42 tracks, made by CPDRead v3.24, SAMdisk120716 or SAMdisk120814
10 with 41 tracks, made by CPCDiskXP v2.1 or CPDRead v3.24
135 with 40 tracks, made by SAMdisk190221, Make_DSK v2.8, (LIBDSK), (JOYCE), Disk-Info, CPDRead v3.24 or (c) 2011 Habi

Only CPCDiskXP v1.6 dumps 43 tracks and only CPDread v3.24 dumps different number of tracks. Just maybe could track 43 be a bug in CPCDiskXP v1.6?

If you find a different pattern for CPC dumps I'd be interested to learn about that, as I said I am looking at the PCW only at this time.

However, the MAME floppy image for 3" drives just have 42 tracks, my fix excludes track 43 and up, let me know if you find an image where this doesn't work on the CPC. The Tomahawk.dsk for PCW has protection on track 41 and stops working if I strip of the last track, it would be very interesting to have an image that has protection on track 43 or higher.
User avatar
Apr 12, 2019, 22:34
Som useful scripts if you are on Linux btw:

# My script for finding images with 43 cyls
find . -type f -name '*.dsk' -exec sh -c '
  for file do
    echo "$file: " `samdisk info "$file" | fgrep -A 2 -B 1 "43 Cyls"`
' sh {} + | fgrep "43 Cyls"

# My script for finding duplicates by the first 40 tracks
find . -type f -name '*.dsk' -exec sh -c '
  for file do
    echo -n `samdisk --cyls=0-39 view "$file" | grep -e "^0" | sha1sum` ; echo " - $file"
' sh {} + > shas.txt

# My script for finding unique creatiors for a certain number of tracks
find . -type f -name '*.dsk' -exec sh -c '
  for file do
    echo -n "$file: "; samdisk info "$file" | fgrep -A 2 -B 1 "40 Cyls"
' sh {} + | fgrep creator | sort -u
User avatar
Apr 13, 2019, 14:24
Thanks for scripts, I am on linux so I'll use them.

BTW, Samdisk also dumps 43 tracks. Image example for this issue (Comando Tracer (S) (1988) (CPM) [Original].dsk) has been dumped with SAMdisk120408.
There are also images with 43 tracks dumped by CPDRead (i.e: Pro Tennis (UK) (1986) (Spain retail version) [Original].dsk).
User avatar
Apr 13, 2019, 18:45
ok, just let me know if there is a problem with the current approach. Thing is that it is a bigger change if we actually need to load the last track(s) as they do not fit the buffer provided from the drive device internally. Can be fixed but only if the hardware actually supports it in which case a new drive variant should be added providing enough storage space.