Re: Olivetti M20 emulation status?
eberhab
01/28/23 09:13 PM
Hi all, I am following this thread since a couple of years and explored quite a bit running some of our software from the 80s in mame. It works mindblowingly well, many thanks for putting this together. Recently I have bought a greaseweazle to image some more disks, and also to write some sector images back to floppy to run them on the original machine. While doing so, a few questions came up concerning the FM track padding that MAME uses, which I was wondering if you could help me to understand.
In general, when imaging the floppy, you get 2 kiB out of the FM track, while mame expects track1 to be at 4 kiB offset. The simple approach is to pad the entire track with 2 kiB. MAME on the other hand internally pads every single sector with 16*128 Bytes [1]. As has been posted earlier in this thread, only the first sector contains data anyways, so the two approaches end up being identical, at least when creating an image from a floppy and loading it in MAME.
When creating an image with mame (or converting with floptool), MAME however seems to use 1s instead of 0s for the padding. In this case track vs. sector padding does make a difference. If one writes such an image back to floppy, assuming track padding, one ends up writing some data to the floppy that does not technically belong there.
We have been discussing if it makes sense for Greaseweazle to support padding of FM tracks [2], but we didn't understand if it would be preferable to do it on a per track or per sector basis. I was wondering what are the arguments for MAME to use sector padding or if its an arbitrary choice?
The other question was why MAME would use non-zero data to pad the sectors, and if it could be an option to change this, to mitigate the problem of writing non-zero padding data back to floppies?
Any info and insights would be appreciated. Thanks

Benjamin
[1]
https://github.com/mamedev/mame/blob/master/src/lib/formats/m20_dsk.cpp#L9[2]
https://github.com/keirf/greaseweazle/issues/143