Floppy Autoloader Takes The Pain Out Of Archiving 5000 Amiga Disks

floppy-autoloader

Archiving data from old floppy disks can be a tedious process at best. Poorly labeled disks combined with slow transfer speeds put it high on the list of things we would rather not do, and it turns out that [Dweller] was of the same opinion. With an estimated 5,000 floppies in his collection, he finally decided it was time to clean house.

With no idea of what was stored where, he decided the best way to go about the process was to read all of the disks, archiving everything, saving the sorting process for later. He originally started by building a floppy autoloader out of Lego Mindstorm parts, which looked good on paper, but performed pretty poorly.

He came across an old floppy duplicator on eBay and figured that since the machine was built for handling gobs of disks, that it was the perfect base for his autoloader. He pulled the mechanical bits from the machine, incorporating them into the rig you see above. He swapped out the duplicator’s brains for an Arduino, which allows him to batch copy his disks and save a picture of each label with little effort.

He says that the system works great, making his life a lot easier (and less cluttered!)

Check out the video below to see his floppy autoloader in action.

[youtube-=https://www.youtube.com/watch?v=H5lkxSY7QsI&w=470]

70 thoughts on “Floppy Autoloader Takes The Pain Out Of Archiving 5000 Amiga Disks

    1. whdload is all well & good for the games that support it, and the Amigas I have left do have hard drives.. and their data is already archived.. it was the rather large pile of floppies that were the problem needing solving.. Some of them hold stuff I wrote back then, some have tracker tunes, midi files, data files etc I don’t want to lose, of course, now they are lost in a large dir full of data, but that’s easier to sort through =)

    1. Lol, it’s like you are reading my mind.. but I had to do this project partly to rescue the data before it became irretrievably lost.. and partly because the space where I was storing the disks was required to hold other stuff.. No doubt I will be receiving strong ‘encouragement’ to lose both the disks and the autoloader before the year is out.. Ideally I’d find someone with a similar problem & pass it on.

    1. Heads up but the dyes in burned DVDs do deteriorate to the best of my knowledge. I have a few I burned way back when that can no longer be read. no sunlight or scratches either.

  1. Very nice… too bad there isn’t another purpose for this machine once your done archiving your floppies because it seems work so good ! maybe the code and idea can be used to build a CD/DVD autoloader for batch ripping ?

    1. “A certain” thrust bearing manufacturer uses a process very similar to this to load loose bearings into a machine. Probably in use elsewhere, but there at least it was known as a “stack feeder”.

  2. I wish I had had one of these in 1999 when I had to leave all my floppies behind to emigrate.

    … And a hard disk at current price per gigabyte of course.

    ===Jac

  3. Wow, I forgot how slow floppies were. Even at 6x playback, that thing is really slow.

    I feel like it takes an inordinately long amount of time to snap a picture. Can’t you trigger it with an optical break and the arduino to snap the picture as the disk slides past, without the solenoid/delay?

      1. If the disks are all loaded in the same direction… there’s not much need to orient the image. Just adjust the camera before hand and every label should be in the same place. I think? I’d simply do the adjustment in a batch in Photoshop or something as post-process.

        Anyone else think he should now reverse the loader and make it into a floppy disk auto-turret?

      2. yes, all the disks are loaded in the same direction, so all the jpgs have the same shutter orientation, but there was a total lack of agreement as to which way up you labelled a 3.5″ floppy, so I have to rotate the images in the archive management app I’ve created .. which is using CRCs of the disk image, against the Tosec dat files, to auto identify as many as possible, and letting me go in to fill in the rest.. many evenings ahead of me to add metadata for all the other images.. I’m hoping to publish a dat of my own at the end, for any disks that others might have.

      3. To accomplish that you could spend 10 hours writing and testing the code to do that or you can spend 10 minutes adding a second solenoid in parallel and making sure the camera is properly aligned. Personally I like the 10 minute solution.

      4. And most of the time spent taking the photo, is actually the time taken to transfer it back from the camera over USB, which takes a while, but at least it means I get a decent resolution image, autofocused etc, rather than the 320×240 webcam shot I started out with.

      5. You could do the real hacker’s 10 minute solution: Digital camera with its own storage, solder relay to shutter trigger switch. Disk fall sthrough, Arduino brain senses light break photocell, triggers shutter via GPIO/relay.

        Download images later and associate with same files by number/order, or write a little util to do it for you. Adjust the disk speed with the angle of the ejection ramp, so there wouldn’t need to be too much trial-and-error with the timing.

        I also wouldn’t mind seeing these floppies turn into projectiles via the two-spinning-wheels type launcher. Maybe hack up a tennis serve/pitching machine to shoot them?

    1. It’s a bit slow, because it’s not just reading the data, its storing the raw mfm track timings, and attempting to validate each track as amiga formatted (since thats the bulk of the data) and when it fails a validate, it re-reads the track a few times to see if multiple reads helps it get a valid checksum. So for some raw tracks it stores a bunch load of revolutions worth, to give more data to reconstruct the track from later.. that’s all down to the kryoflux, which as a data preservation bit of kit does an awesome job.. better than the mfm flux encoder I’m building on the STM32 olimexino..

      1. I was wondering about read errors. One of my great enjoyments of leaving floppies behind besides the size issue was the “floppy not formatted” error I got half the time from bad floppies or misaligned drives.

  4. The sobering part for those of us who remeber floppies is that depending on how he’s got the camera setup, the photo of each label is probably larger than contents of the actual disk itself.

    1. Sadly the disks are only pushed out by the eject spring inside the drive, it’s one reason I ended up mounting the entire thing 45′ to help get out problem disks.

      Gotta wonder if spinning the magnetic part of the disk one direction, while giving the casing opposite rotation might help stabilise the flight tho.. but I doubt the center would spin by itself long enough after the motor disconnects, to help much..

    2. thats what i was thinking!

      (PS: cool autoloader, a true hack :))

      write the data/coordinates to a file on disk and load into disk hopper

      have a turret/autogun that uses the data on the disk (auto-cheating) to shoot it in the right instant and direction ect

      like skeet shooting, execpt its all automatic and 100% ACCURATE hehehe

  5. Nice build – no doubt about that.

    But now he has 10G of non-sorted stuff he hasn’t needed, hasn’t looked at for who knows how long, stuffed on a hard drive someplace he’ll never need, will never look at, etc.

    Maybe he’ll be on the hoarders TV show next.

    1. It’s over 50gb of data, and sure the vast bulk of it I’m unlikely to ever need to use again, then there’s a small chunk I’m likely to want to hang onto for nostalgia value, and a yet smaller chunk that I’ll be happy to have accessible again.. And 50gb is pretty much nothing these days as far as storage goes.. I can dump the entire lot onto a usb key, or just leave it on the home server.. either way its taking up way less physical space than before, and its now accessible & indexable without needing to find the ‘right’ disk in a huge collection.

      With storage increasing in size the way it has, storing all your old data becomes easily doable..

      If hoarders did a data version, I’m sure there’d be quite a few ppl ahead of me in the list ;p

    2. 10G? 5000 disks at 1.44MB = 7.2GB ? unless there 720KB? then its more like 3.6GB

      and at 250 disk in 12 hours (so 250 a day). It’s going to take him 20 days just to create the backups. Then 15 minutes to make DL-DVD backup.

      Funny how it takes him 12 hours to store 360MB of data. I can download that much info in a couple minutes with todays technology.

      p.s. replace eject with high power spring maybe? so it can shoot across the room.

    3. I was thinking the same thing. It’s like having a personal storage unit or garage where you store all of your crap that you will never need again, but just don’t want to throw away.

      This is an awesome hack, though.

  6. That’s actually kind of funny. He has gobs of floppies that he needs to go through and do whatever with. So, to save space and speed up his own UI time, he automates the process of transferring them to a different media, eg HDD.

    Here’s the catch. Once he’s done transferring everything to a HDD. Then the time spent writing a database to track and access the files. He’ll do what I do, leave it on the HDD for the rainy day that never comes.

    A few years down the road, that HDD will get full so he’ll either transfer the whole gob to a larger capacity drive or, I do this a lot, just outright replace the old drive and store the old one.

    In about twenty years we’ll see a HaD post about a dude who needed to auto-extract HDD images to whatever the media of choice is in the future.
    :)

    1. I’m pretty far through writing the app to organise & categorise the disk images, (coverdisk, which mag, sound samples, amiga, st, pc, game, etc) .. about 1 in 5 of the disk images were identifiable via CRC against the Tosec database, of the remaining 4 in 5, 1 in 5 are ‘my’ data, 2 in 5 are likely stuff that is well known where my copy is altered somehow (bootblock changes, timestamp changes, etc).. and the last 1 in 5.. who knows, pc formatted? st? mac?

      The data is currently on a 27tb array, so I doubt I’ll miss the space, or need to move it onto a new disk for a while yet.. although yes, I do have an entire shelf full of old hdd’s, I started cloning the data from those to the array years ago..

    2. He could be doing this in the first place because he needs/wants the data NOW…not on some rainy day. Or because he’s tired of using tons of floppies for what a HDD can do with a single unit.

      I’m not exactly a fan of floppies. I had exactly one floppy disk left in my apartment(Win 3.1, disc 3), and I cut up the mag media last week to make a visible light stop for my IR camera.

      1. I used the browser word search function at the blog to look for the word error, but it wasn’t found. I wonder how this handles a disk error of any sort? I like how this build, and video documentation is so complete, complete to the point the video’s music track was created by the builder. Nice work.

    1. “I wonder how this handles a disk error of any sort?”

      The kyroflux is recording raw mfm flux timings, within that there can only be illegal mfm sequences.. I’m asking it to also decode that to ADF (amiga formatted track data), which it uses to decide if the track really was amiga, if the checksum is good/bad. For bad tracks, or unknown tracks, it head jiggles, and rereads the track multiple times. The stored raw data can be used to replay having the disk present, and reinterpet it as different formats without needing the actual disk again. (eg, where the amiga had written 720k dos format for interop)

      Won’t help for physical damage, or head misalignment, or sectors lost to LamerII, but helps a lot with regular disk problems.

    1. Indeed, I was noodling around on Cm, and found the dr who theme fitted nicely on a blues chord set around there, so hit record & had a play.. figured time travel was appropriate for reading floppies ;p

  7. I remember when I parted with my amigas. That last data transfer over. The harsh keep and kill decisions.

    Paid my way through college with it. Those were the days.

    btw, the images would only be 8bit if they started on a pc. They would be 12 bit on the amiga.4096 color HAM. At a glorious resolution of 320×400.

    Unless you’re talking the Amiga 4000. It had more, but I dont recall what it was. Never bought one.

      1. Video toaster 2.0. So I had 24 bit, just not real time. GVP 030 and 040 accelerator cards. 17MB of high speed ram. Ah the days!

        I think my toaster box all told was over $10k just inside it. Never mind all the stuff it hooked up to.

        Amazing to think I can do more with about $400 in hardware and software now.

  8. i would improve this by the following:
    solanoide actuates a horizontal bar instead of just 1 tiny pole. – aligment fixed , even better if you make a V shape so it falls right in there.

    meta data filling – it’s kind of simple –
    last data written -> time = (+- ejection)time <- last picture taken.

    run jpg's trough some OCR to fill in most common bitts (copyright yada yada) and do the special font title yourself.

    now make a double or quattro loader that simultaniously eject the floppys so they can be scanned by flatbed scanner.

    1. The solenoid was borrowed from inside the original duplicator, so I went with what I could make work with the least effort there.. even using the tiny pole, no disk ever ‘escaped’ so it did its job.

      A V shape to have the disks straighten up a bit would have been a good idea, you have to keep it wider at the top, as the positioning at eject isnt exact, the disk has already fallen 4 or 5 inches. Instead, I’m doing that post using software, it’s pretty simple to have the images rotated & cropped down to just the disk part.

      Very few of the disks have info thats worth OCRing, those that do are usually coverdisks, and you get way more metadata for those just by associating the hash of the ADF via Tosec to online info for the disk in question.

      All the data is stored disk by disk to a subdir that uses the timestamp of the capture as its name. That’s enough to keep it unique, and I use ADFInfo to pull the amigados volume name, and various amigados check results where applicable.

      The adf for each dir is cross checked against Tosec checksums, and against all other dumps by the autoloader, this at least lets me handle dupes easily, and rule out already known disks.

      After all that, I still have to hand process roughly 4/5 of the dirs. I found a nice amigados processing library in Scala, and I’ve integrated that, so from the cataloguing tool, I can browse into the adf, to let me confirm if a disk really does contain what the label said.

  9. The biggest problem I had when reading old Amiga (and PC) floppies is that they really do not age well, almost all of mine were unreadable after 20-odd years, giving read errors and screeching sounds.

    For newbies, there’s a utility called Transdisk which can image a floppy on a real Amiga (as well as put images back onto a floppy), although this will not work with copy-protected games. There are various methods to transfer the resulting images to a PC, much cheaper than this method!

Leave a Reply to HirudineaCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.