
A 48Khz digital music player for the Commodore 64 - SwellJoe
https://brokenbytes.blogspot.com/2018/03/a-48khz-digital-music-player-for.html
======
cromwellian
If you think that’s impressive, look at the demos thealgorithm pulls off On a
stock c64 with no expansion. Advance to the 11minute mark: full screen
streaming video and audio from a floppy

[https://youtu.be/FTtKHLZTbtA](https://youtu.be/FTtKHLZTbtA)

He also has a 22khz demo that plays back a full song on stock HW.

Seeing full screen video and audio on an 8-bit machine in 1982 would have
seemed like alien technology, it would have blown people away. Years later
people would be impressive by simple black and white QuickTime movies on far
more expensive and faster HW.

~~~
tonysavon
This is on stock C64 too :-). I guess the achievement here is using
compression at such a high frequency. Once you get down to lower frequency,
you can implement fancier compression schemes and add more stuff on display.
The same author has compressed video plus compressed digi streaming from
floppy disk here:
[https://www.youtube.com/watch?v=qIRww2a59lE](https://www.youtube.com/watch?v=qIRww2a59lE)
But of course, that's not 48Khz and it sounds like that :-)

~~~
dzdt
Not really. Stock C64 plus 1mb cartridge.

The big innovation was Pex's discovery of a way to output 8 bit samples by a
single register write on the SID chip. The chip was never designed for
outputing digital samples, and the approach leverages basically a bug in the
chip design to achieve this.

The only innovative bit in this new demo (besides presuming to use a cartridge
for storage) is the vector quantized compression technique.

~~~
tonysavon
This is running on an Ocean type cartridge as a storage, which is considered
stock Hardware in the demo community, as stated in the article. If no
additional device can be "accepted", then all of the demos mentioned in this
thread should be disqualified too, because they use a disk drive.:-) In
general, the technology showcased in this demo of course would work also
playing the song from RAM, it would just be a bit too short :-)

~~~
cromwellian
I don't disagree that commercially available REUs were fair game, but a
vanishingly small number of C64 owners had them, while a very large number of
C64 owners had either datasettes or 1541s.

This doesn't take away from the demo, but if say, EA, Epyx, or Activision were
going to ship a game that played music like this, they would have had to fix
it in 64k. So it's even more impressive when I see stuff that a typical home
computer could have seen in 1983.

