Story of Akai S1100 and FlashFloppy

I’ve recently acquired an Akai S1100 sampler.

It’s fine 1990’s tech, running a NEC NV50 processor (an x86 clone), Motorola DSP56001 for effects processing, an SCSI controller for hard disks and from 2 MB up to 32 MB of sample RAM. (This unit has 4 MB.) Even if the SCSI controller is included by default, the hard disk is optional, and the typical storage medium is 3.5″ floppy disk. The floppy disk drive supports both DD and HD disks.

I got this unit from a music department of a vocational institute when they were dumping their old tech. There was no guarantee that it works other than that it seems to boot when the power is turned on.

Getting some disks, and a disappointment

When testing the machine, the first problem was to get some sample disks. Also, the unit was running an old version of the operating system (version 1.39, when the newest version is 4.30). The OS is stored in ROM, but it’s possible to load it from a disk as well. Martin78.com has a good page of Akai S1000/S1100 resources. There are also some Akai S1000 sample disk images.

So, I needed to get these images from the net transferred to floppy disks. The problem with this is that Akai samplers use a proprietary disk format. For HD floppies this is 80 tracks, 10 sectors per track, 1024 bytes per block, so 1600 kB in total capacity. The disk format is described to further detail here.

You can’t access these disks out of the box with a Windows PC, but this requires special software. The sample disk images can be written to disks with a program called OmniFlop. The OS disk is more difficult, it is distributed as a DOS executable, and doesn’t work correctly under Windows. So first you have to make a boot disk that boots into DOS, copy the exe to the boot disk, and then boot from this disk. The boot disk should also create a RAM drive; the OS exe doesn’t want to write to the same drive it was launched from, so after booting from the disk, the exe needs to be copied to the RAM drive and launched from there. I used a Windows 98 boot disk from bootdisk.com for this.

I was using my “vintage computing laptop” from the 1990’s for this. This is the machine I typically use for transferring data with floppies to Amiga or Atari ST. For these machines, regular PC formatted DD disks work fine, as I typically don’t need to write disk images but just transfer individual files. However, after experiencing some failures with the OS disk creation process for the sampler, it became apparent that the disk drive in this laptop is not really compatible with non-standard disk formats. So it was time to dig out an old desktop PC from the back of the closet and repeat the process with that one.

I created the OS disk and one sample disk, and proceeded to test the sampler. Unfortunately it didn’t boot from the OS disk, and trying to load the samples from the sample disk didn’t work either. Obviously there was a problem with the disk drive. I tried formatting a new disk with the sampler; no luck with that either. I tried cleaning the disk drive, no improvement. Obviously the old disk drive was broken – based on some googling it seems that this is pretty common with these samplers.

To hell with disks, USB stick is better anyway

As I don’t have a collection of Akai sample disks, a disk drive that uses physical floppies is not really a requirement for me. A floppy emulator that uses a USB stick as storage is  much more convenient. So I went to my favourite online auction site and ordered a Gotek drive with FlashFloppy as firmware.

FlashFloppy is an open source firmware replacement for Gotek floppy emulators that allows Gotek drives to be used with various vintage computers and other equipment. There are also other firmware options such as HxC, but I went with FlashFloppy because it was pre-installed by the seller, and open source is always a bonus.

After a couple of days the Gotek arrived, and off I went to connect it to the sampler. FlashFloppy allows configuration of the drive with FF.CFG file stored at the root of the USB drive. There’s no configuration for Akai S1100, but Akai S950 has similar floppy interface, so I used S950 settings. For this, following parameters are needed in the FF.CFG:

interface = akai-s950
host = akai

Since the Gotek I got is a bare-bones model and has only a 7-segment display for showing disk image number, I also changed the following setting:

nav-mode = indexed

This requires that disk images are named as DSKA0000.*, DSKA0001.* etc., but it is more convient this way than by trying to guess which regular filename maps to which number.

The sample disks from martin78.com are stored with “.akai” suffix, but they are just raw data. If they are renamed to end with “.img”, FlashFloppy knows how to load the contents when it’s set to “host = akai” mode.

Yet another disappointment – and a surprising fix

