Neo-Geo Pocket Color IMA-ADPCM demo

[mic_]

I've been doing a few small things on the NGPC lately. Here's the latest one: playback of a 16 kHz stereo IMA-ADPCM-encoded song.

ROM + full source code (runs fine on a real NGPC, but not in any emulator that I know of)
youtube video recorded while running it on my NGPC. (Warning: there's a loud burst of noise right before the clip ends. I don't stop/loop the song when it ends, so when it goes past the end of the song it starts writing junk to the audio DACs).

A few technical details for those of you not familiar with this system:

The main CPU is a Toshiba TLCS-900/H, which is nice sort-of successor to the Z80 (32-bit registers, more orthogonal ISA, more addressing modes, etc). There's also an actual Z80 which is used to control the sound chip, but the Z80 isn't used at all in this demo.

The 900/H runs at a max frequency of 6.144 Mhz. Two clock cycles is called a state, and the fastest instructions execute in two states.
At 16 kHz stereo I need to generate 32000 samples every second, so I'm allowed to spend at most 3072000/32000 = 96 states per sample. Even with the optimizations I've made in the decoding routine I'm just barely below that limit (the last time I measured the performance I got something like 94 states/sample).

The decoder routine reads 4-bit encoded samples from ROM, decodes them into 16-bit signed PCM samples which are then rounded down to unsigned 8-bit samples and stored in a circular buffer in RAM. The actual audio output is handled by a microDMA channel (another feature of the 900/H package), which is set up to copy one byte each to the left and right audio DAC at 16 kHz.

[mic_]

And here's a 24 kHz mono variant: http://www.youtube.com/watch?v=fceFejM6qcg

There's some clipping in this recording, which may have to do with my rounding of sample values when converting from 16-bit PCM.

[tomaitheous]

Heh, I wasn't aware that the NG pocket had two processors, let alone a 16bit cpu.

Also, nice demo

[MottZilla]

That's pretty cool. I am not familiar with the NGPC. All I think I know about it is that it competed around the time of the WonderSwan and GBC.

[mic_]

I guess they went with a similar architecture of the original NeoGeo, which also had a Z80 controlling the sound chip. But whereas the Z80 in the NeoGeo had access to some ROM (IIRC), the one in the NeoGeo Pocket doesn't. It can access 4kB of RAM which is shared with the main CPU (and the main CPU has priority on the bus from what I can tell), plus some I/O registers including the PSG control registers (but not the DACs).

So you'd typically have your entire sound driver in the 4kB shared RAM and then use the main CPU to stream music data from ROM to the Z80 over the communication port, and let the Z80 process that data and update the PSG registers. You could potentially implement some kind of soft-synth on the Z80 that generates PCM samples that is passes back to the main CPU which would take care of writing the samples to the DACs. But it would have to be a pretty simplistic synth in order to be able to generate samples at a decent rate.

[ccovell]

My only problem with the NGPC (and WonderSwan (B&W) for that matter) is that they contained 16-bit processors or better, but you couldn't tell that from the games, really.

[mic_]

Unfortunately they went with a 2-bpp tile format and 16 palettes. It does have per-tile palettes and separate palette sets for each of the 2 BG layers and the sprite layer, but that doesn't get you around the fact that you only have 4 colors per tile (of which one is transparent).

[tomaitheous]

With 4k of ram, sounds like enough to do some limited Wavetable Synthesis (not MOD/XM, but REAL wavetable synth where you morph small sets of waveforms over time for timbre effect, or rather a table with premorphed waveforms. Something like 32 or bytes per waveform would be enough).

I'm curious as to what the sprite scanline limit is. I couldn't find it in any of the docs.

[mic_]

ngpcspec.txt says 64 sprites per scanline (maybe the official K1GE docs contains some info about this). I could probably test it pretty easily.

[tomaitheous]

64 8x8 cells per scanline? That's pretty damn good. The system specs looks really good; why the hell did they stick with the 2bpp format!?!? Especially considering the date this came out.
Also, you're handling saturation on the handheld side, right? What kind of speed increase could you get if you omitted that and handled clipping on the encoder side?

[mic_]

why the hell did they stick with the 2bpp format!?!?

To keep the VRAM amount down I suppose. Why that would've been such a concern in 1999 I don't know.

Also, you're handling saturation on the handheld side, right? What kind of speed increase could you get if you omitted that and handled clipping on the encoder side?

About 5 states per sample (so about 5%).
Another possible optimization would be to cut the PCM buffer size to 4kB and move it to the RAM area that is shared between the TLCS-900/H and the Z80 (since I'm not using the Z80 anyway), and take the 8kB LUT I'm using in the decoder and move it from ROM to RAM. That should save a few more states since the data bus for RAM is wider than the data bus for ROM.

[mic_]

I tried the optimizations I mentioned and ran a test on my NGPC. The average number of states per sample went down to 85 or 86, so we're talking about a theoretical output of about 18 kHz (for a stereo stream).

But since the timers run at 48000/N Hz (where N is an integer > 0) you wouldn't be able to output an 18 kHz stream anyway - unless you skipped the microDMA approach and integrated the DAC writes into the decoding routine. This would probably make decoding less efficient since you'd have to decode a left/right pair for each sample, and the channels in a stereo IMA-ADPCM file are deinterleaved in such a way that you've first got 8 samples for the left channel, then 8 for the right, 8 for the left, and so on..
For a mono stream it'd be much easier.