Anyone interested in a run of an SD card based version of the floppy emulator?

[TheGoose]

Umm, I want to ask some especially dumb questions (I read over the pages http://torlus.com/floppy/index.php?About).

What is the relation to the SD card and a floppy image? Or I guess I am asking, can I store a bunch of .ADF images on an SD card, like some super floppy drive? Does this get rid of floppy swappy?

And could it emulate more than one physical device? DF0: and DF1: ? I guess if works as hoped there would be no need for that.

[yaqube]

Unfortunately you have to convert every ADF image to custom format (raw MFM data) and then store such files on an SD card. Only one drive is supported. More over write to images created from Amiga disk format files (ADF, DMS, IPF) is not supported.

I'm thinking about making my own floppy emulator supporting directly ADF images (writable) and up to 4 floppy drives (that would require some Amiga hacking since external floppy connector supports 3 or 2 (A2000, A3000 & A4000) drives, also making external drive acting as DF0: isn't simple (maybe except A4000 where you need only to change a jumper).

[trip6]

Thats great news Yaqube... If you made an ADF compatible one... I would buy two...

But here is what you should consider in desgn of the PCB in my opinion:

1.) That the PCB is the size of a standard Amiga Floppy drive with mounting holes to match (you would probably need threaded barrel connectors attached to the sides of the PCB to mate up with the holes), so it can be easily mounted internally.

2.)That the SD slot pertrudes slightly out of or lines up with the floppy access slot on the amiga case for true floppy replacement and easy access.

3.) That there be a fairly long cable (6-8 inch) that gets run out the floppy access hole providing the connection from a header on the PCB to the LCD and buttons to switch ADFs and scroll through them on the SD card, and reset the unit to allow for external mounting on the outside of the case with velcro or two sided tape.

4.) Maybe a visble LED light to show SD access on the PCB or on the LCD unit...

Any of us who have your ARM unit, know that you make great stuff... I am really to seeing this from you... I would definately take two...

Unfortunately you have to convert every ADF image to custom format (raw MFM data) and then store such files on an SD card. Only one drive is supported. More over write to images created from Amiga disk format files (ADF, DMS, IPF) is not supported.

I'm thinking about making my own floppy emulator supporting directly ADF images (writable) and up to 4 floppy drives (that would require some Amiga hacking since external floppy connector supports 3 or 2 (A2000, A3000 & A4000) drives, also making external drive acting as DF0: isn't simple (maybe except A4000 where you need only to change a jumper).

[Firedawg]

Unfortunately you have to convert every ADF image to custom format (raw MFM data) and then store such files on an SD card. Only one drive is supported. More over write to images created from Amiga disk format files (ADF, DMS, IPF) is not supported.

I'm thinking about making my own floppy emulator supporting directly ADF images (writable) and up to 4 floppy drives (that would require some Amiga hacking since external floppy connector supports 3 or 2 (A2000, A3000 & A4000) drives, also making external drive acting as DF0: isn't simple (maybe except A4000 where you need only to change a jumper).

Ditto on Trip6 comments!  I would also like to have the emulator support ADF directly, as opposed to converting each file.  I would definitely want two or more of these units.

The Dawg!

[TheGoose]

Yes, .ADF support would make all the effort worth while to me...

Thanks for your replies

[Jeff_HxC]

Unfortunately you have to convert every ADF image to custom format (raw MFM data) and then store such files on an SD card.

yes but this is as fast as copy adf file directly to the sdcard: the software convert and store image file directly to the sdcard.

Only one drive is supported. More over write to images created from Amiga disk format files (ADF, DMS, IPF) is not supported.

true actually, but this will be corrected on the final version of the emulator (work in progress ;-) ).

[tnt23]

Hey Jeff, nice to see you! Keep working on your great design

@trip6

What you describe looks very much like this It's a custom installation of Megadrive256 emulator on a 1200. The guy has left SD card on the emulator's board, and I guess it is not accessible through the floppy slot.


Direct ADF support requires some processing power, as the CPU has to take every sector's 512 bytes, split these into odd and even bits, then combine in an Amiga formatted MFM sector adding quite a few CRCs here and there.

(shameless plug on) On Megadrive256 emulator, typical .ADF is loaded and encoded in 15-16 seconds. Funny enough, the already pre-encoded MFM image (2048K in size) is loaded pretty much at the same speed, that's because Megadrive256 runs @16MHz and SD card is being accessed at half of that.

(shameless plug off)

So I guess it would require some really quick CPU to seamlessly read .ADFs, and to write these on the fly it would have to be even faster. Probably an easy job for FPGA.

[Jeff_HxC]

Hey Jeff, nice to see you! Keep working on your great design

@trip6

What you describe looks very much like this It's a custom installation of Megadrive256 emulator on a 1200. The guy has left SD card on the emulator's board, and I guess it is not accessible through the floppy slot.


Direct ADF support requires some processing power, as the CPU has to take every sector's 512 bytes, split these into odd and even bits, then combine in an Amiga formatted MFM sector adding quite a few CRCs here and there.

(shameless plug on) On Megadrive256 emulator, typical .ADF is loaded and encoded in 15-16 seconds. Funny enough, the already pre-encoded MFM image (2048K in size) is loaded pretty much at the same speed, that's because Megadrive256 runs @16MHz and SD card is being accessed at half of that.

(shameless plug off)

So I guess it would require some really quick CPU to seamlessly read .ADFs, and to write these on the fly it would have to be even faster. Probably an easy job for FPGA.

You can also encode the actual track only if the cpu is fast enough to have a settle time < 18ms ;-)

with this hardware this should be possible (AT91SAM7S):


http://hxc2001.free.fr/floppy_drive_emulator/ARM_StandAlone_HxCFloppyEmulator.pdf

but if you use some pre encoded file, why did you need to load the full image into ram ?

[tnt23]

You can also encode the actual track only if the cpu is fast enough to have a settle time < 18ms ;-)

Yeah, right In fact, you have to encode two tracks (both sides) as switching sides takes 0.1ms. This definitely was not achievable on my hardware.

with this hardware this should be possible (AT91SAM7S)

Hope it will be! I am thinking about teaching myself FPGA in the meanwhile

but if you use some pre encoded file, why did you need to load the full image into ram ?

Well, seemed like I haven't got enough time to load even one track of one side into memory in 18ms, so I scrapped the idea. Besides, I'd still need some RAM to accomodate incoming WRDATA stream, and RAM the size of a track would still need to be flushed back to the card in realtime.