Reasonable implementation of PCM

[lidnariq]

The PCB says "DPCM", although who knows whether that actually means anything.
https://www.flickr.com/photos/81889059@N08/25409422524/ shows some Cypress part (has to be CHR RAM), a 8-pin microcontroller for the CIC, a voltage regulator, a QFP that's probably a CPLD as bankswitching and maybe some voltage translation.

There's hidden space on the board behind the label, which has to be hiding the PRG ROM. With only 10 made, we're probably never going to get to find out, unless Bunnyboy tells us.

[thefox]

"The board is custom made by bunnyboy, has 64MB ROM with a custom UNROM-like mapper (4096 16K banks)." -Shiru at http://nintendoage.com/forum/messagevie ... did=152873

[za909]

I'm trying to figure out what would be a good container format that compromises between quality and easy, realtively fast decompresson. From what I can tell it's a reoccurring thing in the sample data to have the same value multiple times in succession, so an RLE compression format could definitely help reduce size tremendously. To stick to 1 byte/IRQ, I'd go for a custom format like this:

Code: Select all

RRSS SSSS
RR: Number of times to repeat the sample
SSSSSS: 6 bits of sample data

Hopefully this could be "decompressed" without losing too much time, and at 6-bit resolution we could stick to regular PCM or some delta-based format.

[FrankenGraphics]

Lots of space

Depending on what results you want, could one cut up the song arrangement in reusable bars and repeat? That'd slice memory requirements conciderably and still retain a lot of extravagance. From an artist's point of view, seamless loop constraints isn't much of a bother.

If it could work synced with the onboard channels, you can probably get even greater fidelity out of the bit depth and sample rate by reserving all or the most dominant percussive sounds to the synth channels, and use samples for arranged parts with less dynamic width, such as strings and whatnot. Drums, vocals and percussives tend to cause the most audible artifacts in low bit samples due to their wide dynamic range and quick changing envelopes.

[tepples]

Depending on what results you want, could one cut up the song arrangement in reusable bars and repeat? That'd slice memory requirements conciderably and still retain a lot of extravagance.

You mean like the introduction to Space Racer?

[FrankenGraphics]

Depending on what results you want, could one cut up the song arrangement in reusable bars and repeat? That'd slice memory requirements conciderably and still retain a lot of extravagance.

You mean like the introduction to Space Racer?

Almost! Space racer sounds like they are using a collection of (almost) singular sounds or 1-beat segments played in a row, where i propose taking more of a complete score (which has to be written, arranged and mixed according to specs), and slice it up into repeatable 2, 4 or 8 beat bars (or 3 or 6 or 12), depending on what we can afford. The total amount of bars used per song should be kept relatively low.

You can get pretty creative with this stuff by allowing the engine to overwrite what bar from memory is being played.
For the sake of the examples, let's assume we can afford 8 beats per bar/sample file:

Case A: Bar 1 plays for 8 beats 2 times.
Case B: Bar 1 plays for 8 beats, then bar 2 plays for 8 beats
Case C: Bar 1 plays two times, but on the 5th beat the 1st time, it is overwritten and repeats prematurely, thus creating variation out of just one bar.
Case D: Bar 1 plays 2 times, but on the 7th beat the 1st time you call bar 2 which then plays for 2 beats before bar 1 overwrites bar 2 again. Can be used for fills, suspension, and more advanced variation.
Case E: Bar 1 plays 1 time and is overwritten 5th beat by a bar containing just a short echo tail and then silence.

And lots and lots of other usable cases for getting the most out of a couple of bars.

As for arranging songs in the engine, i'd have one bit decide wether to repeat the last used bar or to scale one position up in the score bank, so the arrangement data doesn't have to be so explicit about everything. Sometimes, you specify a bar adress (a nibble could represent this if we're happy with max 16 bars per song), sometimes, you don't need to specify anything. And perhaps, if permittable, a nibble to decide start point within that bar - that'd give all the creative freedom needed do do something amazing.