When I was a CS major in the 90's, one of my professors told me a story of his own college days, with punch-card computers.
His university bought a tape reader (like, punched paper tape, not magnetic tape) to do the boot code of the computer, on the theory that tape was a little easier to manage than punch-cards for the boot (you can't lose one of the cards, or get them out of order, etc with tape). So my prof and some of his friends start playing with the tape reader, and they realize that what controls the IO speed of the tape is actually the tensile strength of the tape -- if the feeder tries to put too much force on it, it will tear the paper tape. The actual computer can read the instructions much faster than the tape can physically handle.
So they got some plastic tape instead, and punched the boot code in the (much stronger) plastic tape. Then, to boot the computer, they'd feed the plastic tape through the part of the reader that actually read, bypassing the mechanical part that pulled and wound the tape, and then manually grab the other end and yank on it as hard as they could, basically starting the computer like it was one of those old lawnmowers that you pulled the cord to turn over the engine.
I love this kind of stuff. The fact that we (people in our field; not me specifically) had to and could do stuff like this must seem crazy ancient to the younger folks here. I did boot my first computer from a cassette tape, and I can still remember what it sounded like and it's so, so very nostalgic. And many of us did get our first internet access via these crazy noises as well. I'm sure I could also listen to a modem connecting and tell you what speed it had negotiated from 1200baud all the way up to 56k, since each new sound was, at one point, the pinnacle of excitement since I'd just upgraded to something new (and then I heard it thousands of times).
You will enjoy this classic.
It's a lovely image showing the dialup handshake . My first modem was a Hayes 1200 baud. Every modem after seemed to double. The protocols got better too. Bidirectional transfers, wow.
My first modem was a Hayes-brand 300 baud modem. Atari 800 computer.
So I'll kindly ask you to get off my lawn, whipper-snapper.
(BTW I listen to a lot of ambient / noise / drone music, and a while ago, some artist took those modem sounds, slowed them down, put in some reverb, etc. and it was downright ghostly).
The fun things about 300 baud was I could pick up the phone and hear the individual keystrokes being sent. I couldn't distinguish what particular character was being sent, unless of course I was the one typing.
Same here. I loaded programs from cassette tape into a Soviet clone of a Sinclair computer. Each program started with some sort of a loader block that produced a constant pitch. I would use a screwdriver to adjust the magnetic read head of the cassette player and listen for the pitch to be just right during the loader block in order to get the actual program to load correctly. Good memories.
When I first saw an ad for a "soon to be released" 9600 bps modem, I excitedly mentioned it on a local BBS, where all of the older wiser users told me it was impossible and the ad must have been a joke. 1200 baud was still relatively new at the time and error prone even with a parity bit so I could understand some of their skepticism. The central offices were still in the process of being converted over to digital and lines were still noisy at times. As the quality of the local loop improved, so did modem speeds.
Well never can afford one then. Did saw many a couple of years which use this to win 7! It finally come at end as the patch of win 10 s too large to bear. But nice to see some 56k us robotics after so many decades.
I always hated that damn modem screeching sound. I once popped off the speaker on the modem itself, because it was so annoying.
And then I recall, there was always a commercial playing on the radio, that had that sound. Maybe it was for the now dead U.S. Robotics. I can’t recall.
I could tell what speed my first modem connected at because my DEC modem had a physical switch to select between 300 and 1200 baud. It also had a physical switch between line and data: no acoustic coupler required for this baby.
Back in the late eighties I was in the Air Force and we had a Burroughs machine; replete with all the lights you see in old science fiction; that could be booted through paper tape. I was an octal setup. We also could theoretically boot this machine by switches but never saw that done.
This was one of the first machines built for the service that did not require tubes so that gives you the idea of the age of this and it was in daily use in the 1986-1989. Even the main base computer, Sperry 1100/60? took cards in for data input. Late 88,89 we finally got most cards down to disk images uploaded through a Sperry branded PC. My first useful Turbo Pascal program replaced the provided software and could read/write from the mainframe at many times the rate of the canned software.
We also jokingly had a kick start Sperry, one pack would stick sometimes on boot; you had to swap packs for secure processing; and the fix was to face away from it and hit the side firmly with your foot flat on.
Great story! FWIW this is kind of the origin story for Mylar "paper tape" as well. When paper tape started being used for controlling machine tools (the NC in CNC), the paper tape would not hold up well in a shop. It could get grease or water on it which would compromise its integrity and then it would tear. So a "stronger" paper tape was created but it had to be compatible with older paper tape reader/punches. It was great stuff.
Great post, it made me smile and brought some memories. Btw I did use punch tapes in the beginning of times and the speed with which the mech pulled those through was insanely fast (at least to my eye). Maybe I've dealt with some later generation tech?
Sometimes we use our phones (often no signal in the field) to send photos back to the office over mobile radio using the robot36 protocol. You just load up an image, it plays a modem sound, and the receiving station has it on loudspeaker, with another phone listening. It works remarkably well as long as the sending / receiving environment is relatively quiet.
I even had a telegram chat with my kids where we would share memes back and forth as wave files. We called it 56k meme chat lol.
It's interesting how old analog audio technology still finds itself useful in these days of terabyte drives and satellite internet.
Some retro computer enthusiasts have taken to storing their programs as MP3 files. That way they can be loaded into a cassette interface using a hand-held voice recorder. Instead of carrying around a suitcase of tapes, you can store everything in the palm of your hand. It's also supposed to help protect against bitrot, but I don't know if that's true. Still, bitrot is a serious concern in retro computing circles because one bad bit in a 10 GB Windows game is probably harmless. But one bad bit in a 10K Apple ][ game will likely ruin it.
Also, I remember when I got my Amazon on-demand ordering buttons, they were set up using an analog modem sort of thing. It's been a long while, but from what I remember, when the buttons arrived, I'd open the Amazon app and tell it I was programming the button, then hold down the button on the button thing and the button and the phone would squawk to each other. It sounded very much like a 300 baud connection, but without the underlying carrier tone — just data.
There's a very good chance that a single bad bit in a 10 GB Windows game will prevent it from loading.
The average game might contain a multi-megabyte executable along with gigabytes of assets. Those assets will be stored in some kind of compressed format (for example Quake III used 'pk3' files, which were actually zips). These compressed files with inevitably have checksums, and an invalid checksum will prevent them from loading.
You’re assuming the game engine will panic on a bit error loading what’s probably a texture or model mesh. This probably isn’t the case for most games, especially release builds. You might get a console message.
A 1-bit error in a compressed file will cause every subsequent bit in the entire file to end up wrong (well, 50% of them), and probably the file length to end up wrong, and probably the decompression state machine to get stuck and confused. This is why basically all compressed formats carry a CRC (eg. zip, gz, xz).
Most games don’t store their assets in a single one-shot-load pack file anymore. They use chunked asset files where individual assets or packs will be compressed and then concatenated with a master index, meaning you don’t have to load the whole file when the engine needs only a subset. This means the checksums necessarily cannot cover the entire data file, because then you would need to read the entire file to verify a single asset anyway, throwing away the benefits of random access. You can also turn the checksums off for “speed,” and some do.
If you have something like a Deflate stream, there is a chance that the flipped bit will affect a symbol but change it into a symbol with the same length. Could do anything from changing a single byte in the output, to changing bytes in a bounded range, to corrupting the entire rest of the stream, or making it fail to decompress (not every deflate stream is valid, far from it).
The Square card readers that plugged into the headphone jacks were also analog modems. Well, the swipe variants were just "mo" (modulators) and the phones were the "dems" (demodulators). The first chip card reader, that plugged into the headphone jack, built a full bi-directional soft modem onto either end.
In theory you should be able to update the firmware on one of the chip card readers with one of these vinyl records and a 1/8" adapter.
I wonder what the largest checksummed file you could manually (well, programmatically) test every single bitflip against, rechecksumming to see if you found the bad bit, in a reasonable amount of time is.
1 kilobit of data seems pretty doable, only a thousand variants to check. Somewhere around 1 gigabit seems like it should be too much for consumer hardware -- if it takes 1 second to re-sum the data, that's ~30 years to test every bit flip.
This is the sad NP-hard part of cryptographically-strong checksumming - the heavier the algorithm, the longer it'll take, and the harder it'll be to exhaust it on even trivial inputs.
Sometimes simply loading both copies of the data into RAM and comparing them can be faster - for scenarios where you have both copies available.
XXHash comes to mind as the (apparently) fastest non-cryptographic general-purpose hash out there at the moment; it runs close to memory speed. It would be interesting to see a microbenchmark-style graph showing the slowdown checking all permutations of 1KB, 1MB, etc.
It's a fair question. Tape interfaces had very limited bandwidth. The original Kansas standard used frequency switching (FSK) between four cycles of 1200Hz and eight cycles of 2400Hz. Later faster variations used the same frequencies but cut the number of cycles for faster load speeds.
MP3 compression works by removing frequencies that are (supposedly) too quiet to be audible. If you only have two very loud frequencies in a frame they pass through the compression process unscathed.
The switching hash around them and the tape noise may get munged but that doesn't affect the data stream. So vbr MP3 ends up being an efficient and clean representation, and cbr works too but isn't quite so compact.
Edit: in fact some radio and TV shows in the 70s would transmit software live, and that worked fine too. I never tried it, but I suspect you could probably use a phone line - for early adventures in software piracy.
Lossy codecs use psycho-acoustic models designed to encode music so it sounds okay to humans, by discarding frequencies that we're less likely to hear due to masking etc. -- Just need to avoid those frequencies.
Having said that the newer lossy codecs (e.g Opus and some AAC variants) which are more efficient (sound better at lower bitrates) and have less "problem samples" than MP3 would perhaps also be better for data use, like they are for music.
If you're going to play it over a speaker, you already have way more signal loss than the compression is going to introduce. The solution is redundancy.
The fidelity of standard non high bias tape at compact cassette speeds is already shit compared to even low bitrate mp3. It’s not a problem in practice.
There was an episode of The Modern Rogue on YouTube where they demonstrated sending pictures over cheap UHF radios using “Slow Scan Television” which Robot36 is a part of.
For those interested in learning more about this, the formal term is "packet radio" in amateur radio (ham) circles. See APRS for a standardized tactical implementation.
When I was younger we had an Amstrad (CPC6128) that had a disk drive, but not a tape drive. My cousins had travelled to the UK where they picked up lots of games, but unfortunately most were on cassette. Being desperate to enjoy the wonderful new worlds contained within, I had to come up with a solution. In my case, I cracked open my sisters ghetto blaster and wired it in to the port on the side of the Machine. Worked like a charm, and I too got to enjoy the gruelling wait on every game change.
The need to raise the BASS and reduce the Treble makes me think that the setup was missing the RIAA equalizer. If the AMP did not have a "phono" input that would be the case.
Yeah, and the treble at least was reduced exactly the amount the RIAA curve should reduce it (-10dB at 10kHz).
There are a ton of cheap "dubplate" vinyl cutting shops out there, and it seems like maybe the OP sent off to one of these shops to print their ROM. Otherwise, they could have just re-cut a new vinyl with the equalization fixes baked in...
Are you saying they could have cut it without RIAA equalisation? That probably wouldn't work as the recording might not fit on the record without it. Quoting from Wikipedia:
> The purposes of the equalization are to permit greater recording times (by decreasing the mean width of each groove), to improve sound quality, and to reduce the groove damage that would otherwise arise during playback.
I have a hard time believing this. How is a non-RIAA equalized record supposed to be played? All palyback equipment/setups have built in equalization that converts the RIAA equalized signal from the vinyl back to normal. It's either built in to the vinyl player, or done via a phono-preamp usually in the amplifier or a mixer. This isn't usually explicitly stated anywhere on the equipment as it's an industry standard.
So if you have a record that doesn't have the RIAA curve applied, what are you supposed to play it on? The RIAA correction is pretty much unavoidable on any standard playback equipment.
EDIT: I'm willing to believe this if you can reference me to some example of modern non-equalized/non-RIAA vinyls.
it's simply to maximize the run-time of the vinyl. If you didn't use the compensation curve you'd have to cut wider tracks to accommodate the lows, and that would mean you'd get less time on a side.
"We choose to go to the Moon...We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; (...)"
This blog post made me feel all warm and fuzzy inside -really- it encapsulates all curiosity, hacking spirit and adventure is all about.
Some computer magazines of the 80's actually included so called "Floppy ROMs", actually thin vinyl records, in the magazine pages ! : https://en.wikipedia.org/wiki/Interface_Age
Very cool, but where did the record come from? Was bootable vinyl ever actually a thing? I'm old enough to remember the cassette era and I never saw bootable vinyl before today. Or did they somehow do a custom press from an audio recording?
Not to mention spending hours pouring over the release notes on the album covers. The implementation detail in a gatefold cover for a dual-boot album could be intense.
Ah, the memories! Around the fall of the Soviet Union, there was an IBM-compatible clone called Poisk. It was not 100% compatible with with IBM PC, had 128 KB built-in RAM (extensible to 640 KB with a card), had CGA graphics with a composite output only, no floppy interface without an addon, etc. But it was cheap, like really cheap and only needed a TV and a tape recorder to get going. I'd say Poisk was #2 home PC after gazillion of inexpensive ZX Spectrum clones.
Article mentions that tape interface was rarely used - that was definitely not the case in the (ex)USSR.
Anyway, having spent so much time with Poisk with cassette interface after ZX Spectrum, I can still distinguish PC vs ZX tapes by just listening to them - they have slightly different tonality.
Love it. Conceptually identical to the old TRS-80 cassette tape interface. And even preserves the sensitivity to sound artifacts. Am beginning to think DOS will rise again. FreeDOS graphics mode is just as much fun to play with as PICO-8. 256 colors, 320 x 200 resolution. With modern techniques like AI Upscaling, and DOSBox emulation in browser. It doesn't seem too far fetched to say this is a viable development platform even in 2020 ;)
I remember having a TRS-80 Model I and using the cassette tape to load and save programs. I'll be honest it was a very happy day when I finally got a floppy drive!
Ataris could load bootable apps; mostly games; from tape, too. I had one; it was glitchy as hell, but oh how my early high school self rejoiced when it worked.
It's especially frustrating when the only reason for the consent banner is because they decided to use Google Analytics [1]. Just use something selfhosted like Matomo with a few privacy settings enabled [2] and then bam! no more annoying consent banners for visitors, no more Google tracking your visitors, and you still get the metrics you want. Everyone wins (well, except Google).
Or, and I know this is almost heresy here, but why not just leave off analytics? This is essentially a static page with text and images. What on earth are you analyzing? Why do you need to collect any data at all?
Vanity (in my experience). Though I don't know why web server logs aren't enough for that.
Engagement duration tracking is probably the most important thing client-side analytics brings for a site that's trying to make money, but for a personal site, seems unnecessary.
Privacy badger blocked a whole load of cookies but I was able to get rid of the banner without clicking the dumb consent button with one of my favourite addons, "hide fixed elements".
This post glosses over the whole "getting the data onto the record" process, which may not be the novel bit here but is definitely interesting as a reader.
I remember my old Atari 400 loaded programs using the 410 cassette recorder. I do wonder how much a record could hold compared to a cassette, and given just wear, which would last longer?
Also, didn't some magazine from the era ship a plastic record for some system? I vaguely remember it, but I could just be imagining things. It was actually square with the 45 size record printed in it.
Very similar to the sound of the Commodore data tapes when inserted to a regular cassette player. Tried it as a kid, I was convinced I broke something.
Dual cassete players were great for copying programs/games!
Also reminds me of Amiga's Video Backup System which made use of Amiga's video processing capabilities to output data and read from VHS tapes. That was a slow process but could store large amounts of data, and you just needed a VCR.
That was your modem negotiating the protocol and speed with the remote modem, not proper data. Still, if your mother happened to use the phone line while you were connected, she would heard the actual data on the line, just before the connection broke. Oh, the times.
Best feature of BBS software (WWIV, Telegard, etc.) - the "fake line noise" button, which feigned data corruption as if someone picked up the phone. It displayed garbage characters to the logged in user, and then you could disconnect them.
Dial-up modems used the public switched telephone network to transmit data via audio signals through regular phone calls. The modems had an internal speaker so the operator could “debug” the connection with their ears, e.g. if they called the wrong number and an actual person was talking on the other end.
It literally sounds like guitar wow pedel when it happens. It's due to the fluctuation of the speed of the turntable.
In that video the turntable seems like Audio Technica's Technics 1200sl knock-off version which is quite infamous for instability, it seems fine in short video though. Very impressive nonetheless.
Wow is slow frequency speed variation.
Flutter is fast speed variation.
To an audio person they are distinct sound artifacts.
It was common to listen to recordings of pianos in the past to hear these because the piano was the only common instrument that had very solid pitch. (invariant frequency(
Cool! I'm having a flashback to the time a friend and I decoded the "300 BPS N, 8, 1 (Terminal Mode Or ASCII Download)" track from Information Society's Peace and Love, Inc. album.
I recently became curious about whether vinyl records might be a good choice for long term widespread backup of the information needed to bootstrap back to a full working Turing complete runtime, sort of as seeds for some future where much of the knowledge about computing had been lost. Somewhat absurd scenario, but interesting from a technical point of view due the the constraints you have to optimize for.
Depending on what assumptions you make about the effective bandwidth available on a 33 rpm lp record is somewhere between 225MB and 15MB. That is easily enough space to fit a full fledged implementation of Common Lisp on somewhere between 1 and 4 records (SBCL's working tree is 40MB, and with its .git folder it is 152MB). There are countless other factors that would need to be considered, but I still like to imagine a sci-fi story about the search for the 5th record of lp-lisp needed to reboot civilization! The fact that someone has actually done something even remotely related to this is fantastic.
Vinyl is a bit soft for long term archival; harder materials are better!
The Long Now Foundation has something very like this with the Rosetta Disk - it's a language archive on encased metal disk, and designed to be read optically; the first parts with the naked eye and the rest with a microscope.
Microsoft is also developing something similar for commercial use in Project Silica.
> I recently became curious about whether vinyl records might be a good choice for long term widespread backup of the information needed to bootstrap back to a full working Turing complete runtime, sort of as seeds for some future where much of the knowledge about computing had been lost.
> the effective bandwidth available on a 33 rpm lp record is somewhere between 225MB and 15MB. That is easily enough space to fit a full fledged implementation of Common Lisp on somewhere between 1 and 4 records (SBCL's working tree is 40MB, and with its .git folder it is 152MB). There are countless other factors that would need to be considered
Don't vinyl records experience physical decay over time?
They definitely do, but we have much better historical data about the time course and about how to care for them so that they don't go as quickly. There is also the possibility to stamp them out of something that is more resistant to decay.
Some of my thinking was that so long as the decay was decorrelated multiple copies of the same record could provide redundancy, though that applies to many other candidate media for these kinds of projects as well.
The best option for long term archive is probably still characters printed out on paper, but getting that back into a working system can be quite a bit harder depending on the size of the codebase you want to restore. Of course all these assumptions are probably wildly inaccurate about the relative probably of events, e.g. of someone having a record player and a functional CPU while also not having a scanner. However, another objective here was to reduce the number of steps that had to be performed by a human being that could go wrong. A run of the mill office scanner doesn't quite fit the bill because it might have been cannibalized to be the CPU and because scanning in 40MB of printed pages is much lower bandwidth than the record. So end the end the calculation comes out to be the relative likelihood of having a record player and a CPU but not a modern automated book scanning system, and there the odds seem very much in favor of the record player.
> The best option for long term archive is probably still characters printed out on paper, but getting that back into a working system can be quite a bit harder
Here it definitely depends on what your goals are. The best records we have from the past, in terms of their ability to survive, are fired clay tablets. Paper records really only survive in very dry environments. (Special documents, notably peace treaties, could be inscribed on metal. But the metal used was generally silver, for its value, which isn't ideal for archival purposes.)
With more modern technology, we can do thinner stainless steel plaques, which solve the problems of tablet thickness and metal rusting. They would also be more difficult to shatter than fired ceramics. Such an archive would survive far, far better than a collection of paper. It would be more expensive, and bulkier.
Laserdiscs definitely show rot, but I haven't heard of any decay personally on vinyl (other than very subtle wear from the stylus every time you play it and other mechanical damage).
"Inside the Apple //e" included a program listing to digitize sound using the cassette interface[1]. Years before I got an audio digitizer for a PC I had great fun recording a few seconds at a time of audio on the machines in my public library. I made some floppies that booted and played audio samples. They were super slow to load and the sound quality wasn't great, but voices and songs were recognizable.
'Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.'
No, seriously; though, as a programmer by day and turntablist at night this tickles both my nerd fancies hilariously.
It, of course; makes entirely logical sense, as booting from tapes was obviously common back in the day.
The turntablist side of me also needs to know how they managed to get it on the record. Is it just a dubplate? Do they have friends with a lathe? The article doesn't mention the process of getting that audio onto the vinyl. Surely it had to be custom-made for the process.
I haven't seen this mentioned in the article, but the BASICODE project (Netherlands, UK, West- and East-Germany) was a "real world example" where program code was distributed on vinyl records (and via radio stations):
So is this audio (cassette) boot method still there in modern pcs? I would love to have a pc that had to be booted by playing a track, then executing a hdd bootloader
One of the improvements of the 1983 PC XT (5160) over the 1981 PC (5150) was the removal of the tape port since nobody was using it and it was an extra (and confusing) connector on the back. The other improvements were more on-board memory, more slots (closer together) and HD support.
You could add a hard disk to the original PC, but it wouldn't boot from it as the code in the BIOS wouldn't recognize your HD controller card (initially MFM like you said, a few years later RLL before we moved to IDE/ATA and eliminated such complications).
With the XT the BIOS would search upper memory for extra ROMs and the one in your HD controller card could patch the entry code for INT 13h so it could try to boot from the HD. If that failed it called the original INT 13h which would try to boot from a floppy.
On the software side we had a similar evolution. The first versions of DOS included all the drivers for all devices you might have. If some manufacturer wanted to add some new hardware it would have to ask Microsoft to compile a new version of DOS just for their machine. That didn't scale at all and soon the extra drivers were split into their own .sys binaries which could be loaded by autoexec.bat as needed.
This is really neat. So I get that booting from non-standard devices is just a matter of digital signal processing. Really interesting using an amplifier get the signal. I imagine you can do almost any sort of analog to digital method. How about doing a boot loader from tin cans and a string? Being silly but in theory it should work.
This is of course possible since booting was much simpler when all it had to do was read from the boot device into memory and jump to it. Definitely simpler than the horrible mess that is UEFI booting...
I suppose it is solid-state. Makes me think there's an alternate universe out there where steampunk reigned supreme and records like this are the path that tech went down when the computer age hit.
I do remember loading programs from cassette on my Vic-20. Occasionally I'd pop them into my Sears stereo to hear what was actually on them. Never thought of hooking up the phono. :D
This is sweet.
I wonder if someone has hacked coreboot to boot from a UART, parallel port or sound card? That could make this viable with very little extra hardware as well.
LOL, this must be the coolest project on a computer, I have come across, so far! I mean, how could you even come up with such a crazy idea? Nerds... :-)
His university bought a tape reader (like, punched paper tape, not magnetic tape) to do the boot code of the computer, on the theory that tape was a little easier to manage than punch-cards for the boot (you can't lose one of the cards, or get them out of order, etc with tape). So my prof and some of his friends start playing with the tape reader, and they realize that what controls the IO speed of the tape is actually the tensile strength of the tape -- if the feeder tries to put too much force on it, it will tear the paper tape. The actual computer can read the instructions much faster than the tape can physically handle.
So they got some plastic tape instead, and punched the boot code in the (much stronger) plastic tape. Then, to boot the computer, they'd feed the plastic tape through the part of the reader that actually read, bypassing the mechanical part that pulled and wound the tape, and then manually grab the other end and yank on it as hard as they could, basically starting the computer like it was one of those old lawnmowers that you pulled the cord to turn over the engine.