A 48Khz digital music player for the Commodore 64 | Hacker News Reader

A 48Khz digital music player for the Commodore 64

brokenbytes.blogspot.com

203 pointsSwellJoe57 comments

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

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.

Way better source video:

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

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

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

yes, that sounds plausible.

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

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?"

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

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.

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.

> I don't disagree that commercially available REUs were fair game

This doesn't use REU. This uses a simple banked (EEP)ROM cartridge.

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

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.

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.

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

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.

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

Of course they did :)

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.

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.

I wonder if anyone else has tried that. Ever tried poking that idea in the general direction of some demosceners?

The PC was in some sense doomed to win. It is the natural successor of the S-100 bus. Commodore people have a hardon for "custom chips", exotic proprietary hardware soldered onto the mainboard in a special snowflake of holistic system design but what the PC provided was an open backplane allowing compatible systems to be built and integrated using parts from a variety of vendors. This gave the PC agility that even the best-managed company in the world couldn't match. It wasn't IBM's superior management that put the PC over the top, it was the combined forces of Dell, HP, Gateway, Tandy, and all the little peripheral vendors, to say nothing of Taiwanese white-box builders.

And in addition to the 8088MPH demo mentioned downthread, MDA graphical demos should in principle be possible by rapidly changing character RAM as the beam passes by. This is a trick I saw to generate graphics on another text-only monochrome machine, from Commodore: the PET.

OK, lets assume Commodore's chips would have become the intel equivalent, and an open standard. They could have easily been the PC if they went the same way. It's not far fetched, just mismanaged. They could have done it and gone there but they didn't have the vision. And don't get me wrong, I'm not complaining or have regrets. I enjoy my Linux laptop and I couldn't care less if it's an intel chip or commodore that drives it. But I do know that one of them triggered excitement and one is just "a chip". Maybe it's my age, maybe its nostalgic memories of an era. I don't know... (can you run linux on commodore??? now that would be something...)

> OK, lets assume Commodore's chips would have become the intel equivalent, and an open standard. They could have easily been the PC if they went the same way.

Yes and today we might be talking about boring 65xx vs. exotic, sexy 8086.

> They could have easily been the PC if they went the same way. It's not far fetched, just mismanaged. They could have done it and gone there but they didn't have the vision.

IBM didn't have the vision either. They left that to Dell, Compaq, etc. The PC evolved quite by accident, and once IBM realized what they had unleashed -- a computer revolution in business and eventually the home that was OUT of their control -- they struggled to try to put the genie back in the bottle with the PS/2 line.

> But I do know that one of them triggered excitement and one is just "a chip".

Says you, who never harnessed the on-chip timers of the 80186 to drive PWM sound through the beeper!

> (can you run linux on commodore??? now that would be something...)

You can run LUnix, a cut down Unix workalike. And Tandy Color Computers, based on a 6502 relative the 6809, could run a Unix workalike called OS-9...

IBM did have the vision - or at least one small division in IBM did. They set out to make a (relatively) affordable (relatively) high performance business computer. And they succeeded.

Compaq, Dell, Gateway, and the rest took the idea and ran with it. But it wouldn't have happened without IBM.

Of course the PC was a technological cripple compared to Commodore hardware - somewhat compared to the C64, and very much so compared to the Amiga.

Unfortunately that's not the point. Businesses wanted packaged systems with software, not games with sound and sprites. That's what IBM set out to provide, and that's what they provided. (In spite of themselves - but even so.)

The competition wasn't from Commodore - the PET was considered a risky toy - but from S100 systems at one end, and massively more expensive DEC/DG/IBM minicomputers at the other. The high prices of the latter and limited performance of the former made the PC look like a bargain to corporates, even though its price looked ridiculous to consumers.

But the PC was open quite by accident, and that enabled cloners to rise up, and that allowed the PC platform to get inside the OODA loop of Commodore, Atari, and Apple. As great as those machines were in the early days, betting the whole company on coming up with a perfect cinnamon roll of a whole-system design can't keep up when the market has many companies making video hardware, companies making sound hardware, companies making mobos, companies making memory, and companies plugging them all together and they Just Work. Compatible systems with superior specs to the 5150, and lower prices, emerged in almost negligible time after the 5150's release, and it was only a matter of time before even the gap with the mighty Amiga would be closed. This is why the engineers at SGI ended up making video cards for PCs. If Commodore had had the best management team in the world, eventually they would have ended up primarily producing PC compatibles and/or PC preripherals, because by the early 90s the open ISA (and later PCI) architecture and the reasonable-for-the-time license terms of DOS became VERY convenient Schelling points for the entire industry.

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.

if anyone cared

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.

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/

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)

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.

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.

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

...

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 !

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.

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

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

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.

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

Yes, it does jump every 1.28 seconds :)

Reply on news.ycombinator.com