Floppy disk emulator read please !

[Dizzy]

nothing like the sound from the floppy when playing Great Giana Sisters
Amiga floppie is better than playing tape games on a real c64..wait...wait...wait..wait..wait...error..throw tape at the wall

[alexh]

Can anyone remember the demo that played music via moving the stepper motor in your floppy?

Might have been an ST demo... not sure.

[_ThEcRoW]

From what i can remember, the flash card emulator of the russian guy was standalone, and didn't need the pc on all the time.

[gizmomelb]

Originally Posted by alexh

Having to have a Windows based PC within USB cable length of the Amiga/ST is a big drawback IMHO.

If it had a compact flash interface as well, for stand alone use, it would be great. But it would also be 10x more complicated and more expensive.

The FPGA has to be a lot bigger as it has to do the MFM conversion and the Compact flash file access. There are some home project prototypes in development that do this.

heya,

no need for complicated or expensive - I've suggested on the Torlus forums that the floppy image could be stored on the flash card as an already decoded image (RAW data or MFM data - whichever is more appropriate) - so instead of using the computer to decode and stream the data down the USB, the computer software is used to decode the ADF/DMS/IPF(Amiga)/.ST/.MSA(Atari ST) to a file then that MFM decoded file is auto-renamed to fit a 'slot' of up to 16 spaces (ie: is named 0disk, 1disk, etc. to edisk, fdisk (how many games etc. are more than 16 disks?) and those files can then be copied on to the removable memory card connected to the PC (or MAC).

A PIC could be used to select and load the disk image to the memory connected to the FPGA, then the current project's FPGA does the floppy emulation (no extra programming needed) and transparently loads the data to the Amiga or ST.

All that might need to be developed is the programming for the PIC and interfacing the PIC to a flash memory reader - which from the brief look I've had using google wouldn't appear to be too complicated, the modified 1541 virtual floppy schematic here has exactly what I'm talking about - http://www.pyrofersprojects.com/1541...41-III_v12.pdf

The only possible extras I can think of would be two push buttons (one for 'next' disk image and one for 'previous' disk image) and maybe a LED segment display to display which disk image is currently selected (0-f).

After the decoded disk image(s) is(are) copied to the memory card, the card is removed and inserted into the virtual floppy disk emulator and the Amiga/Atari ST powered on.

The floppy disk emulator by default looks for 0disk and loads it (if found), if 0disk isn't found, then it looks for 1disk, 2disk etc. until a disk image is found - if it cannot find a disk image then it returns the 'no disk inserted' signal to the floppy controller (and if you have a hard drive, then the computer boots from that as normal).

When a disk image has been loaded and the user presses the 'next' or 'previous' buttons - then the 'disk eject' signal is sent to the floppy controller, a small timed loop waits for however long the Amiga/Atari ST needs to register a disk has been ejected, the next or previous disk image on the storage card is selected/loaded into SRAM and the LED segment display is changed so the number/id of the selected disk is displayed; then the 'disk change/disk inserted' signal is sent to the floppy controller and the computer thinks that the disk has been changed and then tries to load it etc.

Originally Posted by alexh

You would not be able to support IPF images using a flash card, as SPS are keeping the IPF details a closed source project.

Well there's the stopper for having IPF access on the device, unless they decide to open the source or release an IPF decoding plugin for the MFM decode software (much like WinUAE and IPF possibly?).


Ultimately it'd be great to have write support in the floppy disk emulator as well - which might be quite easy if the FPGA supports writing to the SRAM - the PIC could then be used to take a 'snapshot' of the SRAM and copy it back to the flash card.

It's all just hypothetical at the moment, gotta wait until the final schematic, FPGA code and PC decoder software are released before I can start tinkering.

Gizmomelb

[alexh]

Originally Posted by gizmomelb

A PIC could be used to select and load the disk image to the memory connected to the FPGA

Bit of a waste of a PIC when you have an FPGA but hey.

Well there's the stopper for having IPF access on the device, unless they decide to open the source

Even if they open-sourced it... the amount of horse power required to decode the IPF file in the FPGA might prove to be prohibitive.

or release an IPF decoding plugin for the MFM decode software (much like WinUAE and IPF possibly?).

The exisitng IPF DLL could be used with any software. What do you think the current Floppy server uses?

