Floppy emulator

[PaSha]

tnt23 wrote:
@X-ray:

I use DF1 since it is available on external floppy connector, but I don't see why it cannot be DF2 or even DF3 It is a matter of soldering to the right pin.

The DF1: pin on "small" Amigas (A500, A600 & A1200) is the same as the DF2: pin on "Big-Box" Amigas. So no worries.

[tnt23]

PaSha wrote:

The DF1: pin on "small" Amigas (A500, A600 & A1200) is the same as the DF2: pin on "Big-Box" Amigas. So no worries.

BTW, can big Amigas be booted from floppy other than DF0?

[tnt23]

motorollin wrote:
I LOVE your avatar :-)

--
moto

I wonder if it can be done in 84x48, mono :-)

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

[PaSha]

tnt23 wrote:

PaSha wrote:

The DF1: pin on "small" Amigas (A500, A600 & A1200) is the same as the DF2: pin on "Big-Box" Amigas. So no worries.

BTW, can big Amigas be booted from floppy other than DF0?

Depends in the Kickstart AFAIK.

Personal experience:

Kick 1.3 in A500 & A2000 : Boots only from DF0
Kick 3.x in A1200 & A4000: Boots from any floppy drive (but DF1-DF3 have rather low boot priorities, usually lower than any harddrives. But you can ofcourse select any boot device in the early startup menu).

-Paul

[tnt23]

MskoDestny wrote:

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

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.

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

[Zac67]

MFM being so simple, it should be pretty fast to encode using a table - or rather two, one when previous bit was 0 and one for 1.
Dunno the Atmel Controller, but 8 MHz clock frequency for a 500 kbit/s signal gives 16 clocks/bit which should be plenty of time - provided you've got a shifting register at hand and don't have to do it in software...

[tnt23]

@Zac67:

You're right, MFM itself is no big deal. My early setup managed to generate MFM flow on the fly completely in software, and that was running mere 4MHz. The tight loop was pretty tight; and it could not generate sync marks on the fly since they specially violate MFM standard.

I had to throw an idea away when it came to Amiga sector encoding scheme. All these odd and even bits splits, shifts and CRC calculations require a lot of CPU work.

In fact, I use table approach as the last step in building the MFM track.

[Merc]

That's amazing! :-D  It would be really slick if the screen was small enough to fit in a 5 1/4" drive bay so you could just mount it there!  Obviously that would only work for the big box Amigas that have 5 1/4 bays.

[Dr_Righteous]

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.

[countzero]

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.

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

[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