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.

Motivation

Don't you remember those days when you were listening to your floppy drive? I don't mean those new projects where you play music with a floppy drive, of course. 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 soound 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 inch disks. The reason is that disk inside the protective enclosure stays in contact with the material. When the enclosure is slightly bent or dented, the disk produced louder noises. The smaller 3.5 inch disks have hard enclosings that leaves 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 quite easy to accomplish; we just need to record a sample of some longer disk operation.

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

We can treat both 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, 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:

If you measure the distance between two peaks, you will of course notice that they are 20ms apart. And we have to admit that it has virtually no similarities to any part of the step sample.

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.

In fact, 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 I'd recommend to record many different seek samples for a drive and only use slightly changed pitch. A good collection would be 2ms, 6ms, 8ms, 12ms, 16ms, and 20ms. Slower step rates behave almost like separate steps, so they can be produced in the easy way by replaying the step sample.