I remember the first few times I heard digi-mods on the C64, like Rob
Hubbard's Skate or Die game intro
([https://www.youtube.com/watch?v=vqRXxPl6bXA](https://www.youtube.com/watch?v=vqRXxPl6bXA))
and it absolutely blew me away. Full screen video + audio like that Onslaught
Demo would have given me a heart attack.

~~~
tonysavon
We are not talking about REUs here, as clearly stated in the article. We are
talking about Ocean Type Cartridges, which were available in the 80s. And yes,
they where ROM, not RAM, and yes, they came in those sizes. 16Mb ram
expansions did not exist, 1Mb ROMs did exist

------
harel
If Commodore (the company) had a fraction of the dedication and ingenuity of
today's Commodore users we'd all be using their machines still, and reading
about Apple enthusiasts who managed to squeeze another ounce of juice off
their old Macintosh, or some fringe PC zealots who got their XT to display a
different shade of green.

~~~
cromwellian
The thing about the VIC II and SID is that they have just enough flexibility
by exploiting the HW to pull off an astonishing number of effects, like
stretching sprites/screen/characters by tricking the VIC to redisplay lines,
this allows cool HW scaling effects. Or getting the VIC to delay displaying
lines, which allows shifting the screen by more than 8 pixels in vertical and
horizontal directions (the scroll registers normally only allow 8 different
pixel positions)

People have exploited interlacing/sub pixel/NTSC/PAL effects to generate new
colors, or simulate hi-res. They've combined changing color palettes per-line
with sprite overlays to breach the barrier of 4 unique colors per 4x8 pixel
block.

The list of surprising effects I've seen on the C64 never seems to end. Some
crazy people have also managed to get the C128's VDC to do demo-scene effects
as well.

One trick I was working on in the 80s before I quit the C64/C128 to go to the
Amiga was to try and use the C128's MMU chip to run high speed 8502 code. The
C128 MMU could remap the 0 page addresses ($00-$FF) into other memory regions.
Because 0-page instructions run faster (e.g. STA $C000 vs STA $C0), if you
could remap zero page, you could write code in a style that is significantly
faster.

I wanted to use this to write a fast line drawing/poly-filing routine. Since
the VIC could also be remapped by the MMU, in theory (I never go to to test
it), you could map the zero page to a VIC mapped address, and do pixel block
operations at 2-3 cycles per write.

~~~
harel
Hat off to you sir. I learned programming on the Vic20 (my first computer) and
I still cannot surpass the level of excitement it got me then. I didn't dream
to squeeze the hardware back then, I just accepted it and used a tiny amount
of it. What I see done now is nothing short of amazing. If these talents of
optimisations would apply to modern hardware, we wouldn't need modern
hardware.

------
Sharlin
Wow. Remember that this on a machine that isn't actually designed to play
digitized sound at all! (Though ways to hack the chip to do just that have
certainly existed for a while, as mentioned in the article.)

~~~
Medox
makes you wonder what our current machines could be doing in 20-30 years, that
was not intended. Maybe some quantum emulation.

~~~
simias
The massive complexity, diversity and general black-box nature of modern PCs
leads me to believe that we won't have a similar scene of enthusiasts to
develop amazing hacks for, say, 2009 Dell Inspiron laptops.

There's an elegant simplicity in these old pieces of hardware, it's relatively
easy to study them exhaustively and if you're clever enough you might find a
new way to fit the pieces of the puzzle to do something nobody had though
possible before. If you want to hack a modern PC you'll probably first have to
spend a few years reverse-engineering the various parts to figure out how they
work exactly and what you can do with them. Even getting a basic understanding
of the low level details of a modern GPU is quite a massive undertaking.

------
js2
You could never do this on an Apple II. The Apple II hardware was limited to a
one-bit click of the speaker (in part due to a dispute between Apple Computer
and Apple Records?).

But there was a modem for the Apple II, the Novation Apple-Cat II that
contained a tone synthesizer and could be used to play music out over the
line. To this day, I think that modem is one of the neatest peripherals ever
made:

[http://www.jammed.com/~jwa/Machines/cat/](http://www.jammed.com/~jwa/Machines/cat/)

~~~
dfox
For what it's worth in early 90's people were playing PCM audio on PC speaker,
which is single bit DAC that is in turn controlled by programmable interval
counter and thus effectively cannot even directly produce single bit PCM.
Norton Commander (5 or so) even included PC-speaker WAV player.

Edit: also having only one bit can be offset by larger sampling rate. In fact
this is how probably every non-audiophile audio DAC manufactured in last 25
years works.

------
coin
I wish people would learn how to abbreviate the units correctly. Hertz is
abbreviated as "Hz". The kilo prefix is "k". Thus kilohertz is "kHz" and not
Khz.

------
ainiriand
Impressive piece of software building on the already impressive technique to
play 8-bit that Mahoney invented.

A good moment to remember
[https://github.com/marioballano/emudore](https://github.com/marioballano/emudore)
so I can experiment with this thing on the weekend.

~~~
vardump
Correct me if I'm wrong, but this doesn't seem to use Mahoney technique, it's
just doing the plain old technique of writing SID volume register at 0xd418:

    
    
      l:      nop                 
      sample: ldx $8400 + i*$100  
              ldy $8000,x  
              lda sidtable,y   
              sta $d418      
              inc sample +1        
              bit $ea               
              ldy $8100,x          
              lda sidtable,y   
              sta $d418            
              inc $d020

...

~~~
popmilo2
It is based on Mahoney technique. Achievement is in added decompression
routine that works in those 21 cycles per sample. Lot's of cool info in that
article. Nicely done !

~~~
vardump
Yeah, you're right.

Found a very good description here:
[https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_D...](https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_Details_by_Pex_Mahoney_Tufvesson_v2.pdf)

Interesting story about accidental discoveries and using oscilloscope to get
compensation tables for different types of SID chips.

------
ekimekim
Very cool! I did something similar for the Game Boy Color recently - playing
18kHz ~7bit audio while also updating the screen at 60fps, using "hi-color"
techniques where you change the color palette before each line is drawn. It
was a ton of fun with a lot of problems like "aha, if I use this register for
this value, it saves 2 extra cycles!".

My code's here:
[https://github.com/ekimekim/gb_music_video](https://github.com/ekimekim/gb_music_video),
and you can get a finished demo rom (which doesn't actually use any of the
graphics stuff due to lack of assets) here: [https://ekimekim.itch.io/steamed-
hams-but-it-plays-on-a-game...](https://ekimekim.itch.io/steamed-hams-but-it-
plays-on-a-game-boy-color-audio-only)

I should note that the technique I used for audio on the Gameboy was taken
from this excellent video:
[http://tasvideos.org/5384S.html](http://tasvideos.org/5384S.html)

------
squarefoot
Sound could be produced by PWMing an i/o port to an integrator, so no need for
the SID, and PWM could be generated through a register loaded with the desired
value then decremented setting that pin to a 1/0 ratio according to its value,
that is, turning the value into a duty cycle which once fed into the
integrator becomes a voltage. It's simple in theory, but being the parallel
byte serialized into essentially a single bit that would require some speed
the 6502 could hardly be capable of.

------
jdalgetty
Imagine hearing that in 1982

------
dep_b
I wasn't expecting to be blown away by what they could do with the SID chip
last time let alone now. Could you use the C64 as a hi-fi sampler with an
analog filter or it's not possible anymore to use the LPF?

------
tonysavon
Playlist with the three demos:

[https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_a...](https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_aizjIG7qur6Gu)

------
mrguyorama
Everyone seems entranced by "wow this would have been cool in the 80s", but
the compression is a necessary part of the puzzle. How fast could you do k
means clustering on 80s hardware?

~~~
tonysavon
That's a very good point! And also one to keep in mind for a possible
additional demo. Use only hardware from the 80s also for the encoding!

~~~
mrguyorama
I think the demo is still really cool. I mean more to push back against the
"programmers are lazy look what you can do with limited resources" ignoring
the fact that the limited resources were only used for the playback part.
Still awesome, just not possible in the 80s

------
8bitsrule
While I'd rather listen to Costello with 16 bits at 24 kHz ... this is a very
cool hack - thanks for sharing. Makes me (once again) sorry I gave away my 64!

------
mnx
where do the visual effects (those blinking bars) come from? Are they
deliberate, or some sort of side effect?

~~~
pgeorgi
You get a bit more speed out of the C64 if you disable parts of the video
chip. It also avoids cycle inconsistencies every 8 scanlines (where normally,
the chip would block the bus for an additional cycle).

To avoid making it a dull monochrome screen, devs tend to push the data that
they process into the border color register (acting as background color in
this mode). You also see this with decompressors at the beginning of (cracked)
games. So the background color gets updated every few multiple of 8 pixels (1
character), and there's where the patterns come from. The slow shift of the
pattern to the left indicates that the code isn't entirely balanced, but the
article states as much (is it moving every 1.28 secs? I can't tell).

~~~
sp332
Yes, it does jump every 1.28 seconds :)

