BRR streaming code not working for unknown reason

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
BRR streaming code not working for unknown reason
by on (#142164)
spc700 side
Code:
ldx #$00
-;
cpx $f6
bne -
lda $f4
sta $c000,x
stx $f6
inx
cpx #$99
bne -
ldx #$00
bra -


65816 side:
Code:
spc700_streaming:
php
sep #$30
ldx #$00
-;
lda wave,x
sta $2140
stx $2142
-;
cpx $2142
bne -
inx
cpx #$99
bne --
plp
rts


The strange thing is that when I try to disassemble the SPC700 code, it looks like it is working, since it is grabbing the right bytes and storing them in the right place, but when I look into the SPC700 RAM editor, the BRR data isn't there, as if it disappears the moment it is being written to. If I edit the RAM editor while it's running, the data stays and it plays a sound, though.
Re: BRR streaming code not working for unknown reason
by on (#142234)
Check that you have disabled echo in the FLG register...echo can and willl mangle up to 30KB of memory based on the setting of EDL from address specified in ESA. In most cases, the memory occupied is 2KB * EDL, unless EDL is 0, it only occupies 4 bytes from ESA.

If that's not the problem, good luck finding a solution
Re: BRR streaming code not working for unknown reason
by on (#142241)
I thought I did set up echo the correct way.

Code:
arch snes.smp

str $f0=#$30   //reset_all_ports
str $f2=#$0f
str $f3=#$7f   //FIR filter is all pass
str $f2=#$0c
str $f3=#$7f   //left volume 100%
str $f2=#$1c
str $f3=#$7f   //right volume 100%
str $f2=#$2c
str $f3=#$00   //echo volume 0%
str $f2=#$3c
str $f3=#$00   //echo volume 0%
str $f2=#$6c
str $f3=#$00
str $f2=#$0d
str $f3=#$00   //feedback 0%
str $f2=#$4d
str $f3=#$00   //no channel with echo
str $f2=#$5d
str $f3=#$80   //directory
str $f2=#$6d
str $f3=#$ff   //echo buffer
str $f2=#$7d
str $f3=#$00   //shortest delay possible

str $f2=#$00
str $f3=#$7f   //channel 0 left volume
str $f2=#$01
str $f3=#$7f   //channel 0 right volume
str $f2=#$02
str $f3=#$00
str $f2=#$03
str $f3=#$10   //original pitch
str $f2=#$04
str $f3=#$00
str $f2=#$07
str $f3=#$7f   //gain up

str $f2=#$4c
str $f3=#$01   //key on


ldx #$00
-;
cpx $f6
bne -
lda $f4
sta $c000,x
stx $f6
inx
cpx #$99
bne -
ldx #$00
bra -




seek($608000)
directory:
dw $c000
dw $c000

seek($60c090)
db $03
Re: BRR streaming code not working for unknown reason
by on (#142242)
since your using a tool that doesn't use native SPC700 I can't even comment lol..

but you're not actually setting the FLG, in your case use it to unmute all the channels and disable echo..
in your case you set echo region to 0xFF00 so there's likely 4 bytes occupied there from echo region, that has nothing to do with your problem but it's important to know so u never get bugs from echo buffer using your RAM OK.

Good luck
Re: BRR streaming code not working for unknown reason
by on (#142459)
It seems to me that if $2142 is already zero when the S-CPU loop starts, it will falsely assume the data index has been echoed and might increment $F6 before the S-SMP has a chance to check it, preventing the APU from getting any data and locking up both loops.

...no?
Re: BRR streaming code not working for unknown reason
by on (#142642)
Getting rid of this code solves the problem for some reason. Now I can actually get this Bad Apple demo finished.
Code:
str $f0=#$30
Re: BRR streaming code not working for unknown reason
by on (#142651)
psycopathicteen wrote:
Getting rid of this code solves the problem for some reason. Now I can actually get this Bad Apple demo finished.
Code:
str $f0=#$30


that's because it should've been $f1 for Port Control -- instead $f0 is a test register u must have activated some funky test shit
Re: BRR streaming code not working for unknown reason
by on (#142657)
I can determine exactly what went wrong now that I realize where the bug was.

What you wrote to $F0 resulted in the following instead of your intended effect...

- RAM Writes were disabled (this is why you ran into your bug in which nothing was being written)
- Timers don't work
- Waitstates on RAM access were set to 9 cycles by mistake (normally this would be zero)