Floppy emulator

[MskoDestny]

tnt23 wrote:

patrik wrote:
@tnt23:

How fast mcu do you estimate would be needed to convert tracks from the adfs to mfm data on the fly?


/Patrik

Quite a bit I'm afraid. You have to deal with ~12k of data, with bit shifting, masking and checksumming, all within 0.2sec or so.

Only if you did the work an entire track at a time before you started streaming the data. If you did it all a byte at a time while you were sending the data the processor requirements would be a lot lower (of course getting the timing right would be a major pain).

[MskoDestny]

tnt23 wrote:
Unfortunately, you ought to have some data to be streamed in advance (right before you start to stream it), and it is impossible to know exactly which track will be requested the next second.

I must confess I don't quite get your point here.

Perhaps I misunderstood your statement about having to process 12K in .2 seconds. I was under the impression that you had .2 seconds from when a track is requested to when you needed to start streaming data in which case you wouldn't need to do the MFM encoding on the whole track in that .2 seconds as long as you could keep up with the data stream.

If that .2 seconds figure was the amount of time from the beginning of the request to the end of the transfer of the whole track than I misunderstood and you can ignore what I said.

[MskoDestny]

tnt23 wrote:
@MskoDestny

Sorry I didn't make myself clear. What I failed to say was that the track has to be delivered over and over again while the virtual drive is selected, in order to simulate the real floppy. That means that the flow is repeated every 0.2 seconds,

I later looked at the Amiga floppy timings and realized my error. I also realized the data checksum is towards the beginning of the sector which makes things more problematic.

so you have to keep these 12k buffered somewhere.

If you could do the encoding in realtime then you'd only need enough buffer for a single sector (maybe two). Of course that assumes you could do the encoding in realtime.

Besides, it is quite possible that the Amiga will query another side of the floppy any moment. This makes me think of keeping 24k of stuff. What is worse, the seek timings leave very little time for fetching and preparing new track data.

3ms(or is it microseconds? I cant remember) is certainly harsh. You could cheat a bit and always present the track gap first. If I'm calculating it correctly that should get you an extra 9ms (about 72000 cycles @8MHz). So I suppose the real question is can you read a sector off the MMC card and produce a single encoded sector complete with header and checksum in a mere 9ms.

Out of curiousity, do you know of a good link that discusses the CRC algorithm used for the data and header checksums?

[MskoDestny]

tnt23 wrote:
I am talking SPI @4MHz now, it is half of MCU's main clock. If I go for 16MHz, I will probably get 6-7ms of one sector loading time. Still not enough.

That would be a bit of a problem wouldn't it. How high of a clock can an MMC card take in SPI mode?

You may wish to check "The .ADF (Amiga Disk File) format FAQ" at http://lclevy.club.fr/adflib/adf_info.html.

I've looked at that document and I see a discussion of the bootblock and rootblock checksum algorithms, but it doesn't say anything about the algorithm used for the sectors themselves (other than that it's applied to the MFM encoded longs). Is it the same basic algorithm?