Idea for floppy transfer at full HD speed with hardware interface

[Thomas Richter]

Originally Posted by hooverphonique

I'm pretty sure it does because it has no other way of getting a clock for sampling the data correctly.
4489 *is* used for amiga format disks, too, yes, so Thomas has a point about "full code space" will make something like sync-matching impossible.

The sync words are only used by Paula to initiate the DMA. That is, Paula follows its data input, and as soon as the clock word is recognized, DMA is turned on. Well, at least this is how trackdisk.device in v37 and on works. Below that, Paula just dumps data to chipmem and the CPU does the alignment all by itself.

In how far Paula syncs to the speed of the serial transfer coming from the floppy, I do not know. It probably requires some sort of syncing by the clock bits, maybe.

This being said, while Paula does not have sufficient DMA time to deposit HD tracks on regular screenmodes, it would theoretically have sufficient time in 31kHz screen modes such as "Multiscan". However, whether Paula can successfully sync to the (double) data rate from the floppies I do not know. Maybe somebody wants to try that.

This is because the DMA slot for the floppy is after the horizontal blank, and the blanking period is twice as high for the 31kHz modes than the regular screen modes.

[Toni Wilen]

Paula internal floppy PLL most likely requires MFM-like signal to sync properly.

[pandy71]

AFAIR there was alternative solution to provide HD without slowing down floppy RPM - DRAM buffer was used to store track during R/W operations - from Amiga perspective this will be fully transparent as transfer speed stays unaltered.

To avoid issues with PLL you can use synchronous transfers to/from fdd - just clock board trough videoport with 28MHz signal as real transfer speed is not exactly 125/250kbps (for PAL it is 506.699285714286 kbps and for NTSC it is 511.363636363636 kbps).

Also GCR mode can be used (unclear how it is implemented in Paula).

[Hypex]

Originally Posted by Galahad/FLT

Clearly as its still being used and upgraded.

All you can do is upgrade them since there hasn't been any new models on the shelf for the past 25 years.

Floppy disks? Not so much

When you have a bare Amiga system and need to transfer software to it floppy disks become very relevant.

[Hypex]

Originally Posted by hooverphonique

I'm pretty sure it does because it has no other way of getting a clock for sampling the data correctly.
4489 *is* used for amiga format disks, too, yes, so Thomas has a point about "full code space" will make something like sync-matching impossible.

In any case, my theory is to keep the track headers complete. Which contain the 4489 syncs. Or other syncs. And just modify the block data. Plus possibly the gap which could have redundant information. It only becomes an issue if the clock bits in between really are needed, in which case would render my whole idea useless.

[Hypex]

Originally Posted by Thomas Richter

This being said, while Paula does not have sufficient DMA time to deposit HD tracks on regular screenmodes, it would theoretically have sufficient time in 31kHz screen modes such as "Multiscan". However, whether Paula can successfully sync to the (double) data rate from the floppies I do not know. Maybe somebody wants to try that.

That's an an interesting idea. But how is this done for audio? Setting a lower period? I looked briefly online but the information doesn't turn up. I just want the facts. All I find are social discussion on the Amiga these days.


In any case, I can't see any way to change the transfer speed. So how would it be done? Changing screen mode, then bit banging it faster, I could only see it working by accident.

[Toni Wilen]

Paula disk PLL is not going to support disk bitrates that are double from the spec. It is usually -10% to 10% or so from nominal bit rate.

This is quite obvious way to support HD floppy. Someone would have already done it in 1980s if it had been possible. (Easy experiment: stuff in HD floppy, start motor, poll DSKBYTR, do you get correct data and/or correct amount of data between index syncs? No need for DMA hacks)

[AmigaHope]

You could probably do this entirely in scripting using a REALLY convoluted route -- networked floppy emulator that works with image file on raspberry pi. Pi also has a kryoflux hooked up with a script that constantly checks image file for deltas and writes delta tracks back to floppy. When new floppy is inserted into kryoflux-connected drive, it triggers eject on floppy emulator, creates new image file from floppy, and points floppy emulator to new image file. Only downside from this technique is long delay between disk swaps. Well, that and it's a horrible kludge.

[MiaM]

Interesting discussion!

Re buffering the data: Back in the 80's and 90's you would had to use DRAM to get a reasonable price Back then DRAMs were typically rarely used by amateurs as they were more complicatet to use than SRAMs. (Not only did they require multiplexing of the address bus with more timing considerations, they also required refresh and in particular better signal quality (the analogue properties of the signals, i.e. rise/fall times, overshoot and so on) which could be hard or impossible to trouble shoot using the oscilloscopes that hobbyistst at best had access to unless they could use something at their work or so).

