Myself086 wrote:
Absolute writes to sound ports are replaced with JSL but not absolute indexed yet. On what changes should I set flags? I understand the bits at $7F4116 and $7F4115.
I think games almost always write to the sound registers with absolute indexed. Before, I was thinking the flags in $7F4116 would be set anytime $4003,$4007,$400B,$400F are written, but now I'm not 100% certain. Looking at my code I see that I only set those flags when length counter enable is turned on. I'm having trouble understanding my old code 100% at the moment, doesn't seem like I can do an adequate job explaining it. The SPC code will only trigger decay if that bit is set, so I'm not sure why I have those 2 features seemingly interdependent.. either I'm misunderstanding my code, or I did it wrong (and I'm finding a bug).
edit: Also, sweep register flags (D6 and D7 of $7F4116) need to be set whenever $4002,$4006 are written
I've been looking through my code for the first time in a while (hard to believe it's been 17 years since I wrote most of this), made some observations:
Right off the bat in 'detect_changes', this branch label implies it has checked the decay enable (D4), but it's actually checking the length counter enable (D5). Very misleading.
Code:
detect_changes:
lda $7F4000
and #%00100000
bne decay_disabled0
D5 of $7F4116 selects mono/stereo mode for the 2 pulse channels, you probably noticed that.
There sure is ton of commented-out code left in there. From the bad old days before I used version control.
Lots of copy+pasted+manually edited code in there. Not sure why I didn't just use macros instead.
Lots of annoying inconsistencies. Like I have this defined:
no4016 = $56 ; $4016
But sometimes I refer to it as no4016, sometimes as $56. Ugh, WTF. Also some places where I use hex like 20h instead of $20 like everywhere else.. minor WTF.
Myself086 wrote:
Memblers wrote:
Also, there is one known bug in my update_dsp routine. It causes occasional glitches. The cause was something really weird with the CPU/SPC alignment, IIRC it worked fine on hardware but was breaking on every emulator. kevtris said inserting a NOP in there fixes it, I may be able to ask him tomorrow where that NOP should go exactly. But probably just in-between my $2140/$2141 accesses, they were just too close together I guess. I don't think that's affecting the audio here, but it's possible.
I noticed a bug while rewriting this and I probably fixed exactly what you're talking about. The index was written before the data byte but it should be the other way around. The SPC waits for index to change so it can read the data byte, otherwise it can fail to read the correct data. I never tried running it before changing update_dsp.
Good find, that is exactly the fix. It's really weird that it apparently works on the actual hardware, but it's still a race condition and should be fixed.