9 ms·

A 48Khz digital music player for the Commodore 64

203 points by SwellJoe 9y ago

ainiriand 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      Yeah, you're right. Found a very good description here: https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_Details_by_Pex_Mahoney_Tufvesson_v2.pdf https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_D... Interesting story about accidental discoveries and using oscilloscope to get compensation tables for different types of SID chips.
Sharlin 9y ago
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 9y ago
  makes you wonder what our current machines could be doing in 20-30 years, that was not intended. Maybe some quantum emulation.
  - jacobush 9y ago
    if anyone cared
  - simias 9y ago
    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.
harel 9y ago
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.
- pgeorgi 9y ago
  > some fringe PC zealots who got their XT to display a different shade of green http://8088mph.blogspot.de/2015/04/cga-in-1024-colors-new-mode-illustrated.html http://8088mph.blogspot.de/2015/04/cga-in-1024-colors-new-mo...
  - harel 9y ago
    Of course they did :)
- cromwellian 9y ago
  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.
mnx 9y ago
where do the visual effects (those blinking bars) come from? Are they deliberate, or some sort of side effect?
- vardump 9y ago
  They're deliberate, done by incrementing border color register. One of the only things possible with the available CPU time.
  - tonysavon 9y ago
    The three-byte codebook version (the mazinger demo) can't even afford the increment, and just does a sty $d020, which takes 2 cycles less, hence the colorbars look a bit different on that one. But the audio sounds better.
- csixty4 9y ago
  They're raster lines. At some point in the code, or multiple points, the program increments the register holding the border color so the video chip starts drawing a different color. This can happen in the middle of a line, which is why you get multiple "columns". Edit: vardump is right, the screen would be "turned off" in this case so just the border color is used. This gives a slight performance boost.
- pgeorgi 9y ago
  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).
  - 9y ago
cromwellian 9y ago
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.
- neotek 9y ago
  Way better source video: https://www.youtube.com/watch?v=yW5v93P-gBw https://www.youtube.com/watch?v=yW5v93P-gBw
  - cromwellian 9y ago
    I deliberately put the low quality one because it has the crowd reaction included at the demo contest, and I really enjoyed the crowd losing their shit when the full screen video + audio came on. :) I just noticed he compressed an entire bananarama music video with better quality sound into a 1Mb REU. https://www.youtube.com/watch?v=xH3yrLG8K7g https://www.youtube.com/watch?v=xH3yrLG8K7g
    - iammyIP 9y ago
      The remarkatble thing is less the compression of a 3:12 video with sound in 1MB, and more the c64 being able to decode it in realtime with a framerate > 10. I especially like the unique but still 64-flavoured compression artefacts of the video. Heres another Onslaught demo that fits on a Floppy disk: https://www.youtube.com/watch?v=OsDy-4L6-tQ https://www.youtube.com/watch?v=OsDy-4L6-tQ
      - cromwellian 9y ago
        He uses powerful PCs to do his VQ compression, everything in 1982 was possible but this :) . I think the general technique is probably something like this: 1) cluster all possible 8x8 pixel video blocks by some metric, and pick the 256 most frequent ones. 2) include these into a new charset, or several character sets up to how much memory you want to use, with the most frequent 8x8 pattern occuring. 3) Now encode each frame by 'quantizing' an 8x8 block into its character code. You want to minimize overall perceptual error, so choosing the optimal charset tile patterns and optimal tiling can be done with many optimization techniques (monto carlo, genetic algorithms, etc) But basically, you're 'dithering' the frame down to characters in a font, and the font character patterns must be chosen optimally to fit the whole video. There's some leeway in this because you can change the font every scanline or 8 scanlines, so it is possible to go beyond a max of 256 unique tiles per frame, you could also switch fonts between different parts of the video. A given full screen would be 40x25 characters, so you'd need to decode/write about 1000 characters per frame. At 10fps, you need to decode about 10k per second. The c64 executes about 20k cycles per frame, and the time to load/store from memory is going to be at least 9 cycles, 13 if you use indirect addressing. That gives you enough time to barely write 1500 bytes per frame, so this is right at the limit of what the C64 can do. You decompression has to be essentially a table lookup, and minimally a loop if I've estimated the bounds correct. (I'm going by 20 year old memory :) )
jdalgetty 9y ago
Imagine hearing that in 1982
squarefoot 9y ago
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.
tonysavon 9y ago
Playlist with the three demos: https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_aizjIG7qur6Gu https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_a...
js2 9y ago
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/
- Someone 9y ago
  You’ll be surprised how far one can push that. https://www.kansasfest.org/wp-content/uploads/Beyond-the-Beep.ppt https://www.kansasfest.org/wp-content/uploads/Beyond-the-Bee... mentions 22 kHz sounds, http://eightbitsoundandfury.ld8.org/software.html http://eightbitsoundandfury.ld8.org/software.html even mentions 44 kHz. It references SAM, a software speech synthesizer that could run on that one-bit click speaker (“with the addition of much distortion”, as Wikipedia says)
- dfox 9y ago
  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.
dep_b 9y ago
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?
coin 9y ago
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.
mrguyorama 9y ago
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 9y ago
  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 9y ago
    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
ekimekim 9y ago
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-boy-color-audio-only https://ekimekim.itch.io/steamed-hams-but-it-plays-on-a-game... 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
8bitsrule 9y ago
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!

203 points by SwellJoe 9y ago

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 9y ago
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 9y ago
  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 9y ago
    Yeah, you're right. Found a very good description here: https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_Details_by_Pex_Mahoney_Tufvesson_v2.pdf https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_D... Interesting story about accidental discoveries and using oscilloscope to get compensation tables for different types of SID chips.

Sharlin 9y ago

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 9y ago
makes you wonder what our current machines could be doing in 20-30 years, that was not intended. Maybe some quantum emulation.
- jacobush 9y ago
  if anyone cared
- simias 9y ago
  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.

harel 9y ago

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.

pgeorgi 9y ago
> some fringe PC zealots who got their XT to display a different shade of green http://8088mph.blogspot.de/2015/04/cga-in-1024-colors-new-mode-illustrated.html http://8088mph.blogspot.de/2015/04/cga-in-1024-colors-new-mo...
- harel 9y ago
  Of course they did :)
