Welcome, Guest. Please login or register.

Author Topic: Anyone interested in a run of an SD card based version of the floppy emulator?  (Read 17794 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline tnt23

  • Full Member
  • ***
  • Join Date: Dec 2005
  • Posts: 195
    • Show all replies
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.
 

Offline tnt23

  • Full Member
  • ***
  • Join Date: Dec 2005
  • Posts: 195
    • Show all replies
Quote from: Jeff_HxC;530430
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.

Quote
with this hardware this should be possible (AT91SAM7S)


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

Quote
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.