sweep problem

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
sweep problem
by Zepper on 2005-03-26 (#1715)
Like Anes :)

While sweep_cutoff works ok (after my papu fix), I cannot get sweep_sub to work properly: it does 1 note, then pitch is decreased and remains for a few more notes, then decreased again and finishes.

Any help? :|

by Anes on 2005-03-28 (#1716)
Maybe you are not updating well the ptimer wevelenght register remember they are two bytes and the byte with the 3 most significant bits of the wavelenght must be updated, but only those 3 bits the other bits remains the same. If you failure to do so, so you will be changing the len counter load register.

Remember to clear the 3 bits with a AND ~0x07 (inverted) of the byte and then OR with the 3 MSB of the new wevelenght. Thats the way a make it and i have an accurate sweep unit.

I had a problem very similar to yours.
If that is not the problem there are no more i can say... :)

One question are you really inverting the value to calculate the "sub" or you have two differents line/s of code to do it?

by Zepper on 2005-03-28 (#1720)
I already double-checked it and it's okay. I don't subtract, but I add the ~number (inversed bits).

by blargg on 2005-03-28 (#1721)
I've been uncovering much more detailed information about APU operation and working on a better set of APU test ROMs for the past few weeks, and will be for a few more. One goal is to breakthe tests into smaller units so problems can be more precisely determined if a test fails. The few tests I wrote recently and posted basically give a pass/fail without much help as to why they failed, so it might be better to wait.

by Zepper on 2005-03-28 (#1722)
Well, any visual output (printed text) would be nice...

by Anes on 2005-03-28 (#1723)
So if you are invertin the bytes, remember they are two, and the second (MSByte) you have to ONLY invert the 3 LSB not invert the two bytes. I mean invert an 11 bit value not a 16 bit value.
Again if that doesnt help i dont know.

Regards.

by blargg on 2005-03-28 (#1724)
Visual output would be quite nice!

In the new tests I'm writing, where possible the result code is shown on screen. The problem is that this is only possible for the length counters and frame IRQ, since those are the only things readable from the APU. Nothing else about the APU state can be determined by the CPU, so I have to find ways of making tiny emulation errors yield large differences in sound output.

It's taken quite a bit of creativity to come up with ways of reporting results in a clear way, and I've recently come up with some better ways than I used in the tests I posted recently. For example the linear counter test ROMs I'm writing today report which of 15 different problems they detect, and for timing, which clock is wrong and whether it's too soon or too late. Again, this new code can't know whether there is a problem; it simply runs sequences on the linear counter that will produce a number of beeps that correspond to which test failed.