cromwellian 9y ago
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.

mnx 9y ago

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

vardump 9y ago
They're deliberate, done by incrementing border color register. One of the only things possible with the available CPU time.
- tonysavon 9y ago
  The three-byte codebook version (the mazinger demo) can't even afford the increment, and just does a sty $d020, which takes 2 cycles less, hence the colorbars look a bit different on that one. But the audio sounds better.
csixty4 9y ago
They're raster lines. At some point in the code, or multiple points, the program increments the register holding the border color so the video chip starts drawing a different color. This can happen in the middle of a line, which is why you get multiple "columns". Edit: vardump is right, the screen would be "turned off" in this case so just the border color is used. This gives a slight performance boost.
pgeorgi 9y ago
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).
- 9y ago

cromwellian 9y ago

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.

neotek 9y ago
Way better source video: https://www.youtube.com/watch?v=yW5v93P-gBw https://www.youtube.com/watch?v=yW5v93P-gBw
- cromwellian 9y ago
  I deliberately put the low quality one because it has the crowd reaction included at the demo contest, and I really enjoyed the crowd losing their shit when the full screen video + audio came on. :) I just noticed he compressed an entire bananarama music video with better quality sound into a 1Mb REU. https://www.youtube.com/watch?v=xH3yrLG8K7g https://www.youtube.com/watch?v=xH3yrLG8K7g
  - iammyIP 9y ago
    The remarkatble thing is less the compression of a 3:12 video with sound in 1MB, and more the c64 being able to decode it in realtime with a framerate > 10. I especially like the unique but still 64-flavoured compression artefacts of the video. Heres another Onslaught demo that fits on a Floppy disk: https://www.youtube.com/watch?v=OsDy-4L6-tQ https://www.youtube.com/watch?v=OsDy-4L6-tQ
    - cromwellian 9y ago
      He uses powerful PCs to do his VQ compression, everything in 1982 was possible but this :) . I think the general technique is probably something like this: 1) cluster all possible 8x8 pixel video blocks by some metric, and pick the 256 most frequent ones. 2) include these into a new charset, or several character sets up to how much memory you want to use, with the most frequent 8x8 pattern occuring. 3) Now encode each frame by 'quantizing' an 8x8 block into its character code. You want to minimize overall perceptual error, so choosing the optimal charset tile patterns and optimal tiling can be done with many optimization techniques (monto carlo, genetic algorithms, etc) But basically, you're 'dithering' the frame down to characters in a font, and the font character patterns must be chosen optimally to fit the whole video. There's some leeway in this because you can change the font every scanline or 8 scanlines, so it is possible to go beyond a max of 256 unique tiles per frame, you could also switch fonts between different parts of the video. A given full screen would be 40x25 characters, so you'd need to decode/write about 1000 characters per frame. At 10fps, you need to decode about 10k per second. The c64 executes about 20k cycles per frame, and the time to load/store from memory is going to be at least 9 cycles, 13 if you use indirect addressing. That gives you enough time to barely write 1500 bytes per frame, so this is right at the limit of what the C64 can do. You decompression has to be essentially a table lookup, and minimally a loop if I've estimated the bounds correct. (I'm going by 20 year old memory :) )

jdalgetty 9y ago

Imagine hearing that in 1982

squarefoot 9y ago

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.

tonysavon 9y ago

Playlist with the three demos: https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_aizjIG7qur6Gu https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_a...

js2 9y ago

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/

Someone 9y ago
You’ll be surprised how far one can push that. https://www.kansasfest.org/wp-content/uploads/Beyond-the-Beep.ppt https://www.kansasfest.org/wp-content/uploads/Beyond-the-Bee... mentions 22 kHz sounds, http://eightbitsoundandfury.ld8.org/software.html http://eightbitsoundandfury.ld8.org/software.html even mentions 44 kHz. It references SAM, a software speech synthesizer that could run on that one-bit click speaker (“with the addition of much distortion”, as Wikipedia says)
dfox 9y ago
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.

dep_b 9y ago

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?

coin 9y ago

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.

mrguyorama 9y ago

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 9y ago
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 9y ago
  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

ekimekim 9y ago

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-boy-color-audio-only https://ekimekim.itch.io/steamed-hams-but-it-plays-on-a-game... 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

8bitsrule 9y ago

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!