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: 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.