PCM scaling and mixing

Printable View

Show 40 post(s) from this thread on one page

12-07-2015, 01:41 PM
Mask of Destiny

Quote:

Originally Posted by tomaitheous

That's what I remember TmEE saying as well. That 26khz was a practical limit, not because of the DAC or the 2612, but because other stuff he was doing on the z80 side.

I could have sworn he said it seemed like the YM-2612 was losing writes, but perhaps I'm mis-remembering. Since Stef has seen different results that seems likely.

Quote:

Originally Posted by tomaitheous

Forgive my ignorance on this, as I never used the z80 when coding for the Genesis, but the bus request is automatic if rom (or cart memory) is mapped into the z80 address range? Then what is the manual bus request for? ($a11100 ?) Is that only for the z80 dedicated ram and the ym2612?

Think of the Genesis as two mostly independent computers. One of them has the Z80, it's RAM, the bank register and the YM-2612. The other has the 68K and all the rest of the hardware. These two computers are connected so that each CPU can get at the hardware attached to the other computer. This requires requesting the bus from the other CPU. When the Z80 tries to access devices on the 68K side this is automatic. When the 68K tries to access devices on the Z80 side, it must manually request the bus with $A11100. Presumably the reason for this is that it's more efficient for doing bulk updates whereas automatic bus request is more efficient for occasional access (say grabbing a sample or writing to the PSG).
12-07-2015, 04:36 PM
matteus

You're right spear :) previously tiido had said the y2612 loses writes
12-07-2015, 05:08 PM
tomaitheous

Quote:

Think of the Genesis as two mostly independent computers. One of them has the Z80, it's RAM, the bank register and the YM-2612. The other has the 68K and all the rest of the hardware. These two computers are connected so that each CPU can get at the hardware attached to the other computer. This requires requesting the bus from the other CPU. When the Z80 tries to access devices on the 68K side this is automatic. When the 68K tries to access devices on the Z80 side, it must manually request the bus with $A11100. Presumably the reason for this is that it's more efficient for doing bulk updates whereas automatic bus request is more efficient for occasional access (say grabbing a sample or writing to the PSG).
Ok, so on cart sram would be kind of a cheat/work around. But I'm cool with that. I need to find out what my Everdrive cart supports.

Ok, that makes sense. And it also makes sense why the z80 is given priority to the 2612.

For 30-32khz, I like the idea that nothing will be resampled/read from a higher rate of that. It's also kinda Amiga-ish in output rate. I say kinda, because the Amiga's period based divider is a really high resolution in comparison.

~30khz is 1:1, so everything else is less than that. That makes for a nice optimization IMO (depending on the cpu). I wrote out a bunch of different routines, and couldn't really get any faster than ~42 cycles for frequency scaling (even assuming the 1:1 method). That does include the sample loop trap and writing directly in cart sram, but doesn't include volume or mixing. In all honestly, that isn't too bad. 42*4*512 = 86k cycles or 67% cpu resource. I'll post those later (not really happy with them).

I'm still toying with the idea of pre-calculated code paths.

Code:

move.b (a0)+,d7 ;8 bne.w skip ;10 jsr (a2) ;18 <- reset sample loop (or end sample output; the control code can mean either). .skip move.b d7,(a1)+ ;8 ;26 cycles per inc ;8 for duplicate write

26 cycles for a fresh read/write (1:1 @ 32khz), and 8 cycles for a duplicate write (less than 1:1). But it gets convoluted. And the stepping isn't as smooth (whether it's audible or not, won't know until it's tested). Basically it's about 400k of premade code paths. 12 notes * 16 inter-note frequency steps (linear) * 4 octaves ( the lower octaves are useless) * 64 writes (code clumps) * 8bytes (I think those are all 2 byte instructions). I set the writes to 64 so that I could average them by calling a few different ones to get a finer precision. If the stream output is 512 bytes, then I can mix up 8 different code paths to get a better average. I shouldn't need to trap for buffer underruns because each code path writes exactly 64 values.

