A 48Khz digital music player for the Commodore 64(brokenbytes.blogspot.com)
brokenbytes.blogspot.com
A 48Khz digital music player for the Commodore 64
https://brokenbytes.blogspot.com/2018/03/a-48khz-digital-music-player-for.html
53 comments
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
But of course, that's not 48Khz and it sounds like that :-)
Even more impressive are IMO the current songs people compose on the SID. This guy is an artist in the true sense:
https://www.youtube.com/watch?v=ELpnGDHo0Bg https://www.youtube.com/watch?v=eI5d6Y0Fzl4
Yes that is 100% original C64, no extensions, no cartridges. The first time I heard these, I was absolutely blown away.
https://www.youtube.com/watch?v=ELpnGDHo0Bg https://www.youtube.com/watch?v=eI5d6Y0Fzl4
Yes that is 100% original C64, no extensions, no cartridges. The first time I heard these, I was absolutely blown away.
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.
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.
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 :-)
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) and it absolutely blew me away. Full screen video + audio like that Onslaught Demo would have given me a heart attack.
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) and it absolutely blew me away. Full screen video + audio like that Onslaught Demo would have given me a heart attack.
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
> I don't disagree that commercially available REUs were fair game
This doesn't use REU. This uses a simple banked (EEP)ROM cartridge.
This doesn't use REU. This uses a simple banked (EEP)ROM cartridge.
I think anything is fair game that was reasonably doable back in 1983.
Cartridges have been used from the beginning, at first they were just 16 kB. Games have been released in cartridge format from 8 to 512 kB.
It's really impressive to be able to include any type of decompression when total budget per sample is just 21 clock cycles on a system where one instruction takes 2 to 8 clocks.
So I think you're underrating the achievement here.
Cartridges have been used from the beginning, at first they were just 16 kB. Games have been released in cartridge format from 8 to 512 kB.
It's really impressive to be able to include any type of decompression when total budget per sample is just 21 clock cycles on a system where one instruction takes 2 to 8 clocks.
So I think you're underrating the achievement here.
I don’t think 1mb expansions were available until the late 80s though.
Expansion would have been unrealistic, you're right. But this doesn't need a RAM expansion at all.
See these 512 kbit 1983 vintage EPROM chips:
https://www.ebay.com/itm/INTEL-D27512-27512-IC-28Pin-DIP-EPR...
16 of these 512 kbit chips, some address decoding and banking logic. 1 MB cart.
Very much doable with off-the-shelf parts even way back then.
See these 512 kbit 1983 vintage EPROM chips:
https://www.ebay.com/itm/INTEL-D27512-27512-IC-28Pin-DIP-EPR...
16 of these 512 kbit chips, some address decoding and banking logic. 1 MB cart.
Very much doable with off-the-shelf parts even way back then.
[deleted]
This is even better:
https://youtu.be/bIM4p0uL6Pw?t=453
Way better source video:
https://www.youtube.com/watch?v=yW5v93P-gBw
https://www.youtube.com/watch?v=yW5v93P-gBw
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
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
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
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
Oh my thank you so much for this, I’m getting lost in the related videos showing the same song played on all kind of devices
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 :) )
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 :) )
yes, that sounds plausible.
The audience reaction was great. It reminds me of a similar audience reaction in this video of motion kernel de-blurring in Adobe Photoshop from 2011 (at about 1:17 in the video)
http://www.youtube.com/watch?feature=player_embedded&v=xxjiQ...
Audience: "No way!" and "That's impossible!" and "How did it do that?"
http://www.youtube.com/watch?feature=player_embedded&v=xxjiQ...
Audience: "No way!" and "That's impossible!" and "How did it do that?"
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.
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.
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.
I wonder if anyone else has tried that. Ever tried poking that idea in the general direction of some demosceners?
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.
> 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-mo...
http://8088mph.blogspot.de/2015/04/cga-in-1024-colors-new-mo...
Of course they did :)
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.)
makes you wonder what our current machines could be doing in 20-30 years, that was not intended. Maybe some quantum emulation.
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.
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.
if anyone cared
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/
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/
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.
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.
You’ll be surprised how far one can push that. https://www.kansasfest.org/wp-content/uploads/Beyond-the-Bee... mentions 22 kHz sounds, 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)
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)
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.
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 so I can experiment with this thing on the weekend.
A good moment to remember https://github.com/marioballano/emudore so I can experiment with this thing on the weekend.
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 $d020It 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 !
Yeah, you're right.
Found a very good description here: 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.
Found a very good description here: 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.
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, 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...
I should note that the technique I used for audio on the Gameboy was taken from this excellent video: http://tasvideos.org/5384S.html
My code's here: 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...
I should note that the technique I used for audio on the Gameboy was taken from this excellent video: http://tasvideos.org/5384S.html
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.
Imagine hearing that in 1982
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?
Playlist with the three demos:
https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_a...
https://www.youtube.com/playlist?list=PLFeDsJqcV6DhwH16fVp_a...
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?
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!
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
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!
where do the visual effects (those blinking bars) come from? Are they deliberate, or some sort of side effect?
They're deliberate, done by incrementing border color register. One of the only things possible with the available CPU time.
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.
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.
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.
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).
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).
Yes, it does jump every 1.28 seconds :)
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.