However, when I plugged the Gotek drive to the sampler, the results were disappointing. It kind of worked; from the boot disk it started loading OS 4.3, but got stuck in the process. From other disk images it loaded the contents of the disk, but the loading of samples failed, often silently and sometimes with disk errors. From some disks it could load one sample, but not more. When I tried formatting the disk, the process continued to around track 19, but then stopped with a notification that the disk had been ejected. I went through several of the possible pre-made configs, but akai-s950 was the only one that worked at all. I tried to change just about all possible settings (that seemed even slightly sensible) in FF.CFG, but the typical result was that nothing worked. I updated the FlashFloppy firmware to the newest version, but no difference.

Since the effects were quite random, I concluded that the issue was more probably electrical than in the software.

Everything else in the sampler worked fine: in the original 1.39 OS there’s a service menu that can be activated with a specific key combination, and it’s possible to run some system tests to check the HW. (This feature has been removed from the newer OS’s.) The system tests indicated that everything was fine, so the issue seemed to be quite local to the disk drive connection.

There was quite small old coffee (or coca cola) stain on the motherboard of the sampler. The substance was completely dry and probably not that conductive, but as it was one possible source for errors – especially if the drive strength of Gotek signals was too low – I decided to clean it off with distilled water and isopropyl alcohol. This improved the situation to some extent – now it was possible to fully format a disk (but not every time). So this suggested even more that this was a hardware issue.

However, the strangest thing also happened: whenever a disk formatting procedure was complete, also other disk images after that worked. I could load samples, record new samples, save them to disks and so on. Whenever the sampler was turned on, a “boot procedure” that included formatting a blank HD disk image was required. If this completed successfully, you could use the sampler, often for hours, but sometimes the disks stopped working after some time again. In that case another format operation fixed the situation.

What’s going on here?

How was this possible? My theory was that some software – either the disk subsystem of the sampler or FlashFloppy – somehow detected that the connection is not reliable and changed some settings. In order to find out whether this was the S1100 or the Gotek, I completed the required “boot procedure” to get the disks working, and after all disk activity had stopped, disconnected the Gotek while the sampler was still switched on (both data and power lines), and then plugged it back. Even after complete power loss on the Gotek side the disks were still working, so the SW on the sampler side apparently changed something to fix the situation.

So, apparently the data connection between Gotek and the sampler was bad, but not that bad that the software couldn’t adapt to it. What could be the reason for this? Gotek drive has 5V interface, but maybe it’s just 5V tolerant and signals coming from the drive have lower voltage? The sampler uses 5V CMOS logic, and as Gotek is much newer design, it’s implemented with 3.3V logic. CMOS logic is not as forgiving as TTL logic for low signal levels, so if the output voltage from the Gotek is very close to the threshold, maybe it’s possible that some rapidly toggling signals don’t get detected correctly?

The first thing needed for testing this theory was to do some measurements with a multimeter, with the drive inactive. Since floppy drive control is active low, most signals should have the higher voltage when the drive is not doing anything. And yes, most signals were 5.0V – but then some signals were only 3.68V. Was the Gotek just using 3.3V logic boosted to a higher 3.68V level with no proper logic level conversion at all?

Logic level converter for the win?

I concluded that I should build a logic level converter to see if I can fix the situation. So, I consulted for some documentation online, e.g. this and this to find out the correct pinouts for the floppy interface. I was interested only in signals originating from the Gotek: pins 8 (IDX), 26 (TK0), 28 (WP), 30 (RD) and 34 (DC/RDY), so a single 74HCT245 would have more than enough lines for handling these five signals. (It has to be HCT in order to work for logic level conversion, as the threshold voltage is lower than with regular HC CMOS logic.)

I won’t bother drawing the schematic, because the connection was dead simple: pins 1, 10 and 19 were connected to the ground, and pin 20 to +5V. This configures the chip to send data from B to A, i.e. connections between pins are 11->9, 12->8, 13->7, 14->6, 15->5, 16->4, 17->3 and 18->2. From those I just used 5 for the selected data lines.

