Home Page Forums MAME MAME MAME support for writable media

This is the start of a discussion about how MAME should be dealing with writable media.

In the arcade game world, you had ROMs, and maybe a CD, and mostly static hard disks.

With the addition of computers with floppies and hard disks, you now have some set of base system software
and applications.

The IA has taken the approach of using MAME as "emulation as a service" with canned static containers
but this isn't really all that useful for someone who wants to emulate a Mac, Lisa or other computer with
a combination of system releases, applications, and the need to get things onto and off of a media storage
container and dealing with issues like the best way to snapshot and diff those containers.

There is also the problem of provenance of the software going into the softlists.

To R.Belmont's advice in the shoutbox to just put a loose CP/M .COM file that (I happen to know) was distributed on cassette back on a "damn cassette":

Yes I can load the .COM file via the memory window of the debugger and save a "damn cassette" as a WAV consisting of a train of naive square waves.

This means making up some bytes in the Exidy Sorcerer tape header (ie the file type byte) that are not preserved when cassette software is converted to a .COM CP/M executable.

(There are also third party tools like tapetool2 that let you do this independent of real or emulated h/w).

But by inventing this intrinsic metadata you not accurately representing the bytestream of a real cassette that would have existed in the wild.

You are not fully respecting the artists intent.

When the programmer recorded their "golden master" in 1982 they made a conscious decision about what to set those values.

My concern over this is why I asked (in the shoutbox) in the first place.

Because Quickload doesn't store all the bytes in the tape header (in particular it doesn't encode the file type byte) it therefore:
- leaves no ambiguity in the archival record about what those values were.
- doesn't imply (as would a .WAV) that this is a truthful representation of all the bytes on a real cassette copy of the game.

Quickload is a way of saying (in band) that this is all we know about this game:

- bytes in the executable code path
- load address in memory (always 100H for a CP/M file on a Sorcerer)
- execute address in memory (always 100H for a CP/M file on a Sorcerer)
- filename (at least as it written to disk)

It therefore feels like a somewhat better fit for packaging up what are effectively almost loose binaries than a cassette.

Put it on a cassette image, mark it BAD_DUMP in the software list, and you have fulfilled your obligation to history. At least the experience of loading it will be authentic then.

That said, if it was converted to a CP/M .COM file, the correct distribution method for the file as it stands would still be as a file on a CP/M formatted floppy.

Al's talking about something else entirely, as far as I can tell.

This sounds like a message from the past, from pre-MESS merger time (I had a look at the message timestamp). Computer systems depend on freely mutable media, which may be one of the most salient differences to arcade systems (some of which may need to save data on media as well, I am not too familiar with them).

Who/what is IA?

IA is the internet archive i.e. archive.org

OK.


Yes. However that presents similar question of selecting an arbitrary format where this is unknown. The situation has arisen because 22DISK was used to migrate the files to MS-DOS a decade ago. There are no sector images as would be created by ImageDisk or Teledisk, there are no CP/M system tracks (if indeed the disks were bootable) and the physical media is no longer available.

An educated guess could be made about which controller supported the original physical disks and synthetic images could be created using cpmtools against that format, but the resulting .DSK would not be a verbatim image of a disk that existed in the wild.

Such a synthetic disk image could also then presumably be marked BAD_DUMP as per your advice above.


My reading is that our concerns intersect around more nuanced descriptions of file and media provenance.

> My reading is that our concerns intersect around more nuanced descriptions of file and media provenance.

I'm concerned about the practical use case for people trying to use MAME as a tool, and the mishmash of known original distribution media that has provenance
with things someone grabbed off of the Macintosh Garden. And also adding support within a running emulation session for mass storage checkpoint-restart-rollback
that software like VMware has had forever.

(the content of this post was deleted to not come across as an "ungrateful whinger", apparently input from actual users is not appreciated at this time)

Look, you guys are getting way ahead of yourselves. MAME’s floppy format handlers pretend I/O errors don’t exist, and device_image_interface doesn’t make it convenient to do a defensive save to temporary/replace operation. If saving fails for whatever reason, the user gets a corrupt image and no recourse. The people doing the most talking in this thread so far strike me as the kind of people who just want to whine and hope someone else implements a perfect solution for them. Meanwhile, I’ve had no sleep at all five nights out of the previous twelve just getting a pull request ready that gets MAME to a point where it’s possible to propagate error conditions across the layers. Talk all you want, but the more you talk, the more clear you make it that you’re a bunch of ungrateful whingers who want someone else to do all the hard work for you.

"you’re a bunch of ungrateful whingers"

I am trying to point out that no one cares about the computer simulations in MAME with either floppies or
hard disks because the UX isn't useful. This needs to be thought through if MAMEDEVs are serious about
supporting a platform and I created this thread because the only place this comes up is in the transient
shoutbox.

You're right, I don't submit pull requests, in fact, I don't use MAME at all, because it isn't useful to me as a tool.
I supply docs and software, do full builds, and try the platforms I'm interested in to see if it is ready for prime time.

They aren't.

"do it yourself" just points out that JD is right about MAMEDEVs not caring about users, or the user experience.