Can it work with Olivetti M20 disks?

[raneri]

Hi, I'm asking to myself if Greaseweazle can write Olivetti M20 disks, that are 5.25 floppies in a particular format. Here are the system disks: http://www.z80ne.com/m20/index.php?argument=sections/download/wrm20/wrm20.inc
It seems to be very tricky because of the 0 track, since MF is not supported by all controllers. Here you will find more informations about this format: http://www.z80ne.com/m20/index.php?argument=sections/transfer/imagereadwrite/imagereadwrite.inc

[keirf]

Greaseweazle understands FM but it's not yet possible to specify a mixed format disk (FM on some tracks, MFM on others). Coming soon though I think!

[keirf]

Consider this done, see #261

[eberhab]

Thanks a lot for the question and all the hard work on the GW. It is very much appreciated. I came here via an internet search about reading M20 floppies, coincidentally just a couple of days after the feature was done. After ordering a GW, I continued to be lucky and I can already confirm that the following config for gw-tools v1.6 works perfectly:

# Greaseweazel v1.6 diskdefs.cfg for Olivetti M20 360 kB DD floppies
disk olivetti.m20
    cyls = 35
    heads = 2
    tracks 0.0 ibm.fm
        secs = 16
        bps = 128
        rate = 125
    end
    tracks * ibm.mfm
        secs = 16
        bps = 256
        rate = 250
    end
end

Reading (and writing!) an entire floppy is now as easy as:

gw read --diskdefs diskdefs.cfg --format="olivetti.m20" floppy.img

The resulting image file has 278 kiB. If one wants to use the image in MAME, one has to keep in mind that FM track0 is only 2 kiB, but MAME expects track1 to start at 4 kiB (probably because historically, a 4 kiB offset was introduced when track0 was skipped). So the image needs to be modified to account for this:

dd if=floppy.img of=floppy_padded.img bs=2048 count=1
dd if=floppy.img of=floppy_padded.img bs=2048 skip=1 seek=2

For writing a 280 kiB image file, the procedure needs to be reversed:

dd if=floppy_padded.img of=floppy.img bs=2048 count=1
dd if=floppy_padded.img of=floppy.img bs=2048 skip=2 seek=1

Happy imaging! :)

[keirf]

Thanks for the diskdef. I can add this as a built in config to next release.

Regarding track sizes in image files I think it may be very common for boot tracks to be padded out where they are FM and contain less data than regular tracks? Currently Greaseweazle and FlashFloppy never pad tracks in IMG files. But if there is a de facto standard around this I could add an option to both such as filelen to allow size of a track in the IMG file to be explicitly specified. What do you think? If supported, would you have used it in your diskdef?

[eberhab]

Thanks for the reply! I would be very happy to see this added to the official diskdef.

Concerning the padding option: Yes, I would have used it. I also thought about it but didn't dare to ask. Thanks a lot for suggesting it. I think it could be very useful. 100% of the M20 *.imgs that I am aware of have a padded FM track (including the ones linked in the OP).

One more thought though, when generating m20 sectors image with MAME, it pads the individual sectors, rather than the whole track. If it does not make it too complicated, it could make sense to have both options.

[keirf]

Interesting. I wonder how common is padding per sector like MAME rather than padding at the end of the track? Can MAME handle both?

I was only considering adding the track padding but at least in Greaseweazle both could be an option. In this case I suppose you would only have used the track variant however.

[eberhab]

Im am not in a position to fully answer the mame related questions. I suspect it's an M20 specific issue, since mame has a dedicated floppy definition for the M20. Without going into too much detail, with the M20 floppies it does not seem to matter, because only the first sector contains data anyways. So both padding approaches will create the same amount of zeros. So, yes, I would have used the track padding option, since it makes no difference.

It becomes an issue when creating a new image with mame, because for some reason it then uses 1s instead if 0s for the sector padding. If you want to write such an image back to floppy, the sector padding does make a difference. I'm not in a position to say if it's a bug, but it's easily fixable with dd before flashing.

Apart from this special case, i believe track padding would be useful.

EDIT: I guess the answer if mame can handle both types when dealing with m20 floppies is yes and no, it only has sector padding built it, but it effectively supports both because usually all FM sectors except the first are empty. I hope it makes sense.

[keirf]

Perhaps sector padding is the usual, on reflection. It would mean every sector in the disk is at the same logical offset sector*256, which kind of makes sense really doesn't it.

By the way you could try simplifying your diskdef. tracks * ibm.mfm would work to cover all mfm tracks. Also note no semicolon. I got rid of that pointless bit of syntax in the officially released tools.

[eberhab]

I'm wondering about the same thing. I'll see if I can find out more in a MAME forum.

Thanks for the hint to use the wildcard, it works well, I have changed the post on top to reflect this.

[keirf]

This discussion is continued in new ticket #275