Some audio stuffs

[ccovell]

ccovell: How did I not know about this demo!?

I've asked myself that question, too.  :-|  Maybe people were preoccupied at the time.

Anyway, depending on the odd/even phase of the VCE at the time that you make it static, dithered patterns consistently give either a usable red (verging a tiny amount towards orange) channel over 15 shades, or a cyan (harder to wrangle because it is 2 RGB channels combined.)  So:


Another test demo: http://chrismcovell.com/data/OldIsBeaut-Test.zip

I didn't use any special tools; removing the R channel from 24-bit pictures is good enough, and the R can be remapped separately to greyscale, or some ramped red/grey; the remaining G&B can be remapped down to PCE BG palettes, since there are now 64 colours possible per tile that have to be reduced.

[Bonknuts]

Ahh ok. So remove the red channel (or crush it near completely down) because the shift (Y to chroma interference) will re-introduce the red back in? I could never figure that part out (I did artifact colors in that mode with dot crawl filter off, but could never figure out how to calculate the colors).

 I ran it on my new 4k HD set and it looks perfect! So even the newer sets with their fancy digital processing filters, couldn't separate Y from C in that res mode. The high color part is very nice, but transparency effects makes sooooooooo many new things possible for demo scene stuff! This is pretty awesome Chris

 So I can just use my RGB to YUV converter, crush the R-Y channel, and convert back?

[ccovell]

I don't know what the effect is if you work in YUV colour space, but one of the side effects of this effect is that the Green channel gets slightly muted... you can see that from Yellow to Green at the far left, there is some blue mixed in, which should never be there.  But, ah, well.

[Bonknuts]

Ok. I promised earlier this year that I would do a 12 channel driver for PCM. 4 regular channels and 8 PCM channels.

 So 9% cpu resource for the driver and 12% cpu resource to mix 8 channels into a single buffer stream. 4 of the channels have direct volume control, and the second set of 4 channels are direct non-changeable volume (max volume).

 Due to optimizing for less amount of cpu resource, the sample format is arranged in a non standard format. There's a little bloat too: and extra 720bytes per second. Not too bad, considering I use 6bit PCM for each channel. I could have done 7bit, but it wasn't optimal processing wise for all 8 channels.

 21% cpu resource total for 8 PCM stream playback out of 12 channels.


 The problem I have now.. is how to demo all 8 PCM channels at once.. along with 4 regular PCE channels.



 Note: All PCM streams are signed 2's compliment. I could technically speed it up be keep all PCM format as non-signed format. It'll still mix, but it will create a dynamic DC offset IIRC. Might not be noticeable.

[Bonknuts]

Since a few other arrangements of straight PCM channels use the same basic format, I have some resource numbers for those too.

 All have 4 regular PCM channels.

 4 PCM channels @ 6bit with volume control: 16% cpu resource.

 4 PCM channels @ 7bit with volume control: 18% cpu resource.

[Bonknuts]

If it helps -- probably not -- here is my writing loop in Old is Beautiful for playing 8-bit PCM.  I do double the channels (4) just to get a louder overall output.

Code: [Select]

Sample_Loop:
bbs0 <samp_interrupt,.no_sample_play
bbr0 <samp_on,.no_sample_play
.samp_loop:
smb0 <samp_interrupt ;Stop player from entering twice
lda [sampadd]
beq .sample_end_marker
tax
lsr a
lsr a
lsr a ;divide by 8!
sax
and #$07 ;top 3 bits
ldy #3
sty $0800   ;chan 3
sta $0806 ;Save sample!!
dey
sty $0800   ;chan 2
sta $0806 ;Save sample!!
dey
sty $0800   ;chan 1
stx $0806 ;Save sample!!
stz $0800
stx $0806 ;Save sample!!
incw <sampadd
rmb0 <samp_interrupt ;Stop player from entering twice

.no_sample_play:
rts
.sample_end_marker:
rmb0 <samp_on ;no more samples!
rmb0 <samp_interrupt ;Stop player from entering twice
rts

 I just looked at this again, and noticed you're doing something a little different.

Code: [Select]

sax
and #$07 ;top 3 bits

If you set channel vol to $DF and second channel to $CB, you output 5bit values to both.
 As in:

Code: [Select]

tax
lsr a
lsr a
lsr a
sax
asl a
asl a

 Did you do an 8bit vs 10bit paired channel setup to save 2cycles per sample?

(edited)

[ccovell]

I wanted to get better than 5 bit audio, but saving on space was the most important consideration, followed by "unpacking" speed, so 8-bit linear was what I chose.  8-bit is also easiest to edit in sample editors.

I calibrated the output (ie: how much to lower the volume of the lower 3 bits' channel) using an 8-bit sawtooth wave and an oscilloscope.
ex:

Code: [Select]

lda #$02
sta $0800 ;Choose channel 2
lda #$99 ;#$99 gives 8-bit precision!
sta $0805 ;Panning
lda #$C0+$1F        ;DDA ON!
sta $0804 ;Write PCE Volume

[Bonknuts]

Yeah, you did the same thing but calculated it at 1/4 for the second part. It saves two cycles since all you needed was and #$07 instead of two ASL's.

 


7bit PCM channels:
 I've seem to have run into a problem with my mixing routine. I was trying to mix without sign extending every sample before the add. This worked for the final 8bit + 8bit (detecting and branching code), but not the 7bit+7bit leading into them.

 So I'm gonna switch over to unsigned samples and just add them. It works, but it doesn't look as pretty (should sound identical). I mean, I've done this on the PCE with regular channels and it was fine (made all waveforms in the upper 10-1f range only). This means I need to rebuild a few LUTs...

[elmer]

I calibrated the output (ie: how much to lower the volume of the lower 3 bits' channel) using an 8-bit sawtooth wave and an oscilloscope.

That's a nice bit of lateral thinking. Very cool trick to get 8-bit precision.