So you spent your youth learning your craft in front of an Amiga 500+, but a quarter century later all you have left is a broken computer and a pile of floppies you can’t read any more. What’s to be done? This was the position [Rob Smith] found himself in, and since some of the commercial solutions to ripping Amiga floppies were rather expensive, he decided to have a go at making his own.
His write-up makes for a fascinating read, as he delves into the physical interface of the PC floppy drive he used, and into the timing required from the Arduino that controlled it. He faced some challenges in getting his code to be fast enough for the task, and goes into some of the optimisation techniques he employed. His code for both Arduino and Windows is open-source, and can be downloaded from his GitHub repository. Future plans involve supporting the FDI disc format as well as ADF, and adding the ability to write discs.
We’ve shown you a lot of Amigas over the years, but perhaps of most relevance here in our archive are this Raspberry Pi floppy emulator and this floppy autoloader for archiving a disc collection.
Via Hacker News.
PRUs might have helped.
What are PRUs ?
Probability Routing Unicorns.
Programmable Refrigeration Units.
As hot as it is? Yeah! Actually that would be an interesting HaD project. A personal A/C unit (and no, it’s NOT called a fan).
That drives me a little crazy too; hot air over a bucket of ice cubes is not an AC IMO.
One of my “someday-when-I-have-time-to-do-it” ideas is a Stirling pump AC/refrigeration machine with many small home-built ‘heat pumps’ that can be swapped-out as they inevitably fail. As few electronics as possible, maybe clockwork for the timers…
PRU means Programmable Realtime Unit.
That last sentence was for [Vince]. PRU has way too many meanings.
@ [notarealemail ] I was thinking something sleeping bag like with a chilled liquid flowing through to a cooling unit. Keeping the effect localized as much as possible, and the amount of energy required to cooling a person to a minimum. Otherwise it would be no better than a room air-conditioner.
That sounds awesome. There are some weird fabrics being invented nowadays. A filler with electronically adjustable thermal properties must be in someones laboratory…
yes, because you need 200MHz cpu to handle 500KHz signal …..
Easiest solution should be to use a timer in “input capture” mode to measure the time between two pulses. No need to worry about synchronizing to the 500Khz clock or using a shift register. I’d use a lookup table to convert pulse lengthes into bit bit sequences (2us -> 1, 4us -> 10, 6us -> 100, 8 us -> 1000). It may be a little bit tight to do this inside the ISR. Alternatively we could store the raw pulse lengthes in RAM and then decode them offline, sector by sector.
Having said that – I’d rather go for a 32Bit processor for a task like this (e.g. STM32). This would offer a whole new range of possibilities like USB connection to the PC instead of the serial connection. Raspberry PI Zero could also be an option. I don’t know – on one hand I don’t like too much seeing every small problem being handled by a full blown LINUX system when a simply uC could do the job as well (or even better). On the other hand, it’s more than time to bury those old 8 bit uCs except for the most simple stuff (a button and a LED maybe ;-) and move to the next level.
No problem reading MFM with an ATmega.
You use the SPI.
It samples at 8MHz on a 16MHz clock.
No need to syncronize.
I did soimething similiar and used an Teensy 3.2 which uses an Arm Cortex M4. My sketch uses timer input capture to record the bit sequences in a buffer for the whole track, by building a histogram of the transitions i can adjust the timings to reread a track which has decode errors to retry, this method works even on some disks which are unreadable on amigas. Storing all transition timings wasnt an option because the Teensy 3.2 only has 64kb RAM.
If you are interested in the source i released them under GPLv3 on my Blog:
http://nickslabor.niteto.de/download
I was working on a similar project (see http://www.nickbits.co.uk/blog/tags/amiga ), Rob contacted me a week ago and today I spotted Nick’s project. Both are fantastic and I am rethinking what I am doing. Possibly going to use bits of both and maybe a Raspberry Pi or simpler Pic 32MX. Either way, keeping an eye on both of the other projects. Well done guys.
Amiga floppies were different as was the interface method. The mechanics/drive were standard. The key difference was how data was processed. The Amiga streamed a track to or from the drive into ram. Then it located the start sector and decoded the track. This reduced the time pressure of a normal approach and improved response as you never missed the next sector, having to wait for it to come around again. A shift register and a parallel read would dramatically reduce the speed required to move track data into ram.
How about reading and writing Macintosh 400K and 800K floppies in a PC drive?
Doable — I had (probably on a floppy somewhere in my collection) a small program that would allow that. Downloaded from a BBS, IIRC.
I did something similiar with an Teensy 3.2 and a Java application running on Windows XP-10, Linux and Raspberry Pi.
My project can read and write adf files, even reading amiga HD floppies work. I documented my project on my blog, its only in german but google translate should do the job. My schematic is easy to build on a breadboard with a teensy and some jumper wires, no additional components needed besides a power supply for the floppy drive.
http://nickslabor.niteto.de/projekte/adf-copy
Congrats on getting it working on an avr! It’s great fun to do this project, I did this myself a while back but haven’t got around publishing about it yet. I used a pic16f1937 overclocked to 80MHz, used the ccp module and passed the captured byte to the rs232 to usb module in real time. I’ve recovered more than 300 floppy disks with excellent results. Hardware wise it’s very simple. The decoding is done in software, that took the largest slice of time to get right, especially with disks with weak signals. If anyone is interested, I’ve got some videos posted here:
https://www.youtube.com/channel/UCJSWen8mcsrenXGCEr2fJ9w
I’m planning open source it all soon.
There IS a software driver for older winXP style machines with a floppy drive. I recently wrote a load of disk images for my 1581 drive and you can read/write ADF as well, no need for any hardware hacking at all.
You’re mixing two things up, The 1581 was a 3,5″ floppy-drive with a serial IEC interface for the Commodore 64, and the ADF File Format is for archiving Amiga Disk Images. The is a software for reading and writing Amiga disks using a special parallel cable which required a LPT Port on the computer, because it used bit-banging there were strict timing-requirements for the machine, Only one core, Windows XP for direct hardware access, newer operating system have an hardware abstraction layer which screws the timing.