from the help!-the-bots-are-colluding-on-submissions dept.
As readers of these pages know, I've always been obsessed with audio and video compression for humble machines. My game Planet Golf for the Commodore 64 even includes Full Motion Video running from a floppy disk. The problem with this stuff, though, is that, as much as it's interesting to see these experiments run on such a limited piece of HW, and as much as it feels like an achievement to the programmer, that doesn't change their gimmicky nature. In other words, let's be honest, no person in their right frame of mind would waste a second of their time listening to those scratchy sounds, unless deafened by unconditional love for the machine. Spoiled as we are with high quality sound coming from all kinds of devices around us, poor Commodore 64 cannot be our to-go solution for our aural pleasure.
Or can it?
Mission
To build a C64 software player that can play a whole song at 48Khz (higher frequency than CDs' 44.1Khz) using a stock Commodore 64 and a regular ROM cartridge, which is your typical 80s setup.
Now, there are all kinds of devilish pieces of hardware available for your Commodore 64 nowadays, such as 16Mb RAM Expansion Units, or even mp3 hardware players. Of course, this stuff was not around in the 80s, and it therefore does not appeal to purists. In other words, any reliance on these monstrosities would get me disqualified. You might as well run a marathon riding a motorbike. The largest "legitimate" ROM Cartridges are those that Ocean used for their games. You can store a whopping one megabyte of data onto them. We are going to need all of it!
Original URL: https://brokenbytes.blogspot.com/2018/03/a-48khz-digital-music-player-for.html
-- submitted from IRC
(Score: 3, Interesting) by turgid on Friday March 30 2018, @05:45PM (4 children)
I had a Sinclair Spectrum 128 (Z-80A CPU). I wasn't wealthy enough to have a C64 or an Amiga or ST when they came out. The Spectrum 128 had an AY-3-81923-channel sound chip but it also had the old "beeper" for backwards compatibility with the original Spectrums. You could have four channels going at once like that.
There were some games, though, from the budget label Mastertronic that had a cool gimmick where they had "multu-channel" sound played back through the beeper. On the original Spectrums the beeper was a small internal loudspeaker about 30-40mm in diameter controlled via a single bit on one of the Z-80's output ports. By toggling the value of this bit at varying rates you got different musical notes.
I have no idea how they did it, but they had games with this amazing music that fit into the RAM of an old 48k Spectrum. The music sounded very fuzzy, but the tunes were cool and seemed to last a long time. I dare say they used some sort of compression algorithm on the data. I'd love to know how it worked. I had a couple of those games. I think they were called Chronos and Agent X II.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Informative) by Anonymous Coward on Friday March 30 2018, @06:13PM (1 child)
PWM as explained here [ntmusic.org.uk]
You could do interesting enough stuff using beep from basic, I used to spend hours fiddling with udg sprite maps and the beep command as a child.
(Score: 0) by Anonymous Coward on Friday March 30 2018, @11:50PM
Also RealSound https://en.wikipedia.org/wiki/RealSound [wikipedia.org]
(Score: 1) by istartedi on Friday March 30 2018, @09:31PM (1 child)
I don't know much about music theory, but a lot
of music could compress well because the basic tune
stays the same but you just change the key signature,
tempo, instruments, etc. Then of course lots of sheet
music has several verses that you just repeat. Subtle
variations in timbre, volume, tone, etc--that's the nuance that's
harder to compress. That's where the musician really
matters. In this case the "musician" is a very simple machine
and we were impressed that it could do what it did, even
without the nuance.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by turgid on Saturday March 31 2018, @12:00PM
Yes, from my days of music lessons, sheet music is effectively a program to render a piece of music. There are repeated patterns and phrases, and this does compress very well. If you have a machine play the music all notes are identical with minimal variation, and would compress very well at the audio level. However, that sort of music isn't much fun to listen to. It's devoid of expression and nuance. That's why humans still play musical instruments.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by SomeGuy on Friday March 30 2018, @06:25PM (6 children)
If Mozilla were to hire this guy, then perhaps the Youtube HTML5 shit wouldn't be so laggy on "older" machines.
(Score: 2) by kazzie on Friday March 30 2018, @06:36PM (3 children)
I didn't know you could do HTML5 on a Commodore!
(Score: 2) by jimtheowl on Friday March 30 2018, @07:46PM (2 children)
(Score: 2) by el_oscuro on Saturday March 31 2018, @04:05AM (1 child)
Coding 6502 assembly and addressing the VIC-II chip *now*... 1M is a shit ton of RAM, and are computers *really* doing much more now?
SoylentNews is Bacon! [nueskes.com]
(Score: 2) by kazzie on Saturday March 31 2018, @08:18AM
One area you could legitimately need so much RAM is for the display. If you limit your video to 800x600 pixels in 256-color mode, you'll still need to have ~470 kilobytes of video RAM.
(Score: 2) by shortscreen on Friday March 30 2018, @07:48PM (1 child)
Then youtube would work perfectly on a 1GHz P3, but the videos would play too fast on anything newer ;)
(Score: 2) by jasassin on Saturday March 31 2018, @10:02PM
MoSlow.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 4, Insightful) by bzipitidoo on Friday March 30 2018, @07:28PM (7 children)
Our systems are so incredibly bloated these days. The attitude seems to be that any unit smaller than 4k is not worth bothering about. I wanted to see how bad Hello World in C was, on a typical 64bit Linux system. Depends on the compiler options, but even the smallest one (created with a whole bunch of compiler options to reduce size) is a ridiculously large 4600 bytes. How can it possibly take 4k of binary to print "hello world"? Is the ELF overhead that huge?
And that's the dynamically linked version. With the -static option, which is maybe a more fair comparison with binaries on 1980s era home computers, the Hello World binary was 808k. The size reducing options cut that to 711k. Maybe uclibc would've helped. But it seems to really reduce size, you have to look into all kinds of things, like using assembler, ditching all portability, and there's this Tiny ELF format...
(Score: 0) by Anonymous Coward on Friday March 30 2018, @07:35PM (2 children)
Wouldn't the 64-bit binaries naturally be 4x bigger than the 16-bit binaries of the 80's, all else being equal?
(Score: 0) by Anonymous Coward on Friday March 30 2018, @07:43PM
16bit? You've gone back to the future and arrived in the wrong half of the decade for this story.
(Score: 2) by Kilo110 on Saturday March 31 2018, @02:31AM
from the little asm I know, it's my understanding that all the 64 bit registers can be accessed as a smaller register if you only need to use a small slice of it. so instead of RAX you can refer to it as AL and treat it as an 8 bit register. the actual asm code is smaller by doing this and any decent compiler will do these optimizations whenever possible.
(Score: 0) by Anonymous Coward on Friday March 30 2018, @08:07PM
I'll just leave this here:
(Score: 0) by Anonymous Coward on Friday March 30 2018, @10:32PM
whats it in 32bit, 16 and 8?
you realize now what game programmers had to deal with when porting forwards and backwards. it makes how far we've come seem like bloated backwards compatbility with no native mode.
(Score: 2) by VanessaE on Saturday March 31 2018, @08:52AM
I guess these days, any 8-bit programmer (on any platform) will probably just roll their own functions for the sake of speed, but if you point your neighborhood library's Timewarp-O-Scope to 1985, you may find that modern dynamic linking would be more comparable to coding in those days, assuming the libs you'd be linking to today have something comparable in the 8-bitter's OS, allowing for the difference in technology.
So in the case of "Hello world" and the C64, the KERNAL's CHROUT call would do most of the work of printing a character to the screen (and handling cursor movement, color, inverse video, and other stuff that one would normally put into a string, if memory serves). Half a dozen or so instructions to form a loop, along with that call, is enough to print a string (on the C128, you can discard the loop and use the PRIMM call instead).
As for ELF overhead, I'm not sure, but on the C64, the most you'll usually see for a program header is a two-byte load address (which is discarded at load time), followed by a single line of BASIC similar to "1985 SYS 2064".
(Score: 0) by Anonymous Coward on Saturday March 31 2018, @09:12AM
https://musl-libc.org [musl-libc.org]
They have a comparison page that can show you, but they have hello world in under 8k, I think smaller, and the entire libc with utf-8 support in under a meg for either dynamic or static implementations.
It is missing a lot of the compatibility support of gnu-libc, as well as non-linux platform support, but practically speaking very little of that stuff works in the stock glibc distro and hasn't in any sort of consistent manner in the 20+ years glibc 2 has been around. glibc1 as I remember was simpler but even more prone to cross-compile issues. It just was small enough that you actually had a chance of fixing them, unlike glibc 2.x.
There is still lots of gotchas with running some apps or classes of apps on musl, but it is overall the better library between the two of them, especially for native utf-8 systems that don't need legacy charset translation, but it provides a lot of benefits, including compiling it in under an hour on a *133mhz 486*, and far less hassles with cross compilation and symbol versioning breaking your apps in unpleasant ways. Combined with libc++ and clang, it offers a much more svelte C++ toolchain than the gnu toolchain has, and all licensed under the MIT or compatible licenses.