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.
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.
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.
"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.
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.
Could you use a tortilla instead of the vinyl record ? I immediately thought of a video I saw where a tortilla was used as a record, and some music could actually play back, although it was very distorted.
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 ;)
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.
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!
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".
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(
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.
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 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.
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...
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.
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.
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).
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).
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'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.
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.
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.
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.
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.
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.
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.
166 comments
[ 2.8 ms ] story [ 174 ms ] threadRandom example: https://www.youtube.com/watch?v=wVsY9PVIKsQ
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.
I’d note that as then-large amounts of data.
“520MB will fit on a 4-hour tape!”
Danmere Backer was similar for PCs, with custom hardware; they got up to 4 GB a tape.
https://en.wikipedia.org/wiki/ArVid
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.
At least for modems near the end of the period. The very first ones at 300bps really did sound like cassette audio.
This blog post made me feel all warm and fuzzy inside -really- it encapsulates all curiosity, hacking spirit and adventure is all about.
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.
[1] http://boginjr.com/gdpr/
[2] https://matomo.org/faq/new-to-piwik/how-do-i-use-matomo-anal...
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.
Quite a petty design choice if you ask me.
> wow², n.
> Slow variation in the pitch of a sound reproduction resulting from variations in the speed of the recording or reproducing equipment.
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(
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.
Reminds me of the vinyl records with games on, that were sometimes included with home computer magazines in the 80s: https://www.rediscoverthe80s.com/2014/01/80s-first-video-gam...
What's the baud rate?
https://en.wikipedia.org/wiki/RIAA_equalization
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...
> 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.
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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_cor...
WAV or FLAC i could see, but MP3?
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.
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.
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.
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.
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.
https://youtu.be/tVi9zEJkJ9g
So, HD support, that required an MFM card?
Also, do you remember a game called ‘Round 42’ or ‘Janitor Joe’?
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.