Even if you could create a program that converts IPF to MFM data how large would that file be?

Is it even possible to extract an IPF to a single file? Does the DLL give the same MFM data every time for the same disk commands? I thought that some copy protection relied on fluctuations.

write support [snip] might be quite easy if the FPGA supports writing to the SRAM

Adding write support between the FPGA and the SRAM is trivial. If it were easy, the author would have added write support. There will be a "gotcha" somewhere.

[gizmomelb]

Originally Posted by alexh

Bit of a waste of a PIC when you have an FPGA but hey.

it's to keep the circuit simple, no need to upgrade the FPGA to a bigger, faster (more expensive) one - use the current design and have the PIC do the 'dumb' loading and shifting work. A PIC should be much cheaper and easier to add than upgrading the FPGA.

Originally Posted by alexh

Even if they open-sourced it... the amount of horse power required to decode the IPF file in the FPGA might prove to be prohibitive.

nope, the software on the PC is used to decode the IPF file (if IPF support can be added - maybe that's an advanced step - just get basic (ADF/DMS) MFM disk support happening with a flashcard first, then look at IPF support as it will need an extra table for the floppy errors).

Originally Posted by alexh

The exisitng IPF DLL could be used with any software. What do you think the current Floppy server uses?

Ahh, I forgot the IPF decoding with the PC software was already implemented.

To have IPF support on the floppy emulator would need some extra development for the PIC and the FPGA.

From Toni's comments how WinUAE handles IPFs :

http://eab.abime.net/showthread.php?t=26352

it would seem "ADFs/IPF/whatever are converted to raw data + a separate buffer for possible timing data (IPFs only)".

So IPF support would mean extra programming for both the PIC and the FPGA to be able to read the errors from a second file/table, as well as how to act with the errors.

Originally Posted by alexh

Even if you could create a program that converts IPF to MFM data how large would that file be?

A standard DD disk is 901120 bytes in size, so only 1MB SRAM required to store the entire decoded MFM image (ADF/DMS images) in memory on the floppy emulator.

IPF support would need an extra area of memory to hold the 'error table' and would need extra development for the FPGA to 'know' about the IPF error table, as well as how to handle it. So IPF support is definately advanced work, best to just get a flashcard floppy emulator working with ADF and DMS support first.

Originally Posted by alexh

Is it even possible to extract an IPF to a single file? Does the DLL give the same MFM data every time for the same disk commands? I thought that some copy protection relied on fluctuations.

No idea, as you said - it's closed source. But there is a similar project on the Atari ST named 'pasti' which supports copyright protected disk images on the Atari ST, and they might also offer some assistance with implementing support, once a standalone flashcard floppy emulator is available. I'm not saying the SPS guys won't help, but actually doing the development for a standalone SD/MMC floppy emulator with ADF/DMS etc. support will certainly get them interested with helping implement IPF/pasti support.

http://pasti.fxatari.com/

Originally Posted by alexh

Adding write support between the FPGA and the SRAM is trivial. If it were easy, the author would have added write support. There will be a "gotcha" somewhere.

The current design for the Torlus floppy emulator only has 256KB or RAM and relies on the data streaming from the USB port - that's something I forgot to mention above - the Torlus design would need to include more memory as well as some (minor) FPGA programming to have extra address lines to the FPGA can access more than 256KB (at least there are a few unused pins on the FPGA, so they can be programmed as I/O address lines for the memory).

2MB of memory should more than cover a fully MFM decoded floppy image, as well as a seperate error index table (please IPF/SPS guys - if it won't please at least let us know the maximum filesize a decoded IPF image might be).


I just realised that writable support to a floppy emulator with enough RAM on board to store an entire decoded MFM image should be extremely trivial - the Amiga and the Atari ST both do the MFM encoding themselves in software (Amiga) or hardware (Atari ST) - so with enough RAM to support a full MFM image in memory then the device should also be able to write data to the interface (as the floppy emulator should be 'transparent' to the original Amiga/Atari ST hardware - it just sees it as a normal floppy drive). The PIC can then be used to copy the memory image back to the flashcard.

What do you think?

[gizmomelb]

oh, I just found a nice English translation of the Torlus main site, for those of us who don't understand French that well (or the crappy translation offer by online translation software)

http://forum.defence-force.org/viewt...e0990b530aee9b

[gizmomelb]

oh and pointing out the obvious - a floppy disk emulator would make no noise - so you wouldn't hear the stepper motor etc. maybe that could be an enhancement at a later stage!

[musashi5150]

Originally Posted by musashi5150

I can see your point why floppies are bad, but I like them. I like the noises they make

Originally Posted by gizmomelb

a floppy disk emulator would make no noise - so you wouldn't hear the stepper motor etc. maybe that could be an enhancement at a later stage!

Trying to cater for every taste I see

[Toni Wilen]

Originally Posted by alexh

Is it even possible to extract an IPF to a single file? Does the DLL give the same MFM data every time for the same disk commands? I thought that some copy protection relied on fluctuations.

"weak bit" protections need multiple revolutions of same track.

btw, there is at least one protection that reads same track 60+ times (don't remember the exact number) and fails if there is less than 50 different results...

[gizmomelb]

first off - thanks for any and all input to this idea and future tinkering.

ok, so IPF support might be extremely difficult to implement - the floppy drive emulator only supports constant bitrates at the moment. But it's something to look forward to in the future maybe.

IPF support would be magnificent, but with ADF/DMS support and possible being able to write to the virtual floppy disk images - then at least you could play (cracked) games and still save your high score etc.

[gizmomelb]

Originally Posted by musashi5150

Trying to cater for every taste I see

hehe, sure am.. mostly just trying to get imaginations fired up and get some discussion of what is needed to actually needed (on the Amiga side of things) to for 'full' floppy drive hardware emulation.

[gizmomelb]

Originally Posted by Toni Wilen

"weak bit" protections need multiple revolutions of same track.

btw, there is at least one protection that reads same track 60+ times (don't remember the exact number) and fails if there is less than 50 different results...

too bad if you had a perfectly aligned and balanced drive which rotated at the same speed all the time!!

extremely unlikely, but hey

[musashi5150]

Originally Posted by gizmomelb

too bad if you had a perfectly aligned and balanced drive which rotated at the same speed all the time!!

Would still work fine - flaky/weak bits are to do with unmagnetised areas of the disk being read giving random results...

[IFW]

You have to use the ipf library to decode a track each time it is being accessed on a track that hasn't been decoded before, or whenever a new revolution starts on the same track.

In addition to emulate generic MFM devices it is a good idea to use the builtin emulation.

IPF files do not have the concept of format specific errors or anything similar; they generate raw bitstreams (after agc, but before any kind of decoding takes place) and timing information. Both timing and the data can vary depending on the stream with each new revolution for the very same track.

[Retro1234]

CooL But does this replace the floppy drive(DF0) or can you have both?
This Floppy emulator project runs from Flash card http://www.amiga.org/modules/myalbum/photo.php?lid=2486

[alexh]

But it is unfinished, unreleased and doesnt do IPF etc.

[gizmomelb]

Originally Posted by Boo Boo

CooL But does this replace the floppy drive(DF0) or can you have both?

this is a direct replacement for any floppy disk - so you could stick in internally as DF0: or stick it in an external floppy enclosure and use it as DF1: (or DF0: if you do the switch mod to reverse the external and internal drives).

With the USB cable having to stick out of it all the time it might be easier to mount it as an external drive and do the DF0:/DF1: swap trick.

Originally Posted by Boo Boo

This Floppy emulator project runs from Flash card http://www.amiga.org/modules/myalbum/photo.php?lid=2486

from previous comments on here and other forums, it appears the author has stopped development of that device - but that is similar to what is aimed at for modifying the USB floppy project.

[Brass]

It would be nice if you could do a dir on the entire contents of the disk from CLI and then assign the file that you want loaded on boot in place of using a little screen or perhaps in conjunction with.

I.E

SSF -r <device>

to get a dirlist

SSF -m <device> <image> to use this image mounted now until next reboot.

SSF -m -r <device> <image> to mount the image and have it survive reboot

SSF -u <device> unmount and remove reboot survival flag

Something like that.

[gizmomelb]

The floppy disk drive hardware emulator site has been updated with new circuit schematics, FPGA code and the Windows transfer software.

http://jeanfrancoisdelnero.free.fr/f...rive_emulator/