If four streams were played back at ~16khz (typical note range for MODs) on the fixed 30.6khz output, that would be ~17 cycles per sample @ 512 samples per channel x 4: or ~27% 68k cpu resource for all four channels. Z80 would handle volume and mixing.
12-07-2015, 05:24 PM
Kamahl

That's some nutty optimisation there. I'm not really seeing how you can go any faster then that, but optimisation isn't really my forte.
12-07-2015, 06:50 PM
Barone

Quote:

Originally Posted by tomaitheous

Code:

move.b (a0)+,d7 ;8 bne.w skip ;10 jsr (a2) ;18 <- reset sample loop (or end sample output; the control code can mean either). .skip move.b d7,(a1)+ ;8 ;26 cycles per inc ;8 for duplicate write

Using a jmp instead of jsr will save you some cycles, won't it? I know it will only affect the reset/end but... And you also save some cycles on the return by replacing the rts for a fixed address jmp.
12-07-2015, 08:30 PM
tomaitheous

Quote:

Originally Posted by Barone

Using a jmp instead of jsr will save you some cycles, won't it? I know it will only affect the reset/end but... And you also save some cycles on the return by replacing the rts for a fixed address jmp.

The JSRs are only taken if the control for loop point reset is encountered, so it's not very often. I need JSR because I need to return to the same spot as the call, which can't be precalculated. It can't be precalculated because that group of instructions, or the single move.b d7,(a1)+, makes up a block of 64 units.. among almost a thousand blocks. Anyway, the phase accumulation overflow is actually built into the code path itself, so it needs to return to that spot regardless if the pointer has been reset for a loop point. If it was a simple/small unrolled loop, I would use specific jump offsets and fixed return offsets as well, which is what I think you're suggesting.

Quote:

That's some nutty optimisation there. I'm not really seeing how you can go any faster then that, but optimisation isn't really my forte.

I'm not the first, or the last, to use pre-calc code paths like that. There's even an official Genesis game that does this, but uses even more (768k IIRC). Besides, I did this on the PCE for doing vertical scaling of textures for raycasting - it meant I could store way more textures than normal but still keep the speed benefit (pre-scaled code path VS pre-scaled textures). I listed 400k for this one, but it'll be less than that because as the frequency gets further away from 1:1, the more the smaller of the two units will be used instead (a single move.b d7,(a1)+ ).
12-07-2015, 09:14 PM
Kamahl

Quote:

Originally Posted by tomaitheous

I'm not the first, or the last, to use pre-calc code paths like that. There's even an official Genesis game that does this, but uses even more (768k IIRC).

Bloodshot/Battle Frenzy I believe. Really once you get to that point that's about as optimised as you can get, other than fishing for cycles here and there.
12-07-2015, 09:19 PM
Barone

Quote:

Originally Posted by tomaitheous

The JSRs are only taken if the control for loop point reset is encountered, so it's not very often. I need JSR because I need to return to the same spot as the call, which can't be precalculated. It can't be precalculated because that group of instructions, or the single move.b d7,(a1)+, makes up a block of 64 units.. among almost a thousand blocks.

I see, but if I'm not misunderstanding what you said (a lot of the talk here is not really 100% clear to me) you could still do it like this:

Code:

LEA RETURN,A0 ;Return address goes in A0. JMP routine ;Jump to the subroutine RETURN ;A0 points to this spot. Then to return, just JMP (A0). By avoiding use of memory, this saves 8 cycles. (Note that the LEA instruction references the label RETURN with PC-relative addressing.)
12-07-2015, 11:58 PM
tomaitheous

Barone: Ahh I see what you mean. It saves 16 cycles total, but it also increases the 2 bytes for the LEA instruction; lea (.skip, PC), a3.

I think going about the loop point reload thing all wrong. I can reorganize this a little bit..

Code:

move.b (a0)+,(a1)+ ;12 bne.b .skip ;10 move.l d0,a0 ;8 move.b (a0)+,-(a1) ;12 .skip

22 cycles for a new fetch. And 8bytes for the unit.

or...

Code:

move.b (a1),(a1)+ ;12

12 cycles for a redundant write. And 2 bytes for that unit.

