nothing much

This commit is contained in:
zeromus 2020-04-09 16:03:43 -04:00
parent b8accdfd75
commit e2389e25d7
1 changed files with 321 additions and 316 deletions

View File

@ -44,7 +44,12 @@
Should shift occur on all stages of ADPCM sample decoding, or only at the end?
On the real thing, there's some kind of weirdness with ADSR when you voice on when attack_rate(raw) = 0x7F; the envelope level register is repeatedly
reset to 0, which you can see by manual writes to the envelope level register. Normally in the attack phase when attack_rate = 0x7F, enveloping is effectively stuck/paused such that the value you write is sticky and won't be replaced or reset. Note that after you voice on, you can write a new attack_rate < 0x7F, and enveloping will work "normally" again shortly afterwards. You can even write an attack_rate of 0x7F at that point to pause enveloping clocking. I doubt any games rely on this, but it's something to keep in mind if we ever need greater insight as to how the SPU functions at a low-level in order to emulate it at cycle granularity rather than sample granularity, and it may not be a bad idea to investigate this oddity further and emulate it in the future regardless.
reset to 0, which you can see by manual writes to the envelope level register. Normally in the attack phase when attack_rate = 0x7F, enveloping is
effectively stuck/paused such that the value you write is sticky and won't be replaced or reset. Note that after you voice on, you can write a new
attack_rate < 0x7F, and enveloping will work "normally" again shortly afterwards. You can even write an attack_rate of 0x7F at that point to pause
enveloping clocking. I doubt any games rely on this, but it's something to keep in mind if we ever need greater insight as to how the SPU functions
at a low-level in order to emulate it at cycle granularity rather than sample granularity, and it may not be a bad idea to investigate this oddity
further and emulate it in the future regardless.
Voice 1 and 3 waveform output writes to SPURAM might not be correct(noted due to problems reading this area of SPU RAM on the real thing
based on my expectations of how this should work).
@ -617,7 +622,7 @@ int32 PS_SPU::UpdateFromCDC(int32 clocks)
sample_clocks++;
}
while(sample_clocks > 0)
while(sample_clocks > 0)
{
// xxx[0] = left, xxx[1] = right