SoylentNews is people
SoylentNews
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: 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.