The 15khz mark is the same cycle average (17), but everything above that gets a slight reduction in cycles thanks to a lower ceiling number (22 vs 26). The loop point reload doesn't need anything more than an address vector reload and a sample refetch. And there's enough regs 'cause I'm don't doing one stream/channel 512 byte packet at a time. Size is still the same for both.
12-08-2015, 12:11 AM
Barone

Quote:

Originally Posted by tomaitheous

Barone: Ahh I see what you mean. It saves 16 cycles total, but it also increases the 2 bytes for the LEA instruction

It just saves 8 cycles total if you consider the LEA cost. I'm used to global cost-only, lol.

It looks very promising, man, I'd love to see this project coming to fruition.
12-08-2015, 01:28 AM
Mask of Destiny

Quote:

Originally Posted by Barone

(Note that the LEA instruction references the label RETURN with PC-relative addressing.)

This is a bit pedantic, but note that while at least some assemblers will optimize LEA RETURN,A0 to use either pc-relative or absolute short mode, it's probably better to be explicit if that's what you want. So LEA RETURN(PC),A0 or LEA (RETURN,PC),A0.
12-08-2015, 01:35 AM
Barone

Not pedantic at all IMO. As I usually hack things directly in hex I'm not used to such compiler-related concerns. Thanks for the heads up.
12-08-2015, 02:40 AM
tomaitheous

Just to go off tangent here for a second...

PSG PCM. So, if I got this correct, you set the PSG channels some a high frequency (or a super low frequency and constantly resent the waveform to keep it from shifting to the next height), and use the volume as the way to control the waveform output (non linear PCM). Doing it across multiple channels increases the positions available for the combined amplitude output?

What is the volume relationship of the PSG to the YM2612? Is it the same across most models? The idea would be to get at least 4 levels of PCM amplitude, as close to linear as possible, that's 1/2 the DAC channel output's lowest amplitude. Hell, I'm not even sure how the centerline output of that PSG PCM would be in relation to the DAC output (high frequency trick might work better for this). So basically, paired together they would give roughly 10bit audio. Though I'm a little skeptical how good it would actually sound.

IIRC, on the 2612 side you can't use the volume reg with FM channel when it's in PCM mode -right? I'm sure if you could, coder's would have already done this for a cheap range compression.

On a different note, assuming the z80 has enough resource for this, if the main output is fixed at 30khz - everything that plays at a lower rate could use a non-linear type interpolation. I mean, since the code paths already knows ahead of time how many runs of redundant samples to write, this could be encoded as an RLE control code followed by the length, and the next sample value. Since the PCM stream isn't the full 8bits, the D7 could be used for the RLE flag and the length is the lower 7bits. So only two bytes needed (rle_flag+length and next sample). The z80 side would continually generate the average ( [previous_sample_cache+target_sample]/2 ) until the length expires. Though at 116 T-cycles, I'm not sure there's enough time to all four channels, and volume, and mixing, and prefetching/building for vblank area. Maybe just for one channel. Probably wouldn't even notice the effect unless a channel scaled a stream to as low as 8khz (closer to 1/4 the main output). Hell, I'm not even sure what it would sound like at that low of a rate (the shape of the interpolation should look like a rough 2^x curve.. flipped around).

Maybe simply sticking with linear interpolation and just providing the slope/delta and length would be faster. Yeah, definitely faster since there would be no averaging per sample slot. It would just be a simple addition. It would be the same amount of data packet size.

Thinking more on this, on the z80 side, the control code could be used as two things. If D0-D6 is zero, when D7 is set, continue adding previous delta. Everything is encoded into one byte. No pairs or seperate delta/length bytes. The 0x80 control codes would normally take the place of a samples, so it wouldn't be any larger or smaller than 512 normal samples per frame, per channel. No counter needed on the z80 side either (length counter). This could work.
12-12-2015, 04:58 AM
Mask of Destiny

Quote:

Originally Posted by tomaitheous

PSG PCM. So, if I got this correct, you set the PSG channels some a high frequency

Yep.

Quote:

Originally Posted by tomaitheous

and use the volume as the way to control the waveform output (non linear PCM).

