Booting A PC From Vinyl For A Warmer, Richer OS

If you’ve scrolled through the list of boot options offered on any PC’s BIOS, it reads like a history of storage technology. Up top we have the options to boot from disk, often a solid-state drive, then USB disk, optical drive, removable media, and down the bottom there’s usually an option to boot from the network. Practically no BIOS, however, has an option to boot a PC from a vinyl record — at least until now.

Clearly a project from the “Because why not?” school of hacking, [Jozef Bogin] came up with the twist to the normal booting process for an IBM-PC. As in the IBM-PC — a model 5150, with the putty-colored case, dual 5-1/4″ floppies, and one of those amazing monochrome displays with the green slow-decay phosphors. To pull off the trick, [Jozef] leverages the rarely used and little known cassette tape interface that PCs had back in the early days. This required building a new bootloader and burning it to ROM to make the PC listen to audio signals with its 8255 programmable peripheral interface chip.

Once the PC had the right bootloader, a 64k FreeDOS bootable disk image was recorded on vinyl. [Jozef] provides infuriatingly little detail about the process other than to mention that the audio was sent directly to the vinyl lathe; we’d have loved to learn more about that. Nonetheless, the resulting 10″ record, played back at 45 RPM with some equalization tweaks to adapt for the RIAA equalization curve of the preamp, boots the PC into FreeDOS just fine, probably in no more time than it would have taken to boot from floppy.

It’s may not be the first time we’ve seen software on vinyl, but it’s still a pretty cool hack. Want to try it yourself but lack a record-cutting lathe? Maybe laser-cutting your boot disc will work.

Thanks to [John] and a bunch of other folks who tipped us off on this one.

