gasega68k wrote:About the sound: i made the song with tfm music maker and the 68000 is used to play the music with a tfc replayer that i made in asm, but using only 5 channels, thus i use the sixth channel to make two-channel samples with the z80. The samples are compressed 2 to 1 and is played directly in the z80 ram, the samples are played at about 6900hz and each channel can use 3584 bytes (about 1 second),the driver uses less than 1k. I did it this way because with DMA, the samples do not sound right, because you have to stop the z80 during DMA.
I have not tested this on real hardware, if anyone can do would be great.
What sort of compression are you using? 4-bit DPCM or ADPCM? (I assume not just 4-bit linear PCM)
4-bit DPCM seems to be a common choice. Stef uses that, as does Sega's own SMPS. (a 4-bit delta sample format with fixed "palette" of 16 delta values -Stef's engine uses a considerably smaller range than Sega's, the latter just using powers of 2)
Though, honestly, at the bitrates/sample rates used here, plain linear 4-bit PCM could probably work pretty well too, if not better than DPCM. (at such low bitrates, linear 4-bit PCM should work fairly well, and from what I understand, ADPCM/DPCM doesn't tend to fare particualrly well at such low rates)
On that note, Tiido made an interesting sort of hybrid 2-bit DPCM/ADPCM scheme with 3:1 compression over 8-bit. (TADPCM) It's technically ADPCM, but should require CPU overhead closer to DPCM since it uses explicit delta values rather than algorithmically derived ones. (the "adaptive" computation is done entirely on the encoding end rather than both encoding+decoding as with typical ADPCM or CVSD)
It uses an 8-bit which is used as a definition for the following 12 2-bit deltas (2 bits defined +/- the 8-bit value or 1/2 that, ie 128 would be used as +128, -128, +64, -64), and then the next 8-bit value is provided for the next 12 deltas. So you get 12 samples in 4 bytes, or 3:1 over 8-bit PCM.
Chilly Willy has a 22 kHz demo using this format in his CVSD thread:
viewtopic.php?t=586&postdays=0&postorder=asc&start=15
Chilly Willy's 2-bit CVSD offers 4:1 compression and sounds pretty good too considering (in the demos, there's a few areas it sounds better than TADPCM, but that's likely more down to encoder limitations than actual quality of the compression). 1-bit CVSD would provide the highest compression ratio, but more quality lost relative to sample rate (still maybe a good option for certain low bitrate stuff, especially speech). But then you've got to consider the CPU overhead involved with CVSD relative to sample rate too. (2-bit is probably much more useful overall for typical MD stuff, and TADPCM probably more so)
I suppose you could also try a fully fixed palette 2-bit DPCM version to (like 4-bit DPCM but only 4 values), but I doubt that would sound very good. (at least better than 1-bit DPCM like the NES does)
With your current set-up, you're loading entire ~1s long chunks of samples into Z80 RAM and then playing them? That would work well as long as you kept samples within that short length, or segmented longer ones to load in chunks. (but you'd get small gaps between playback then, perhaps less noticeably if you specifically chopped up samples with that in mind, especially for speech)
Loading samples into Z80 RAM like that also works around the Z80 bank switching overhead for multi-channel playback. (well, at least it will once you exceed 32 kB of samples in ROM
)
Stef wrote:gasega68k wrote:
I guess you can somehow do direct write in tiled organization because of the way the raytracer work. I tried to find a way to organize my bitmap buffer in the SGDK bitmap engine but i really can't find anything working efficiently :-/ Modifying the organization would require too much overhead in bitmap drawing functions as line or polygon filling so i have to manually transform the bitmap in cell during the vram upload (software transfert). At least this has the advantage of not screwing up the Z80
Would it help if you made a polygon renderer that used column filling rather than line filling?
That'd be a pain to do for full-res 4-bit pixels, but more useful if you were willing to use paired pixels (bytes) like this set-up does. You'd lose resolution, but gain speed. (and could consider dithered color like this too)
Oh i understand of course, the sound is pretty good given you have these sample limitations ! I developed a specific driver for the bad apple demo which take care of the DMA contention but it would not work in your case as you extend the vblank (i used vint on Z80 side to detect start of blank period). But now i'm thinking about it, if you limit your frame rate to 20 FPS max (which is smooth enough and it seems to never goes higher anyway) you can divide your DMA on 3 frames and then have complete screen display and an easier DMA contention with Z80... but that would require double buffering then :-/ ok, not a good idea :p
Could you possibly use a combination of vblank interrupt and YM2612 timers for working around extended vblank?
Ie use vblank to sync up with video timing, and set a YM timer to account for the extended blanking period, and poll the timer to keep track of where active display will end. You could maybe even keep a screen counter that cycled every few frames and tie that to a framerate cap put on the renderer (and have the 68k keep a similar counter so it only ever set DMA on the right frame). That probably wouldn't help that much overall though, since you'd still have the same minimum per-frame bandwidth bottleneck to consider. (on frames asserting DMA) So probably not worth it, depending how long your mixing buffer was. (ie long enough to smooth out CPU time over several frames)
To maximize usable CPU time per frame, you'd also probably want to set different timing for 50 and 60 Hz, or set the display taller in 50 Hz so the extended vblank period is of an equal scanline count. Ie sync to v-int in either case, but make sure the actual vblank period is equal on both, so if 60 Hz has screen cut to 176 lines with 86 vblank lines, you'd want the 50 Hz screen to be set to 226 lines, and positioned such that the same timer set-up code would work. You could still leave that added space black, of course, or just tiled with a repeating 8x8 texture. (still, PAL uses slightly faster h-sync timing than NTSC, so that's a consideration too -iirc it's 15.65 vs 15.75 kHz)
Wait . . . does the v-int signal the normal start of vblank, or end of vblank?
. . . Well, in any case, the generall idea (interval timer combined with v-int) would still apply, just some of my above comments won't make sense.