Yep. You can find a volume table on SMS Power.

Quote:

Originally Posted by tomaitheous

Doing it across multiple channels increases the positions available for the combined amplitude output?

AFAIK, the tone channels are added together so yes.

Quote:

Originally Posted by tomaitheous

What is the volume relationship of the PSG to the YM2612?

I think I measured the max level of a single YM-2612 channel as roughly 7 times the max level of the PSG measured peak to peak on my Model 1. That's based on the numbers I have in BlastEm (assuming I'm interpretting things correctly, it's been a while).

Quote:

Originally Posted by tomaitheous

Is it the same across most models?

Certainly not the same across all models. Not sure which ones are different though.

Quote:

Originally Posted by tomaitheous

IIRC, on the 2612 side you can't use the volume reg with FM channel when it's in PCM mode -right? I'm sure if you could, coder's would have already done this for a cheap range compression.

If you don't need FM at all, you can use the undocumented register $2C that Oerg866 discovered in combination with the LR panning bits for all the FM channels to get some extra resolution. Details are in this thread.

On a tangentally related note, I've spent some time rewriting my pure Z80 driver to do re-sampling during buffering rather than during playback. I don't have anything resembling a working driver with this new version yet, but I'm far enough along to see that the timing works. There's even enough time during active display that I can stick a volume table on the cartridge allowing up to 128 volume levels without consuming any Z80 RAM. I considered trying to add in a 3rd channel instead of having the external volume table, but even if it's fixed sample rate with no volume I can't make the timing work out on PAL at 12Khz (fixed sample rate might barely work on NTSC). Initial version won't support jump points or samples bigger than 32KB, but I think both are solveable.
12-13-2015, 02:55 PM
Sik

Yikes, late to the party.

Quote:

Originally Posted by Mask of Destiny

l is used in that last write under the assumption that the MSB is always zero. Given that you can't read from 68K work RAM, that's probably a pretty good assumption unless you're on the 32X (though if you're on the 32X, you would probably use the PWM output for samples anyway).

If you're making a 3D game on the 32X, you may want to use both SH2s for graphics (one for 3D calculations and one for rendering polygons). Even then, the MSB will always be 1 in this case since you're forced to run off the 32X area ($800000~$9FFFFF).

The truly useless bit is the next one actually: the $C00000~$FFFFFF range is unusable, and $400000~$7FFFFF in practice is only ever used in one situation (when booting from a cartridge and trying to use the Sega CD area). In fact this is how Echo handles things: it skips bit 7 but not bit 8. This means the same sound engine can be used on both the MD and 32X (or even MCD if you dare to cope with the RAM swapping).

Also, if you write to $6001 instead of $6000, you can use H to write a hardcoded 0 and L to write a hardcoded 1 =P (this actually made Echo break BlastEm initially, go figure)

Quote:

Originally Posted by Mask of Destiny

This gives you access to the bottom and top 4MB so you can set a bank to access RAM (you can't read it, but you can write it which may be useful for synchronization with the 68K in some cases).

Writing doesn't work on some ASIC revisions either.

Quote:

Originally Posted by tomaitheous

I was thinking maybe lower the output frequency to 15.3khz, which is 256samples per 1/60th frame. 256*(12+1) is ~3,328 68k cycles total. I was thinking along the lines of: the 68k scales the streams, but the z80 does the volume and accumulation. Since, well, the z80 isn't doing much.

In other words, Stuck Somewhere In Time, although if I recall correctly the 68000 does pretty much the full mixing and the Z80 only plays it back (I remember suggesting to try something much closer to your idea before though, precisely because the Z80 is sitting bored =P). I think the reason of going with that approach was to be able to get 26KHz with as few timing offsets as possible, it even relies on word writes to Z80 RAM to shave off cycles during buffer transfers (it eats up like 90% of the frame duration, I think?).

Sounds stupid since every track is a chiptune but it was easier to just write a full-blown MOD player (especially when the tunes were still being composed). Also the hidden track is not a chiptune and sounds like you crammed a CD player into a cartridge =P Press A+B+C+Start when Eddie appears

Show 40 post(s) from this thread on one page