60 thoughts on “Booting A PC From Vinyl For A Warmer, Richer OS

      1. “The limits of data storage depend on the technology to write and read such data. The theoretical limits assume a scanner that can perfectly reproduce the printed image at its printing resolution, and a program which can accurately interpret such an image. For example, an 8″ × 10″ 600dpi black-and-white image contains 3.43 MiB of data, as does a 300dpi CMYK printed image. A 2400ppi True color (24-bit) image contains about 1.29 GiB of information; printing an image maintaining this data would require a printing resolution of about 120,000 dpi in black and white, or 60,000 dpi with CMYK dots.”

        https://en.wikipedia.org/wiki/Paper_data_storage

        1. There was software called 3D FAX that encoded files a TIFF images. They could be FAXed to a FAX machine and printed or to a computer with a FAX modem.

          To decode the files the receiving software could scan the printed sheets or be fed the TIFF images.

          There was quite a bit of redundancy in the encoding so up to a certain % of the image could be ruined while still recovering the data.

          The receive only software was a free download and came with some demonstration images to decode. The send/receive version was a paid program.

          Can’t find the software anywhere. There were Windows and Mac versions.

          With the processing capability of smartphones it should be possible to write decoder apps to convert 3D FAX printouts to their original files.

          https://www.youtube.com/watch?v=a6y8cqayjQI

      2. I think there’s no practical limit for the inefficiencies one could achieve:
        – Stone tablets carved in binary
        – Using stone monoliths to represent bits
        – Setting up a selective breeding program for elephants in order to have them trumpet out the message in Morse code by instinct.

      3. Step 1: Implement a physics engine to compute digits of pi using idealized sliding blocks, as described in: https://www.youtube.com/watch?v=HEfHFsfGXjs

        Step 2: Plan on finding a sequence of digits within pi that exactly correspond to the bootloader, so you can store just the index (the number of digits you have to compute until you get to the bootloader).

        Step 3: Plan on recording the index and the physics engine with a selectively-bred herd of elephants (see comment by CityZen).

        Step 4: Describe the awesome idea in TED talks.

        Step 5: Raise money on Kickstarter to fund the unfinished plans.

        Step 6: Pocket the money without finishing the project.

        Step 7: Profit!

          1. Yep, that is precisely one of the problems with trying to use transcendentals like pi as a compression system. At present it hasn’t even been proven that pi contains every possible string (search for “normal numbers” on math sites if you want details). Sadly, raising money for a project is not constrained by the mathematical impossibility of the goal.

      4. We did an exercise in artificial stupidity in university along these lines; the worst algorithms always involved random correctable mistakes.

        So, for instance, take the algorithm you have with the OCR, but require 127 copies of transmitted, where each bit is randomly correct in exactly 64 of those copies (but which 64 is random, and independent for each bit).

        I’m sure there are ways of getting it even worse.

    1. Phonocut‽ Ok,

      Ha Ha Wow! And it’s only €2.499,00!

      Next thing I notice is the audio input. Looks like mono. I thought that was a bad thing but then I realized the intended market probably would see it as a feature.

    1. I remember in the days pre-hard drive I had a Tandy w/ DOS built into a ROM. But it was an old DOS and I had a newer version on Floppy. Some software required the newer OS. I had two drives but I liked keeping the OS off of both of them so I could easily copy things back and forth or run multi-disk programs w/o swapping. I would have gladly booted off a record in those days!

  1. I’m not sure it took quite that long to boot from floppy back in the day, but it’s been a long time since I last owned a computer like that, so I could be mistaken.
    That being said, this is simply awesome.
    It reminds me of trying to load programs into my old TI-99/4A using the tape recorder. One bump to the volume control and one had to start over, and that was after spending some time trying to set the levels correctly again. What a pain, I don’t miss it.
    Again, this is awesome.

    1. Floppies were *fast*. Not instant-on like ROM firmware, but like greased lightning compared to cassette transfers. Tape might get you 1500 bps to floppies at 125000 or 250000. Being essentially audio it’s not surprising the vinyl load time is more like the cassettes.

      And copy that, re fiddly levels on tapes. Mine was a TRS80 mod 1, with similarly flaky tapes. Never did get to personally own disk drives for that system, but my school had them. The first thing I learned in the first five seconds with that disk system was “tape is garbage”

      1. The only small disk system that was horrible out of the box was Commodore’s 1541. Single sided and didn’t use the index hole. Super ultra slow without some hacks.

        I had a TI-99/4A (seven consoles and two PEBs) but never had the $ for an aftermarket double density floppy controller so I was stuck with DS/SD. FAST loads and saves with floppy.

        One variant of the TI used a 12Mhz crystal for timing control of everything. I put in a 14.31818 from an old PC and a toggle to switch between them for overclocking. Worked fine for *almost* everything. When playing Super Demon Attack it shifted the enemy locations and where their shot sprites spawned so the player became un-hittable but could still shoot the enemy. :) The other main (pre-1983 QI revision) version used more than one crystal and isn’t (easily) overclocked.

        I also trimmed the sides of the case next to the joystick and cassette ports to install screw posts so my home made cables would stay firmly attached. I built a dual 2600 stick adapter into a DB25 shell with insert pins. Had enough room to fit a stick plug into each end and I glued a trapezoid of wood in the middle to make it two sockets. I took my TI Wired Remote Pinky Pinchers apart to figure out how to do the diodes in the stick adapter. Another mod was cutting a trace and soldering a diode on the keyboard to fix TI’s engineering fail on the Alpha Lock key that blocked the UP direction for joysticks when Alpha Lock was on.

        School had a room with Commodore 64s. I discovered that I could make a super loud squealing sound by gently dragging the palm of a hand perpendicular to the vent slots atop a 1541 case. :) Took just the right pressure and not too dry or damp.

        1. Oh yeah, those 1541s were dogs. The actual bit rate off the head was comparable to TRS80 or Apple II, but only dumped data into a local buffer inside the 1541, which then transferred it to the C64 serially, and almost as slowly as tape.

          And yeah that noise from rubbing the vents was about like nails on a chalkboard. Good times!

  2. The obvious next step: See if you can get a buffer overflow from scratching.

    I’m also left wondering… if you play it backwards, do you get a SOD prompt loaded into the lower 046k of memory? Or does it just give you ASCII art of Paul McCartney and a walrus?

Leave a Reply to AKA the ACancel 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.