Demoscene > TIC-ROLL


PCM sample playback at 1.96kHz. I'm really sorry.
made by Gasman / Hooy-Program
uploaded by gasman
added:
download cartridge
- CLICK TO PLAY -

16


The TIC-80 really isn't designed to play samples. Each audio channel can play a repeating 4-bit waveform of up to 32 elements. But you can change that waveform every frame, so if you stretch it out enough, you can get it to play 4-bit PCM samples at 1.96kHz. And at that sample rate, a 64Kb cartridge has just enough space to fit one verse and chorus of a certain 1980s pop hit.

What a time to be alive!

Comments


mido_gamer

cool rickroll

masternama

Hi, i'm curious how I put sprites with .WAV convert to .GIF or idk? in Sprite Editor.

szecska

I spent some time trying to figure out how could we achieve the pcm playing, and you've done this for me!
Awesome!

hanamileh

its funny to see that someone has implemented what i wanted to do for a long time but i lacked the skills
btw, the space in the code itself is almost unlimited, maybe you can use it to fit the whole song into the cartridge?

thecyanman

Out of curiousity, would there be any way to up the sample rate? Say, to about 4 KHz?

gasman

@masternama I didn't use the TIC-80's editor environment at all for this - I constructed the .tic file with a custom Python script, based on the information at https://github.com/nesbox/TIC-80/wiki/TIC-File-Format . Source code here: https://gist.github.com/gasman/3d966f23aa317eacccb8da5e23713333

gasman

@hanamileh The maximum code size is 65536 bytes, which is still quite limiting for this purpose, especially as you can't just store binary data there directly like you can in VRAM - you'd need to come up with a scheme for unpacking the data from a string or something. You might be able to get another verse or so that way, but it didn't seem worth the effort for a proof-of-concept.

gasman

@thecyanman I don't think so. You can only set the waveform for a sound channel once per frame, and that gives you 32 sample values that you have to space out across the duration of that frame (= 1/60 of a second). If you run through those values any faster, you'll run out too early and end up repeating them. It *might* be possible to improve on it by using multiple channels running at different rates, and having them combine to make the final waveform, but that gets really complicated and I haven't figured out the details yet.


Post comment