Nowadays SRAMs that is large enough is cheap. They are actually so cheap that you could even use an SRAM and waste 7/8 of it by only connecting one data bit and still have space for more than one compete track of HD disk data.

Any such circuit still would need hardware to sync up to the MFM clock. Then I see two possible ways to use the actual memory. One way would be to fist store a track from disk and then output it at double speed to the Amiga. It would be simple to implement but slow as the Amiga would have to wait for each read. The more complicated but faster solution would be to multiplex the address and data bus of the memory and thus be able to start the output to the Amiga as soon as data has been read from disk.

This might not be completely compatible with arbitrary formats though. On a regularly formatted disk (either PC or Amiga) there are well defined ways to sync up with the start of a track. But some kind of arbitrary (copy protection?) format might possibly break this. However, I don't think there are any copy protected HD disks.

If the goal is just to be able to store more data on a disk it might be worth having a look at GCR. It would be incompatible with all other disk formats, but should not require any special hardware.

Reading and writing GCR DD disks does afaik use the 250kbps mode in Paula. Back in the 80's and early 90's a HD disk drive were so expensive that more or less noone would install one of these in their Amiga just to get an additional drive. So someone would had to really want to experiment with the GCR mode, and be prepared to either modify an expensive drive or live with having to use the diskchange for each disk change, and also be able to write the apropriate software, i.e. both being able to actually code and also have the right documentation. From what I recall the Hardware Reference Manual weren't that good, at least not the older versions which hobbyists tended to keep as an upgrade to the newer versions were considered too expensive for someone who was still in school or similar.

Nowadays it's far simpler to find documentation and even example code.

If someone wants to have a go at GCR, it might be worth having a look at the software on Aminet that is able to read 1541 formatted disks (directly on some of the tracs, and on all tracks on a drive that is modified to run at 280 instead of 300 rpm). Also whatever software that can read/write Macintosh DD format disks might be worth having a look at. There were also software that did go with simple hardware where you could join two Amigas using the floppy port and get SANA-II compatible network drivers. Perhaps the only implementation of running TCP/IP over a floppy interface

Btw the CatWeasel hardware did exist back in the days and did work similar to a Kryoflux or GreaserWeasel nowadays, so the idea to have hardware that requires special software drivers isn't new.

[Hypex]

Originally Posted by AmigaHope

You could probably do this entirely in scripting using a REALLY convoluted route -- networked floppy emulator that works with image file on raspberry pi. Pi also has a kryoflux hooked up with a script that constantly checks image file for deltas and writes delta tracks back to floppy. When new floppy is inserted into kryoflux-connected drive, it triggers eject on floppy emulator, creates new image file from floppy, and points floppy emulator to new image file. Only downside from this technique is long delay between disk swaps. Well, that and it's a horrible kludge.

Could be an interesting way about it. Almost like have a full disk cache that flushes to disk when needed. You may only notice it when ejecting when it flushes the final buffers to disk.

[Hypex]

Originally Posted by MiaM

Interesting discussion!

Re buffering the data: Back in the 80's and 90's you would had to use DRAM to get a reasonable price Back then DRAMs were typically rarely used by amateurs as they were more complicatet to use than SRAMs. (Not only did they require multiplexing of the address bus with more timing considerations, they also required refresh and in particular better signal quality (the analogue properties of the signals, i.e. rise/fall times, overshoot and so on) which could be hard or impossible to trouble shoot using the oscilloscopes that hobbyistst at best had access to unless they could use something at their work or so).

One comparison I would make is with a scan doubler. These need memory to buffer at least one line to double it. An overcanned AGA super screen would need just over 5K for a line at 32bpp. Two whole Amga HD sectors for one track would need just under 25K for raw data. So 32K RAM should cover it.

Nowadays SRAMs that is large enough is cheap. They are actually so cheap that you could even use an SRAM and waste 7/8 of it by only connecting one data bit and still have space for more than one compete track of HD disk data.

Or even use it as an extreme disk cache. A whole raw disk is just over 2MB. But a cache is better inside the computer.

Any such circuit still would need hardware to sync up to the MFM clock. Then I see two possible ways to use the actual memory. One way would be to fist store a track from disk and then output it at double speed to the Amiga. It would be simple to implement but slow as the Amiga would have to wait for each read. The more complicated but faster solution would be to multiplex the address and data bus of the memory and thus be able to start the output to the Amiga as soon as data has been read from disk.

