Floppy Disk Hardware Emulation: Your EII floppies on a memory stick?

[HideawayStudio]

... complete silence from floppy emulator world  ?? 
... any success or progress yet guys ??

Hello - It's taken a bit longer than I'd hoped to arrange a bank transfer to the supplier in China.  I am now waiting for 4 samples.  Don't worry - I will post the results just as soon as I can.

Cheers,

Dan.

[esynthesist]

OK guys, we keep our excitement stand-by 
Hope to hear good news from you soon.

[wintermute]

NEWs!

...unfortunately no good news.

The EII recognized the floppy emulator but I was unable to write on the CF card.
Formating, copying does not work (disc not ready). I made sure the ready signal is present on PIN34...still no luck. I was able to setup the device to work as FD1 or 2 and the EII could access the device but not read or write from it. I am sure that if you modify the firmware it is possible to use an floppy emulator but I doubt that any company will put effort in developing or modifing the firmware for this application. Does anyone know details about the disc format of the EII?
Maybe I can ask the developer if they can modify the firmware accordingly.
esynthesist?

[esynthesist]

Hmmm... no good news indeed.

I'm wondering what disklayouts *have been* programmed in their firmware. E.g. would the device work with an Emax-I ? With a Korg DSS-1 ? With a Casio FZ-1 ? (ok, I admit I own these babies...)

Unfortunately no one knows about the actual diskformat of the EII anymore. Even Rob of the Emulatorarchive doesn't know. I guess we could e-mail the designers of that machine but since Rob is still in contact with them, I assume that they don't remember anymore OR that they don't want to be bothered anymore with these annoying questions 

BUT at least there's a "hint" in the service manual.
My best guess is that the disk has no sectors within its tracks. This means that the sectorsize equals the tracksize. Now the EII disks have 80 tracks of 3584 bytes on each side, so this means 2*80*3584 bytes on a disk. Yes: the EII is able to store 560K of bytes (573440 bytes) on those good old 360K dos disks 

But to be honest I don't believe that there are no sectors in these 3584 byte tracks. I tried however to detect them with sectorsizes of 128, 256, 512(, 1024) on an eighties DOS machine equipped with a 360K 5.25 drive and the old OmniDisk program, but without any success. Unfortunately no other sectorsizes than these 3 can be tested on PCs because the BIOS/Floppy controllers simply don't support them. So I also can't check if the sectorsize is actually 3584.

Damned, this lack of information is frustrating.
I will contact Rob and ask him if he still can get into contact with Dave Rossum or Dana Massie. They designed the EII... if I would have designed it, I would still know this kind of choices I made in the design, even after 25 years. Fingers crossed, let's hope they can respond.
And then... let's hope the device's engineers want to update their firmware...

///E-Synthesist

[wintermute]

I have no idea if other synths with discdrives are working. The only other devices I have here with floppy are the S2000 and the DPX-1. Maybe I could try the DPX but I think there is no real point in doing so. I think the EII is the most interesting device to get a floppy emulator for (along with the PPG and the Fairlight). I still have some 3.5" drives as spare but I want a permanent solution. The discs I am using are old Amiga floppys...I have no idea how long they will work. A few years ago I never wanted to buy a floppy based synth! Now I remember why I never wanted to do that but the EII is such a great device...we need to save it!!!

Lets start a petition!

Edit: What I will try is to send the developers a floppy disc with the EII OS and ask them if they know how the floppy is organized.

[HideawayStudio]

