Talk:Namco 163 audio

Point of terminology: Namco 106 vs. Namco 163

A regular on another wiki, who might not qualify for trusted on wiki.nesdev.org because he isn't active on the BBS, sent me a message on my talk page at that wiki that Namco 106 audio might need a rename. --Tepples 14:52, 15 December 2010 (UTC)

Mechanism

Is the cycle-by-cycle behavior known? I can guess it's something like "ld_7f ld_8 add_9 st_9 ld_a add_b st_b ld+mask_c add_d bound_c st_d add_e ld_indirect mult_f st_dac"—Lidnariq (talk) 13:41, 11 February 2013 (MST)

I think that would require a decap; it would be hard to determine this externally. The pseudocode I put as an example seems to give very accurate results though. - Rainwarrior (talk) 14:16, 11 February 2013 (MST)

Should be able to figure out which cycle 9, b, and d are updated. But otherwise, yeah.—Lidnariq (talk) 14:45, 11 February 2013 (MST)

How do you intend to do that? They're write-only registers. You can sort of read them by setting the waveform position to sit on the registers and recording the audio out (this is how the contents were determined), but the output only changes every 15 cycles, so there's no way I can think of to see anything getting updated at a finer granularity than that. - Rainwarrior (talk) 02:05, 12 February 2013 (MST)

The same way blargg's tests test the timing of write-only PPU registers: very precisely timed writes. --Tepples (talk) 09:50, 12 February 2013 (MST)

Hmm, so you're saying to devise a test for each of the control bytes, to be executed at each of the 15 cycle alignments, and then deduce from the signal collected what happened in each of these tests? I suppose you could mark your starting alignment with a $4011 write as well. Anyhow... I can see how it would be possible in theory. The real question I suppose is whether anyone will do it? - Rainwarrior (talk) 11:31, 12 February 2013 (MST)