Oh, that’s not new tech.
Programs used to be on standard audio cassettes.
In fact, there were even radio shows that would broadcast games. Listeners could then record the audio onto a cassette and play it on their zx spectrum or commodore 64
It’s all data, whether that data is text, an image, audio, or a binary containing computer code.
Raw audio data is just a series of amplitudes. It has a bit depth (which says how many bits are in each amplitude sample) and a frequency (what is the change in time going from one amplitude to the next). Using those, you can convert it to an analog signal that can be played on a speaker. And if you use the same values to convert that signal back to digital, you end up with the same input signal (though with some random noise added and if you get unlucky and your sample phase lines up with the player’s transition phase, you won’t be able to extract the original signal, though it might sound similar). The multiple recordings help mitigate these issues.
Given that data format, any arbitrary file can be treated as raw sound that can be transmitted as analog audio.
The only real difference between this and other transfer methods we use to transfer files is that this involves a less reliable conversion from digital to analog back to digital because it wasn’t designed to do that like USB, COM, wifi, etc connections are.
There were also TV shows that would have a little flickering box in the top right corner. You would attach a diode to the screen and by the end of the show, you had a working program recorded to cassette.
Programs were not just distributed on cassettes and via radio and TV broadcasts. There was software distributed on vinyl records as well. The very first programs distributed on CD were stored on CDs as audio.
All of this was done, because floppy disks and especially floppy drives were hideously expensive - and hard drives even more so. It wasn’t unusual for a floppy drive to cost more than the machine it was attached to. Everyone had a cassette recorder at home though and knew how to operate it.
If this seems cumbersome, consider that one of the most important software distribution methods for home computers in the '70s and '80s was through so-called listings: Magazines would print the program code and you manually typed it in, line by line. We are talking cryptic assembler code, not something an ordinary human being could actually understand:
If you were very lucky, there were checksums. If not, have fun going through every single one of the hundreds to thousands of lines of code, trying to find that one mistake you made. In case you were a kid on a tight budget, it wasn’t uncommon that you didn’t actually have any storage media to save this code to, so if you wanted to play a game, you had to type it in anew every time.
Even if you stored it on cassette tape, loading times on for example the C64 were typically between 15 and 30 minutes, if it loaded correctly.
Sending data over audio was how dial up Internet worked. My guess here is that the audio playing hardware loses the ability to come to a stopping point at the end of the audio file after a crash and starts playing the data in the memory after the audio file ends as if it were audio.
The guy who uploaded the video that corporate content farm is “reporting” on actually covers exactly why this happens. In short, the gba plays sound from a certain part of ram, which a cpu interrupt continously refreshes. In the event of a crash, it keeps playing sound, but doesn’t get the interrupt to keep it playing the proper data from ram. If you let it cycle through all of ram, it eventually leaks out and just starts playing, well, everything else, eventually getting to the game rom.
RelevantVideos
A signal is a signal. For system hardware developers it might have been a quick and dirty way to debug the hardware. It could also be an abandoned feature for low level developers and cartridge development teams. We may never know the real answer but it’s not an unreasonable thing to use the thing designed to output waves as a quick hookup point for logic analyzers / oscilloscopes.
If I had to guess possible reasons off the top of my head:
1: the aux cable and port are a very common for factor for electronics of all sorts, especially computers. So you could probably transfer that data to non-Gameboy devices and not have to manufacturer more proprietary GB ports which you may also have to write drivers for on your non-GB hardware. And your customers would also go through the hustle, if you require them to use your proprietary debugging hardware and drivers, when they inevitably test and debug their own games for your console.
2: in the event of a crash, the kernel might better be able to handle the aux than the proprietary port. Pure speculation by me.
Regardless of any possible reasons or strangeness, it just seems much more probable to me that the behavior of dumping the rom over the audio port is a design choice rather than a coincidence.
Could be that their audio playback is done by hardware reading from a low address buffer in parallel to the rest of the logic and just relies on that logic to update pointers otherwise it will run through the entire address space.
Or it could be their way of implementing a full address space dump on a crash without large amounts of storage available and that just includes the ROM because it’s a part of that address space. But in the video, they were able to get a 100% match for the ROM using an emulator, so this isn’t it unless they didn’t mention chopping off a RAM section.
When I read shit like this I realize I don’t know a damn thing about computers
Oh, that’s not new tech.
Programs used to be on standard audio cassettes.
In fact, there were even radio shows that would broadcast games. Listeners could then record the audio onto a cassette and play it on their zx spectrum or commodore 64
https://en.m.wikipedia.org/wiki/Ventilator_202
What the fuck, see know nothing about computers, despite a career in IT and a homelab addiction
It’s all data, whether that data is text, an image, audio, or a binary containing computer code.
Raw audio data is just a series of amplitudes. It has a bit depth (which says how many bits are in each amplitude sample) and a frequency (what is the change in time going from one amplitude to the next). Using those, you can convert it to an analog signal that can be played on a speaker. And if you use the same values to convert that signal back to digital, you end up with the same input signal (though with some random noise added and if you get unlucky and your sample phase lines up with the player’s transition phase, you won’t be able to extract the original signal, though it might sound similar). The multiple recordings help mitigate these issues.
Given that data format, any arbitrary file can be treated as raw sound that can be transmitted as analog audio.
The only real difference between this and other transfer methods we use to transfer files is that this involves a less reliable conversion from digital to analog back to digital because it wasn’t designed to do that like USB, COM, wifi, etc connections are.
There were also TV shows that would have a little flickering box in the top right corner. You would attach a diode to the screen and by the end of the show, you had a working program recorded to cassette.
Programs were not just distributed on cassettes and via radio and TV broadcasts. There was software distributed on vinyl records as well. The very first programs distributed on CD were stored on CDs as audio.
All of this was done, because floppy disks and especially floppy drives were hideously expensive - and hard drives even more so. It wasn’t unusual for a floppy drive to cost more than the machine it was attached to. Everyone had a cassette recorder at home though and knew how to operate it.
If this seems cumbersome, consider that one of the most important software distribution methods for home computers in the '70s and '80s was through so-called listings: Magazines would print the program code and you manually typed it in, line by line. We are talking cryptic assembler code, not something an ordinary human being could actually understand:
https://i.imgur.com/NW4Mhp6.jpg
If you were very lucky, there were checksums. If not, have fun going through every single one of the hundreds to thousands of lines of code, trying to find that one mistake you made. In case you were a kid on a tight budget, it wasn’t uncommon that you didn’t actually have any storage media to save this code to, so if you wanted to play a game, you had to type it in anew every time.
Even if you stored it on cassette tape, loading times on for example the C64 were typically between 15 and 30 minutes, if it loaded correctly.
Early home computing was wild.
https://yurichev.com/mirrors/machine-code-for-beginners.pdf and then https://github.com/jherskow/nand2tetris/blob/master/nand2tetris BOOK.pdf you will somewhat understand computers after this.
Sending data over audio was how dial up Internet worked. My guess here is that the audio playing hardware loses the ability to come to a stopping point at the end of the audio file after a crash and starts playing the data in the memory after the audio file ends as if it were audio.
It might also be a debugging behavior built into the device
That’s my guess as well.
The guy who uploaded the video that corporate content farm is “reporting” on actually covers exactly why this happens. In short, the gba plays sound from a certain part of ram, which a cpu interrupt continously refreshes. In the event of a crash, it keeps playing sound, but doesn’t get the interrupt to keep it playing the proper data from ram. If you let it cycle through all of ram, it eventually leaks out and just starts playing, well, everything else, eventually getting to the game rom. Relevant Videos
Here is an alternative Piped link(s):
Relevant
Videos
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Interesting. I’m check those out, thanks!
Why would you debug over audio when you can use a cable?
A signal is a signal. For system hardware developers it might have been a quick and dirty way to debug the hardware. It could also be an abandoned feature for low level developers and cartridge development teams. We may never know the real answer but it’s not an unreasonable thing to use the thing designed to output waves as a quick hookup point for logic analyzers / oscilloscopes.
I really don’t know.
If I had to guess possible reasons off the top of my head:
1: the aux cable and port are a very common for factor for electronics of all sorts, especially computers. So you could probably transfer that data to non-Gameboy devices and not have to manufacturer more proprietary GB ports which you may also have to write drivers for on your non-GB hardware. And your customers would also go through the hustle, if you require them to use your proprietary debugging hardware and drivers, when they inevitably test and debug their own games for your console.
2: in the event of a crash, the kernel might better be able to handle the aux than the proprietary port. Pure speculation by me.
Regardless of any possible reasons or strangeness, it just seems much more probable to me that the behavior of dumping the rom over the audio port is a design choice rather than a coincidence.
Program code for a Gameboy game wouldn’t normally be sent through an audio port so this is pretty weird.
Could be that their audio playback is done by hardware reading from a low address buffer in parallel to the rest of the logic and just relies on that logic to update pointers otherwise it will run through the entire address space.
Or it could be their way of implementing a full address space dump on a crash without large amounts of storage available and that just includes the ROM because it’s a part of that address space. But in the video, they were able to get a 100% match for the ROM using an emulator, so this isn’t it unless they didn’t mention chopping off a RAM section.