MAME Floppy sound emulation

MAME (or its subproject MESS) shows impressive precision for the emulation of arcade and computer systems. One thing that has been slightly out of scope was the emulation of physical phenomena outside of the computer system, in particular the sounds and noises that occur when you operate these systems.

The following text elaborates on the state of the art of MAME 0.177.

Motivation

Do you remember those days when you were listening to your floppy drive? Well, I don't mean those new projects where you play music with a floppy drive. Disk operations took quite some time, compared to the flash drives nowadays. The Commodore 64 was well known for its superb games, but also for its dreadfully slow floppy drive, the C1541. When we dediced to play some of the bigger games, we often put some water in the coffee machine in the meantime, prepared some snacks, or did some other urgent things, and about two minutes later, loading was complete.

Luckily, the TI floppy system was much faster, but when you wanted to work productively, saving long texts or assembling or compiling programs, the floppy operation still was annoyingly slow.

Also, floppy disks were never 100% reliable, and their quality degraded over time. There were often read or write errors that showed up right at the end of loading, or when the program was almost built. These errors did not go unnoticed, though: The floppy drive started to produce uncommon noises when the head moved over the disk several times, while the controller tried to load or to write a sector.

Programs did not run flawlessly in those days either, just like today. Unlike today's operating systems with their powerful process management features, the home computers frequently crashed when something went wrong. In combination with the unreliable disk media, loader programs sometimes crashed, which was not guaranteed to be obvious; it just quietly locked up. You, however, kept waiting for the load process.

This is where the audible floppy drive noises came in handy. You noticed that for some time, nothing could be heard from the drive, no head movement, maybe the spindle motor stopped. In that case it was reasonable to freak out, hitting the case of that stupid old thing, vowing to get a new computer as soon as possible, just because it stopped saving your letter, with no real hope to recover it.

Floppy sounds from an emulation were one of those things that brought me into that emulation business, actually. I was astounded when I heard the UAE (Amiga emulator) loading a floppy disk, just like the real one sounded. I always wanted to have something like this in MAME. In summer of 2015 I added a first implementation for 3.5" drives which already proved to create floppy sounds quite nicely.

This is an update of these works, describing a new concept and the implementation in MAME.

Initial approach

The basic idea is quite simple, and it was quickly implemented in MAME. Floppy sounds can be produced when the floppy device (the MAME component that implements the floppy) is enhanced by another subdevice (floppy_sound_device) that is derived from a samples_device. The best way in the view of MAME would be to emulate the physics that produce the sound, which would mean to conceive a model for the resonances of the mobile and fixed parts of the floppy drive.

Trying to go for such a physical emulation opens up a giant world of dynamic systems with complicated maths and considerable requirements for the emulating systems. Also, while there is an abundance of visual rendering system, there are not that many for audio rendering, at least to my knowledge.

If we do not want to compute sounds, we have to use pre-defined sound clips or samples. This is a proper way to emulate sounds for quite a long time, appearing in many applications. For our floppy sound emulation we need to find out what sounds have to be produced:

• The spindle motor produces a low humming sound while running. There may also be a specific start and stop sound, caused by the quick acceleration and slowing down of the rotation.

• The floppy disk often causes a hissing sound, in particular the bigger 5.25" disks. The reason is that disk inside the protective enclosure stays in contact with the material. Moreover, when the enclosure is slightly bent or dented, the disk produces louder noises. The smaller 3.5" disks have hard enclosings that leave enough space for the disk to turn without hearable sliding.

• The head motor and the read/write head are the components with the most obvious sound production. The head motor is a stepper motor which moves the read/write head. Stepper motors have a noticeable sound; the moving head sounds as if it locks into some hole or hits an obstacle, but this is not the case. The rapid stop of the head movement is what causes the "pop" sounds.

Taking this list into account, we can easily define our requirements:

• We need samples of the turning disk without head movement. Since the head does not move all times, this is easy to achieve; we just need to record a sample of some longer disk operation to get everything we need.

• We also need samples of the head movement, the popping sounds as just mentionend.

We can treat both kinds as two sound sources and simply add the sample values on each sample step. This creates a mix of motor and stepper sound.