While waiting for the parts to arrive, I double-checked the settings of FlashFloppy. Pin 34 was obvious: it had to be set to “rdy”, the other sensible option “chg” (disk change) made the sampler just think that there’s no disk in the drive. Pin 2 was more problematic. Based on inspecting the device and S1100 service manual, I concluded that the sampler uses NEC uPD72068GF floppy controller IC. In order to find out what signal is connected there, I had to find the datasheet of the controller. From there it was possible to deduce that pin 2 is connected to DEN0 signal. This was consistent with other documents describing DENSEL signal on pin 2, going from the floppy controller to the disk drive. In here it’s described this way:

“DENSEL selects double density or high density and at the same time if reduced write current should be used as those are coupled. For this reason, this pin is sometimes also called low current. [Level assignment is still unknown. It is said that the assignment is inverted between 5 1⁄4″ and 3 1⁄2″ floppies.] Modern ‘‘intelligent’’ 3 1⁄2″ HD drives do not depend on this signal but recognize the data rate from the floppy disk.”

Based on this I concluded that “dens” is the correct setting for pin 2 in FlashFloppy config file. So it seemed – and made sense – that the default configuration for Akai S950 sampler was the correct one for Akai S1100 as well. In the Akai S590 config the pins are defined like this by default:

pin02 = dens
pin34 = rdy

When the parts arrived, I constructed the special cable with the logic level converter. It worked with the first try – but it didn’t cure the problem! In fact, it got slightly more difficult to be able to successfully format a disk in order to reach correct disk operation. Now I was puzzled – there definitely was something wrong with the electrical signals, but it was not the logic levels as I had suspected.

Deep dive to the source code, and the final fix

At this point I downloaded the FlashFloppy source code and started to search for any hints to find out what is actually happening in the software. I searched the code base for all instances of “akai” to find any special cases that could explain what is going on. In floppy.c this caught my eye:

    [FINTF_AKAI_S950] = {
        .pin02 = outp_hden,
        .pin34 = outp_rdy },

Why is .pin02 tagged as outp_hden? It should be input!

Reading the code further confirmed that this is indeed an output. Pin 2 is always configured as an output pin in FlashFloppy.

Now it seemed also clear what was happening electrically. Both the S1100 and the Gotek were driving the same wire. This is obviously bad – it creates a current in the wire and voltage levels will become unreliable in the same net. This also explains the weird 3.68 V levels I measured. The fix was easy – as FlashFloppy obviously doesn’t care about the incoming DENSEL signal, just disconnecting pin 2 by setting it to “nc” solved all the disk issues. No need for my special logic level conversion cable.

Surely this is a bug? The DENSEL signal should be from the controller to the drive, not the other way round! Well, not necessarily. There is no single properly defined standard how the disk interface should behave. Even if the disk controllers I looked up generate the DENSEL signal and send it to the drive, there are also controllers that want HD select signal from the drive. (This is basically generated based on the hole in the corner of the HD disk.) For instance Akai S950 is constructed this way – as Akai S950 schematics are available online, it’s possible to check it easily. Pin 2 from the floppy interface goes into one input of a 74HC257P MUX IC, so the direction in Akai S950 is definitely from the drive to the controller. Often disk drives have jumpers for defining this directionality, see e.g. this document.

So there are basically two ways to handle this: either the controller attempts to read with HD mode, and if this fails, it switches to DD mode, or it bases this decision on the signal it gets from the disk drive. Typically the disk drive doesn’t really need to be instructed to use a specific mode. It knows the mode based on the floppy already (or the disk image in the FlashFloppy case). As this is the case, FlashFloppy can safely ignore the DENSEL signal from the controller, as it should anyway be using the correct mode. The only case where this could cause some problems is when trying to format a disk image with wrong density – but you shouldn’t be doing this with real disks either, so it’s not really an issue.

Finally, the conclusion

If you managed to read this rant all the way to the end, here’s a small treat: FF.CFG that works with Akai S1100 sampler.

interface = akai-s950
host = akai
pin02 = nc
pin34 = rdy

Although this was not really a FlashFloppy bug in the end, I did file an issue in FlashFloppy github about inadequate documentation related to the signal directions. The descriptions there are better now, and S1100 specific instructions have been added to the wiki.