I'm hoping my experiences with the solution I sourced from China are a little more positive as it's clearly a different beast.   The device is not supposed to have any predisposition about formats so as long as the physical connection is correct it should work  (or so I'm told).

It's a long wait...  I have been assured that some of these devices are working in vintage studio gear.

Fingers Crossed....

Dan.

[Elmbeatz]

but the EII is such a great device...we need to save it!!!
Lets start a petition!

+1

SAVE THE EII ! .............

 

[wintermute]

The developer answered and told me that if I send him the EII discs he will examine them for us.
I will prepare 2 floppies for him and we'll see if he finds out something more specific.
I am really surprised by that offer and I am really curious if he finds something out.
If he knows how to the sectors are organized he can modify the firmware.

He told me that the firmware only supports 512 bytes/sector.

@esynthesist
could you list some facts that you know for sure about the floppy format and disc drives?
At what speed do they spin?
What software did you try to read the disks? So I can tell him that certain programs are useless to try.

Still exiting!

[esynthesist]

There are really not  a lot of details known about the physical EII disk layout.

The only information mentioned in the service manual is:
- "there are 0x00 to 0x9E tracks on a disk". Translation: there are 160 tracks on a disk and we can assume that this means 2 sides of 80 tracks because 160 tracks on one side is impossible on those 5.25 disks.
- "there are 0x0E00 bytes in each track". Translation: there are 3584 bytes in each track. This equals 7 times 512 or 14 times 256 or 1 time 3584 bytes... So if the sectorsize would be 512 bytes, there would be 7 sectors per track. But again: this kind of information on sectorsizes is not provided, nor are the gapsizes being explained etc.
- "burst time is between 0x60 and 0x70": Translation: burst time is between 96 and 112 (don't know the unit)
That's all. I don't even know the spinning speed.

I tried to find out the lowel level physical disk layout using the OmniDisk software on an old DOS PC containing a 5.25 drive. OmniDisk is the predecessor of the WinXP software OmniFlop (see www.omniflop.com). I tried several manual settings, as well as the autoscan mode of OmniDisk. Without any success. After contacting the guy who wrote OmniDisk, I learned that most probably the EII does not use a sectorsize or a drive spin speed which is supported by a PC floppy controller. And if the controller doesn't support it, the software can not detect the disk layout of course... 

I also received an answer from Rob of the emulator-archive. He says none of the EII design team members remembers these details anymore and the design documents which could explain our problem have been lost.
One thing we could do is monitoring the EII Shugart interface pins while the EII is formatting/reading/writing a disk. But this requires a logic analyzer which I don't have. Maybe some pins can be read with a high speed serial link to a PC and a small terminal program instead of an L.A.... But I doubt about the success ratio of any of these experiments.

So I really hope that the device Dan will test is more generic and doesn't need this low level EII disk information. That would be the easiest way to continue this project 


///E-Synthesist

[wintermute]

So I really hope that the device Dan will test is more generic and doesn't need this low level EII disk information. That would be the easiest way to continue this project

 I hope so too but I also hope to find out more details about the floppy format. I still wonder if the USB stick device is fast enought for this application. We will see !

[esynthesist]

I still wonder if the USB stick device is fast enought for this application

? What do you mean ?
The floppy drive/bus needs 25 seconds to read/write only 0.5 MB.
I think any USB bus or device can handle much higher transfer speeds than a floppy based dataflow...
Or do you mean something else ?

[HideawayStudio]

So I really hope that the device Dan will test is more generic and doesn't need this low level EII disk information. That would be the easiest way to continue this project

 I hope so too but I also hope to find out more details about the floppy format. I still wonder if the USB stick device is fast enought for this application. We will see !

err???  Yes - you've completely lost me too.  Shugart runs up to 500Kbits/sec raw MFM data ie. a max of 50Kbytes a second (in bursts).   Even a USB 1.0 memory stick is capable of 150Kbytes/s - enough for at least a 2X oversample on a raw data capture.  I would expect there to be some buffer memory anyway ie.  I doubt it uses the memory stick as scratch space - it's more likely to use SRAM for that - surely?   When I get the drives I will let those who are interested what it's guts consist of (although I have a sneaking suspicion that it consists of one ASIC).

It is almost totally unlikely the drives in the EII were non standard - it simply would not have made commercial sense and I know the drives in the EMAX family were standard computer drives of the time.  What is possibly more likely is that the EIIs floppy disk format was very simplistic - this certainly was the case for E-mu's scsi formats of that era.  This could make reading an EII disk in a PC very difficult.  As I keep saying I'm really hoping this product doesn't have any preconceptions about format ie. it simply oversamples raw MFM data in a virtual array of tracks in memory - this is exactly how I intended to design such a product.  The issue with this method is it's rather inefficient on memory as the oversampling process could waste up to 8 times as much memory as the "real" data - what it should guarantee though is that the system should run with a much wider range of embedded gear.

This is possible because there is no intelligence whatsoever in the Shugart compatible floppy mechasms - this is purely the job of the controller at the other end of the Shugart interface.  All the drive does is lay down MFM data raw on a magnetic media on the track stepped to (relative, not absolute - hence the need for continual resets to track 0) and synchronised to a hub reference where the drive is the master sync to the controller.  The data itself is serially loaded/unloaded to/from the controller.  One interesting aspect about this method of recording (CAV) is that the data density has to be higher on the inner tracks with a smaller diameter which is where you'd expect to see more data errors.

On the other hand the job of emulating a disk in a comuter emulator such as UAE is quite complex as the system calls are made to a virtual disk controller (not a drive) which in turn is managing virtual disk images.  In our case the drive emulator is only mimicing the drive mechanism ie. the H/W floppy controller is still very much in tact on the sampler's motherboard.

[wintermute]

Its just that I heard of USB based floppy emulators that write directly to the stick without buffering the data. I also realised that the boot process of the device takes "long". I dont know if this could affect the operation of the floppy emulator in the EII...but it could be a possible error (maybe).

Anyhow I send back the floppy emulator and included 2 disc with the EII OS on it. Maybe the developer can tell us more details about the layout of the floppy disc.

[wintermute]

Hi guys,

the developer answered and he told me that he was unable to read the disks with  any of his tools. Maybe he will try again since I told him to keep the disks I sent him.
But all in all it seems that Emu did the best copy-protection ever .

Still hoping that the china device will do the job.

Cheers
Wintermute

[Elmbeatz]

 

somehow I knew...