A somewhat double buffer approach could be used like that. Where it begins the transfer the data while caching the front and back end. Then send when the front end of data is done.

This might not be completely compatible with arbitrary formats though. On a regularly formatted disk (either PC or Amiga) there are well defined ways to sync up with the start of a track. But some kind of arbitrary (copy protection?) format might possibly break this. However, I don't think there are any copy protected HD disks.

The caching way, which wouldn't offer any speed increase by itself, would use raw data. As long as the raw data is sent serially it should be fine. Since to my knowledge the Amiga somehow scans for the sync words in the hardware, obviously as DMA is working, and completes a whole word transfer.

If the goal is just to be able to store more data on a disk it might be worth having a look at GCR. It would be incompatible with all other disk formats, but should not require any special hardware.

The goal would be to use HD disks. Since they are supported currently and both HD PC and Amiga disks are supported on HD Amiga drives. GCR could an interesting option for other formats.

Reading and writing GCR DD disks does afaik use the 250kbps mode in Paula. Back in the 80's and early 90's a HD disk drive were so expensive that more or less noone would install one of these in their Amiga just to get an additional drive. So someone would had to really want to experiment with the GCR mode, and be prepared to either modify an expensive drive or live with having to use the diskchange for each disk change, and also be able to write the apropriate software, i.e. both being able to actually code and also have the right documentation. From what I recall the Hardware Reference Manual weren't that good, at least not the older versions which hobbyists tended to keep as an upgrade to the newer versions were considered too expensive for someone who was still in school or similar.

It was really more relevant when HD become a common PC standard. And when cheap HD drives were more common than DD Shugart drives. I'm not aware of many GCR drivers. Perhaps some Mac stuff. But doing GCR on the normal floppy drives was possible without external hardware.


Nowadays it's far simpler to find documentation and even example code.

If someone wants to have a go at GCR, it might be worth having a look at the software on Aminet that is able to read 1541 formatted disks (directly on some of the tracs, and on all tracks on a drive that is modified to run at 280 instead of 300 rpm). Also whatever software that can read/write Macintosh DD format disks might be worth having a look at. There were also software that did go with simple hardware where you could join two Amigas using the floppy port and get SANA-II compatible network drivers. Perhaps the only implementation of running TCP/IP over a floppy interface

I've got a 1541 drive adapter for the parallel port. Would it be different to that? I've used it but it connects to a 1541 so wouldn't use GCR as it would send Commodore DOS commands. OTOH if there is a driver than can interface with a 5.25 inch external drive, then yeah, that would be worth a look doing GCR.

The floppy network idea is interesting. Though really only useful if the parallel is occupied. Since it's faster.

Btw the CatWeasel hardware did exist back in the days and did work similar to a Kryoflux or GreaserWeasel nowadays, so the idea to have hardware that requires special software drivers isn't new.

Yes. Usually to go the opposite way and read Amiga disk on a PC. My ideas intend to do what is mostly supported already but faster.


Surprised the guy that made the Catweasel hasn't come up with a usb drive version. Of course it would need a drive and case. But using off the shelf USB floppy drives should be no problem. As a comparison you can buy external DVD drives for hooking into the IDE of an A600/A1200.

[jlin_au]

You could read and write standard PC 720kB and 1.44Mb formatted floppy disks on an Amiga 600, 1200, and 4000 via an IDE connected Superdisk LS-120 drive using IDEFix97 and a special LS-120 drive the is available on Aminet.


A Gotek USB floppy emulator drive with flashfloppy Firmware installed and configured with "interface = amiga" will give you access to mount and access HD ADF files on the USB card using HD floppy emulation similar to a real FB357A high density floppy without special drivers or Power computing XL(?) drive with it's special drivers.

[Hypex]

Originally Posted by jlin_au

You could read and write standard PC 720kB and 1.44Mb formatted floppy disks on an Amiga 600, 1200, and 4000 via an IDE connected Superdisk LS-120 drive using IDEFix97 and a special LS-120 drive the is available on Aminet.

Yes you could. It would be convenient to replace the internal floppy with it. But it didn't read Amiga HD disks so limited that way. Better suited to a big box Amiga. And could be used to transfer megabytes of data.

A Gotek USB floppy emulator drive with flashfloppy Firmware installed and configured with "interface = amiga" will give you access to mount and access HD ADF files on the USB card using HD floppy emulation similar to a real FB357A high density floppy without special drivers or Power computing XL(?) drive with it's special drivers.

It would allow the bus to run at full speed without the mechanical latency. But would still be stuck at top DD speed. However, it could be a good base to simulate my idea or even the XL method of operation by patching the firmware.