Floppy emulator

[tnt23]

Dr_Righteous wrote:
Definately needs to work as DF0: replacement as well. Perhaps as a second, simplified design (sans the LCD screen) it would be easy to fit in the floppy bay of big box miggys. It really only needs a slot for the card and two buttons for scrolling though the ADFs... You'll know what disk it loads by what shows up on WB.

Given a floppy mounts in 100 seconds, now that would be a torture :-) The LCD I use is 39mm x 36mm and seems to fit in 5 1/2 inch drive bay well.

[tnt23]

countzero wrote:
wow, very nice work ! Seems like all the good ideas are coming into reality these days.

I think you can make your device behave as more than one floppies when necessary (not only df1, but also df2, df3 etc.) without much effort. it would be even cooler that way.

It is indeed tempting to just wire all drive selects into the device. I think this can be implemented in one of subsequent designs. I'd like the first design to be as simple as possible, so the whole bunch of great ideas like simulating four floppies, automounting via the BOOT root directory and such are left for the future.

[tnt23]

@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, so you have to keep these 12k buffered somewhere.

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.

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

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

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

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

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

[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 :-)

[tnt23]

Read only huh, well that will make it a lot easier to transfer files from my Mac, which doesn't have a floppy drive. That means I have to copy files to DOS disks at work :roll:

If I could use an ADF explorer on the Mac, then copy the ADF file to the MMC card, and then mount the ADF as PC0 then all my problems would be solved :-D

Still seems a bit complicated to me. You don't have to take your files back from Amiga to Mac do you?

So when can I buy one?

After I fix most of the bugs and figure out a way of producing and delivering the device in small quantities I guess. What would you suggest the price can be?

[tnt23]

@Doobrey

Isn't the fifty bucks color LCD an overkill? I doubt there's much to show on it in my case :-)

[tnt23]

@humppa

No, I have never been to the C64 scene [unfortunately] :-) I love the MMC64 project, too.

[tnt23]

mrmkl wrote:

Perhaps the Amiga could write ADF-images to the flash card, via somekind of serial protocol through the floppy port? It is not the same thing as writing to a floppy, but you could do things from the Amiga keyboard. And similarly since microcontrollers usually have UARTs, you could read and write floppy-images from a remote computer via RS-232.

Amiga also has RS-232 port, this could be used, too. Some software support from Amiga side would be necessary, like drivers.

UARTs are great, but there is USB. A guy from Amiga Floppy Project (http://techtravels.org/amiga/amigablog) interfaces his reader with computer via USB.

"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)"

May a job for an FPGA?

Maybe. I will teach myself FPGA some day for sure, just look at the Minimig :-) It is that I'm having fun with Atmel AVR's now.

[tnt23]

Yesterday I've put the device into A500's drive bay and set it to DF0. Workbench 1.2, 1.3 and utilities like DOpus, AMOS Pro boot just great!

Bad news is that of six or seven games on my MMC only ARKANOID managed to load and run. Also, only two demos loaded and run OK, one is some 40K intro and ANNOUNCE.

Maybe this is due to the fact that AmigaDOS doesn't use INDEX pulse (says DiskMonTools manual), which is not implemented in my design, but can well be used by other software to sync to.

Hyperspeed wrote:
Avoid Spaceballs - State of the Art, I remember that demo turning my floppy drive into a buzzsaw!

:-D

State of the Art didn't run either. If I do a diskcopy from emulated DF1 to real floppy it runs just fine. There must be something important I miss about the floppy interface.

Looks great, I think it should be for DF0: internal and it would need to work well with the desktop casing (the eject button could be replaced with an access light).

Just out of curio, what is the maximum transfer rate of the floppy interface? The drives only do 10k/s and the flash cards 1MB/s!



EDIT: Oh, the F.Disk LED will be the access light right? We'll have to use putty for the eject button hole. ;-)

There is an LCD with all sorts of indications, like head movement, drive selection, side and dir signals :-)

Floppy speed test shows values around 21K-22K bytes per second. I don't know if the floppy DMA can be faster than 500K bits per second, or roughly 60Kbytes/s. We are trying to mimic the FDD as much as possible, so don't expect any breakthrough here :-)