Floppy emulator

[polardark]

Could it be made to work as a general floppy emulator, rather than just one for the Amiga? Many old machines including old computers and electronic musical instruments which depend on 3.5" DD floppy drives are beginning to gradually deteriorate, and finding and using old floppies and floppy disks is becoming harder and harder as the old ones break down.

Also, for general use, would it work better reading and writing using larger "raw" data files rather than dedicated MFM or ADF files? It seems that encoding and decoding takes a lot of effort. Could that stage be left out entirely?

You mentioned before that writing is not possible. Is this a fundamental problem, or something that could be solved if enough cpu power was available?

Well anyway. I think many of us have been waiting for someone to do something like this. We'll wait in anticipation to see what comes of it

[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?

[tnt23]

polardark wrote:
Could it be made to work as a general floppy emulator, rather than just one for the Amiga? Many old machines including old computers and electronic musical instruments which depend on 3.5" DD floppy drives are beginning to gradually deteriorate, and finding and using old floppies and floppy disks is becoming harder and harder as the old ones break down.

I guess so. INDEX support must be added, and the whole thing shall be tweaked with regard to INDEX and hard sectoring.

Also, for general use, would it work better reading and writing using larger "raw" data files rather than dedicated MFM or ADF files? It seems that encoding and decoding takes a lot of effort. Could that stage be left out entirely?

Well, I was thinking of some MFM format just as if it were 'raw' files, i.e. complete ones and zeroes array that can be output right after you load it. It turns out that to simplify things in my design, such a raw file will be 2.5M in size, or three times bigger than ADF one. On the other hand, loading it will take more time, too.

You mentioned before that writing is not possible. Is this a fundamental problem, or something that could be solved if enough cpu power was available?

To be honest, I haven't spent much time thinking about writing. I was obsessed with reading in the first place you see :-) There are good chances another tight loop can be built to aquire writing flow and to somehow deal with it, not necessarily turning that into pure ADF.

It won't take much CPU power to record the flow into RAM, but it definitely will be a challenge to later process it when it comes to flushing it back to the flash card.

[tnt23]

MskoDestny wrote:

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.

For DD track, we need to deliver 11 MFM sectors every 0.2 seconds. This makes it 18ms per sector.

Loading one ADF sector from MMC now takes 13ms, and preparing one MFM sector takes 56ms. These times can be optimized in variety of ways, from code to hardware (going high megaherz, using SDRAM instead of EDO/FPM DRAM etc).

Maybe the code can be built so that while one MFM sector is being delivered to the floppy bus, next one is being loaded and processed. I am afraid this technique is beyond my skills, at least using current hardware :-)

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.

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.

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

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

[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?

[tnt23]

MskoDestny wrote:

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?

My MMC card is of some unknown manufacturer, I recall reading something about 10MHz as the highest speed possible for MMC cards. For SD card, I've heard of 20MHz, and this can be figured out of quering some SD card registers AFAIK.

SD cards can be read in their native mode, way faster than in SPI compatibility mode. This however requires more complex bus. And CF cards will beat the hell out of SD and MMC for sure, if you can allocate that much of I/O pins.

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?

In chapter 2.4, 'How to decode MFM data?', there is a small C snippet. I used mainly that to construct own checksum routines. Another piece of information was C code from some Amiga emulator sources, but I can't find that now.

[uncharted]

@tnt23

I love your avatar!

[Jope]

Tim, can you shed some light on your new prototype?

[tnt23]

I have posted the photo of partly assembled proto PCB in the gallery this morning. (EDIT: check it out here.)

Got PCBs last week, only am waiting for the DRAM chips to arrive in a week or so. The code is being tweaked against the new design here and there, MMC and LCD and buttons already work.

There are some issues though. One is with DRAM chips which are no longer manufactured since 1995 I believe and thus are rather hard to obtain. I am addressing this by working on another design which would use legacy 72 pin SIMM. This also would boost overall performance since these are 5 volt and so the MCU can toot whole 16MHz.

Another issue is the Nokia 3310's LCD. Popular and affordable and all, it is a challenge to build simple and eye appealing connector for it. (See JELU Web-Shop for more info)

On my PCB there is an 2.54mm grid 2x10 pin male LCD connector (see the photo in the gallery). I use simple ribbon cable with 2x10 pin female plug on one end and a bit of soldering on the other to attach the LCD. This hardly can be an option for non-DIY persons out there.

[timofonic]

Hello,

this project seems really *A LOT* interesting. What about giving more information in english of the project and creating a web page of it? It seems really promising but too few information for non-russian people.

About the project, it can have a very great future in retro machines using floppies. This project can be even more interesting if adapted for other floppy-based architectures too (Acorn Archimedes, Amstrad CPC, Apple II, Atari 8bit/ST/Falcom, BBC Master, BBC Micro, C64, Dragon 32/64, MSX, Nec PC-100, NEC PC-8801, Nintendo Famicom Disk System, SAM Coupé, Sharp X1, Spectrum +3/Sprinter/Scorpion, Sharp X68000, Sega SC-3000, Sinclair QL,  TRS-80, TI-99/4A, Jupiter ACE...) using some kind of modular platform design (two modules and one being used for connecting to the floppy interface of different computers). Of course I'm not asking you for supporting the wide variety of floppy-based architectures, but designing your project with this on mind, supporting a few and providing the necessary information for others developing modules for it.

Best regards,
timofonic

PS: MskoDestny, I found you here! You never replied my emails, please do it about the SCD stuff, read the PM.

[tnt23]

I am trying to report as much as possible here at Amiga.org, too, mostly in English  :-) I don't think the project is mature enough to arrange a separate web page for it.

Covering all floppy formats sounds attractive. Maybe PC DD format should be implemented in the first place as there are ancient synthesizers and measurement equipment with decaying 720K floppy drives out there.

MSX people probably won't need this type of emulator since there is already a number of flash media projects for the platform, and MSX roms are much easier to tinker with.

I like the idea of modular approach, too. There are so many ways for the project to evolve, from USB to standalone floppy writer, but I'd try to first accomplish simple things :-)

[tnt23]

OK, so I've got my DRAM chips this week and the prototype board is complete. A usial number of wire fixes to the board can be seen in the photo section  :-)

I have tailored the code, too, and it now takes 35 seconds to both load and encode an ADF image. I think this is almost minimum possible for current design, maybe I'll squeeze a couple of seconds more.

DMT's speed test shows ~21K/sec. There are some glitches in FAT16 code I have to iron yet. And I'm going to sacrifice an I/O pin for audio seek indication :crazy:

[motorollin]

That's fantastic - well done! :-) What is the IDC header for on the board? Is it for connecting to the internal floppy connnector to use it as DF0?

--
moto

[tnt23]

Yeah, the big 34-pin IDC is for the floppy ribbon cable. I haven't tested it with real A500 yet, only with A1200 as DF1 using some custom cabling.

On the board there are two ugly jumpers allowing the device to respond as DF0 or DF1.

[motorollin]

So does it work as a total DF0 replacement?

--
moto

[tnt23]

motorollin wrote:
So does it work as a total DF0 replacement?

--
moto

As a read-only, ADF-based replacement :lol: Give me a couple of hours to fit the thing into my A500 and I'll report back :-)