This was the first approach, added to MAME with release 0.165, and it worked already quite well ... but not fully convincing.

The Real Thing

The approach as described assumes that we can produce all sounds that we hear from the floppy by playing the motor and head samples. This is not true, though. The problem appears when we listen to a seek process, that is, when the floppy drive navigates to a farther track, crossing several track in between. If the samples were sufficient, we should get a believable seek sound by replaying the step sample.

The bad news is that this is not the true story. Let us have a look at a complete recording (click on it for the full size):

This is a recording of a Chinon 5.25" floppy disk drive, run by a Geneve 9640 with a DDCC-1 controller. As usual, the time advances from left to right.

There is some action at the left side, then a significant area with some louder sounds, going for some time. Then we see repeated short sounds for some time nearly up to the end; finally there is some faint sound at the right end. We have some specific, well-known sounds at these points:

• At the left side (1) there is the start-up sound of the drive. When the spindle accelerates, the motor produces a slightly louder noise. From that moment on, the motor and the floppy disk can be heard, but pretty faint. Note that the line has become slightly thicker.
• The broad blue area (2) is a Restore operation of the drive. The head is pulled back to track 0. This sounds like "rooooooop", quite familiar, and it takes longer the farther the head has to travel.
• The short sounds (3) are step sounds, like "tup ... tup ... tup".
• After 40 steps (not shown here), the drive is restored again.
• Close to the right end, the spindle motor stops (4). This can be heard when you keep your ear close to the drive.

The step rate may be configured for many drives and controllers. For this recording I selected a 20ms step rate; there is also an option for 6ms. These rates are very common for drives of that time; later 3.5" drives can handle down to 2ms rates.

Challenges

The assumption from above is that a "roooop" is just a very fast "tup tup tup". This is, as said, not true, and it makes our endeavour a bit more complicated.

Let us have a look at a close-up of a step sound:

What we cannot see in this graph is the time for playing this sample: It is 75 ms long. You should see the problem: If we have a step rate of 20 ms, we cannot play back the whole sample. The next step occurs before the sample is completely played.

Things are even worse, actually. We could decide (well, I did on the first try) to ignore that issue. Just restart the sound every 20ms, and it will magically turn into a seek sound. In the end, the real physics are not better off: How can the stepper motor and the head possibly know that another step will follow and sound differently?

If we restart the sample at that rate, the result is much too loud, and it sounds weird. It is getting much worse when you try the 6ms step rate: When restarted at that rate, you are less than one tenth away from the start. Either you do not hear anything, or the result does not sound remotely similar to the real thing.

We need to have a closer look at the seek process:

Check the distance between two peeks; they are 20 ms apart, so each one is caused by a step during the seek process. Obviously, the seek sample looks very different to the step sample, and it is questionable whether it is possibly to turn either one into the other.

Physically speaking, there are two points that explain this issue:

• When the head travels in a seek process, there is no hard stop before it reaches the target track. This is more obvious with faster step rates.

• Not only the head and the motor, but the complete chassis are subject to vibrations. These vibrations are significantly different for a seeking than for a stepping head. It is not even certain that two drives from the same brand also sound the same, depending on the way they are mounted in the computer or in the drive case. These additional sounds are known as harmonics.

The first point leads to another thought: The "pop" sound of a step is not really the step itself, but the stop of the head at the end of the step. Certainly, there is also a sound when moving the head, but much fainter.

Improved concept

The above considerations led me to a new concept that improved the step sound significantly: A sequence of rapidly triggered steps is a seek process; so let us play back a special seek sample. This approach can be seen here:

At first we start with a step sample; then we switch to the seek sample. You do not notice this quick switch; it sounds as if it begins with the seek sample. We keep the position within the step sample, though: When the seek is over, the last step should resemble a single step, and then we resume the step sample. If you look closely you see that we resume the seek sample at a slightly later point of time (1/100 s); this way we can dampen the end pulse a little bit to make it more realistic - we are skipping the strongest peak.

Hence, from a "tup-tup-tup" and a "rooooop", we create a "tu-roooooo-p" here. That is, we get to this solution:

• We start with a step sample.
• If the step sample plays to completion, we do not have a seek. This is the easiest case.
• If another step occurs before the step sample has completed, we switch to the seek sample.
• If the seek sample plays for some longer time than should be expected from the step rate, the seek process is obviously done. We return to the remainder of the step sample, which adds the "-p" sound.

There are still some points to consider: The seek sample will only sound correctly when the step rate matches; here, 20 ms. If we have a different step rate, for example of 6 ms, we do the following trick:

• When we have to switch to the seek sample, we calculate the step rate from the position in the step sample.
• We then choose a suitable seek sample for the calculated step rate. For this purpose we need several samples for different step rates.
• If there is no matching seek sample, we play back the closest seek sample with an adjusted pitch.

This proved to yield a really nice sound output that sounds much closer to the real device. However, the playbacks with a shifted pitch decrease the quality of the sound emulation again: An 8 ms seek sample is just not a 16 ms sample, played at double speed; recall the harmonics mentioned above.

Therefore we need to record many different seek samples for a drive and only use slightly changed pitch. A good collection would be 2ms, 6ms, 12ms, and 20ms. Slower step rates behave almost like separate steps, so they can be produced in the easy way by replaying the step sample.

Sample files

These are the current sample files as of release 0.177. The XX prefix must be "35" or "525", according to the floppy type. You need at least one full set of 10 sample files. If a file is missing, floppy sound output is disabled.

File name	Meaning	Timing requirements
XX_spin_start_empty.wav	Starting spindle motor, no disk inserted	At least 50 ms
XX_spin_start_loaded.wav	Starting spindle motor with floppy disk	At least 50 ms
XX_spin_empty.wav	Running spindle motor, no disk inserted	Match rotation period (usually 200ms) or multiple
XX_spin_loaded.wav	Running spindle motor with floppy disk	Match rotation period (usually 200ms) or multiple
XX_spin_end.wav	Stopping spindle motor (with or without disk)	less than 100ms (or we would notice the disk sound)
XX_step_1_1.wav	Step sound in zone one, sample 1	Comprise the whole step sound, at least 75 ms; should be clipped to start immediately
XX_seek_2ms.wav	Seek sound at 2ms step rate	Should be low volume, can be barely heard; at least 10 ms
XX_seek_6ms.wav	Seek sound at 6ms step rate	Most notable floppy drive sound; may be well hearable. At least 50 ms.
XX_seek_12ms.wav	Seek sound at 12ms step rate	May be well hearable. At least 75 ms.
XX_seek_20ms.wav	Seek sound at 20ms step rate	Very coarse sound, well hearable. At least 100 ms.

The step sound naming already suggests that there is a possible further enhancement: to use different samples according to the position on the disk, and then possibly different sounding samples in the same zone that would be picked at random. The step sounds are softer when the head approaches the spindle in the center.

Adapting to other drives

Many drive brands have their specific sound, one could say, like a fingerprint. Therefore, while MAME delivers 20 sample files (10 for 5.25", 10 for 3.5" drives), you may want to use samples for your special disk drive. You'll have to proceed as follows:

• Create your own samples directory (like mysamples) and use that name in the mame.ini configuration file as value for the samples property
• Record your own samples with the same names as above (according to the drive size)
• Put those files into your mysamples directory.

Concerning the seek samples, it may occur that you cannot make your disk drive use the mentioned step rates. This is not a problem as long as the emulation uses the same rates. You must provide those files, however. If the file is never used, you can put anything into it. Otherwise, if you want to provide something meaningful (just in case you do have that step rate in emulation), you can try to "forge" a sample.

For instance, you may only have a 20 ms sample, but you cannot be sure that there won't be a 16 ms step rate at some time. If you cannot record a sample at that rate, load your 20 ms sample into an audio processing tool (like Audacity), and change its rate to 16 ms. In Audacity, you would have to apply the effect filter "Change speed". However, keep in mind that those samples are no real samples, and they likely sound weird: For human speech you could easily tell whether a recording is replayed at higher speed, or whether the speaker has a higher pitched voice; this is nearly the same effect here. For the same reason we cannot get along with a single seek sample and just modify its replay speed.