|
| |
|
Wir sind die Nacht [2019] |
Released At :
Intro Creation Competition 2018
Achievements :
C64 Demo Competition at Intro Creation Competition 2018 : #14
Credits :
Scrolltext and other text in this release : ()
Download :
Look for downloads on external sites:
Pokefinder.org
Production Info
Submitted by ChristopherJam on 24 January 2019
Some technical details about this intro.
The data hierarchy for the music is as follows:
- A song is a list of segments from the original track.
- A segment is broken into list of slices
- A slice is composed of up to 255 blocks (this way slice playback doesn't have to handle page crossings)
- Each block represents six samples as an 8 bit index into a palette of deltas
All of the segments share a single 256 entry palette; each palette entry contains six delta values
A slice contains a starting sample value, then up to 255 palette indices.
so, total size (excluding sequence information) is roughly 1.5k+nsamples/6
There are eight unique segments, with a total duration of 8.54 seconds. At a sample rate of 7819Hz (one sample every two raster lines), that's 66786 samples. I lose around 70 bytes to padding when dividing the segments into slices that don't cross page boundaries, so the total block storage is 11,201 bytes
The slice playback routine is a CIA interrupt scheduled to ensure block boundaries never clash with character DMA. Everything else runs in main, including updating the pointer to the next slice whenever the previous one has commenced playback.
- The blocks are decrunched to the end of zero page, one block every 12 raster lines.
- The encoder performs carry prediction/compensation, so there's only one CLC required to decode each block.
- The sample playback method is Mahoney's; I've lifted the initialisation code directly from the Musik RunStop technical details, and built my own translation tables from his measurement data (thanks Pex!)
Scroller font was originally a 5x2 heavily based on Blackmoor LET. I did a lot of hand pixelling to try and get it to look nice in the available cset space, but then I had to squash it down to a 4x2 at the last minute when I didn't have enough ram for the table that contains the char indices for each glyph.
Most of the initialisation code is overwritten by a second decrunch pass once initialisation is complete.
Approximate memory map is as follows:
init time:
0x4000..0x6bc1 sampledata.prg (one byte per six samples)
0x6bc2..0x6bf4 sd.prg (some sequence data that didn't fit into main.prg)
0x6c00..0x6c64 tc.prg (tinycrunch. Overwritten with 'rasterbar' characters after it's done with)
0x6c64..0x6e23 init.prg (SID detection, sample and music playback init, VIC init, scrolltext load location)
0x6ed0..0x6fc2 pextable6.prg (sample translation table for 6581)
0x6fd0..0x70c2 pextable8.prg (sample translation table for 8580)
0x710f..0x7530 art_tc.prg (tinycrunched artwork. Overwrites 6c78..7530)
0x7531..0x79e9 main.prg (effect code, music playback, and sequence data)
0x7a00..0x7fff vqpalette.prg (six deltas per palette entry)
run time:
0x0002..0x00f4 pextable
0x00fa..0x00ff current sample block
0x0100..0x01dd scrolltext
0x01f8..0x01ff stack
0x4000..0x6bc1 sampledata.prg
0x6bc2..0x6bf4 sd.prg
0x6c78..0x6fe8 screen
0x7000..0x7270 clogo.prg # 78 logo chars
0x7270..0x7530 cfont.prg # 85 font chars
0x7531..0x79e9 main.prg
0x7a00..0x7fff vqpalette.prg
Apparently I didn't quite keep it updated in the last few days of release; the last copy I checked in had a number of inaccuracies. I think I've corrected them all in the above, but I wouldn't be surprised if there are still a few fenceposts here and there. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia (1)
|
|
| Forum | |
|
| Info on other sites | |
|
| Support CSDb | |
|
 |  |
|
