Home Page Forums Active Threads Since Yesterday

We have some initial PCMCIA support in MAME, that is used by Konami/Taito systems. I'm currently looking at extending this a bit and adding it to the Amiga driver. Here's a screenshot of an SRAM PCMCIA card on the A600 driver:



I'm currently looking for people owning one of those cards to dump their EEPROM (and document the PCB). The dump I'm working with came from here: https://eab.abime.net/showthread.php?p=393062.

Writing to floppies is currently broken, and the emulated system will crash pretty much immediately.

I don't this was a choice of the mame developers but that's how the images available were formatted. Support for that image type was added in https://github.com/mamedev/mame/commit/e28bcc6f74ac45be1665af38219d96ce40297cbe by (I think) z8001cpg.

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

That's not right for priorities. Higher numbers have more priority. DF0 is 5, DH0 is 0, DF1 is -10, DF2 is -20, DF3 is -30