36 ms·

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 v

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 :) )
      - iammyIP 9y ago
        yes, that sounds plausible.
    - piger 9y ago
      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
  - jloughry 9y ago
    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=xxjiQoTp864 http://www.youtube.com/watch?feature=player_embedded&v=xxjiQ... Audience: "No way!" and "That's impossible!" and "How did it do that?"
tonysavon 9y ago
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 :-)
- deleted 9y ago
  [deleted]
- dzdt 9y ago
  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 9y ago
    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 9y ago
      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.
bsdhacker 9y ago
This is even better: https://youtu.be/bIM4p0uL6Pw?t=453 https://youtu.be/bIM4p0uL6Pw?t=453

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 :) )
    - iammyIP 9y ago
      yes, that sounds plausible.
  - piger 9y ago
    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
- jloughry 9y ago
  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=xxjiQoTp864 http://www.youtube.com/watch?feature=player_embedded&v=xxjiQ... Audience: "No way!" and "That's impossible!" and "How did it do that?"

tonysavon 9y ago

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

deleted 9y ago
[deleted]
dzdt 9y ago
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 9y ago
  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 9y ago
    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.

bsdhacker 9y ago

This is even better: https://youtu.be/bIM4p0uL6Pw?t=453 https://youtu.be/bIM4p0uL6Pw?t=453