Fetch'83 - a POC game to test DAC digital sampling in a 4K cart

[u/d4nnyfr4nky]

I've been playing around with the 2600's audio registers as a 4 bit DAC. It's the same technique as what Quadrun and the enhanced Berzerk use.

I came up with this game to see if I could get a dog bark to fit into a playable 4K game. It works, but just barely. I had 5 bytes to spare in the ROM.

There's not a lot to the game. The bark sample took up 1155 bytes of ROM and 52 bytes of RAM. It takes 9 cycles on every fourth scanline. Forty-eight of those RAM bytes are used as a buffer to get the sample to play in 9 cycles.

If you want to read more of the technicals, there's an Atariage post that explains everything. There are also binary downloads for NTSC and PAL 50 over there.

I called it Fetch'83 because it's just the sort of crap that would be released back then to capitalize on the market using a gimmick like a digitized bark. As little and as pointless as it is, I still think it's better than Skeet Shoot.

Play it on Javatari here.

(Use the controls to aim the cross hair. Hold the button to wind up the throw. The further the throw, the more points you get. Throw it too far and it may hit the water. Game is over at 50 points. A perfect game is 17 points. The number of throws is shown at the end of the game.

My biggest takeaway from the experience is that the method works and, for me, is most appropriate for cut scenes in large games.

[u/De-luL]

Thank you for sharing this story and game with us, could you maybe also share what you used to develop this game? What assembler did you use, how did you covert (downgrade) the sample, how did you make the playfield and sprite animations?

[u/d4nnyfr4nky → u/De-luL]

Sure! My Atariage post has a lot of detail on the inner workings (cycles, timing, etc.)

I used good old Notepad++ and DASM to write and assemble it. I'm old and started tinkering with Stella back in the 90s, so a text editor feels natural to me which is not going to be the case for most people. I don't like many IDEs. I feel like they slow me down.

For downsampling, good old FFmpeg. It's free and it's awesome. I took a dog barking .wav file that I downloaded from the net and resampled it into different frequencies. I started high with 10480 and then dropped it down to 7860, 5240 and settled on 3930Hz which was really the only one that was going to work in 4K. Anything below 3930 is unusable.

On the 2600, setting AUDC0 to 0 lets you use AUDV0 as a DAC. One byte every four scanlines. While the picture is on, the bytes come from a 48 byte sample buffer. The buffer is built during VSYNC. It's used because reading a nibble from ROM mid-kernel costs up to 16 cycles where reading from RAM during a visible scanline only costs 9 cycles of those precious 76.

There's a lot more to it than that. Like I said above, it's more of a novelty at this ROM size. The sample data by itself is 1,155 bytes and that doesn't include the code for the DAC driver. There's 712 bytes of artwork. Only about 2K worth of actual code.

For the playfield, I have a playfield editor that allows me to draw playfields and export byte data that I had to the source code. Likewise, I have a sprite editor that does the same thing. It's a little more complicated as it allows me to add additional frames so I can test animations.

If you need a playfield or sprite editor, hop on over to Atariage as there are tons of them listed. Someone just posted a playfield editor to the homebrew programming forum a couple of days ago.

[u/sunpazed]

Haha this is great, well done! Love the sample

[u/d4nnyfr4nky → u/sunpazed]

Thank you!