Talk:Super NES Programming/Loading SPC700 programs

I may have made some mistakes when translating the IPL ROM code to an algorithm. In particular, I'm not sure that the cmp instruction on the SPC700 is doing what I think it should do. I believe that a sequence like:

cmp y,$f4

should compute (y - the contents of $f4) and set the N flag if the result is negative. This instruction sequence is used to compare the SPC's counter (in y) with the counter value sent by the SNES (in $f4) to check for the end of a block. Thus, when I send a counter value to terminate the block the SNES is sending, I expect I can send $ff, which is greater than or equal to any value the SPC counter is holding, which therefore should terminate the block, if the SPC follows the algorithm I have outlined in the tutorial. Instead, when tracing with Geiger's Snes9x debugger, I am seeing the SPC compare y (containing a low number) with address $f4, which seems to contain $ff, and it is not setting the N flag. Thus, sending $ff causes the program to lock up. But, for some reason, adding a small (< $80) value to the counter works, even though this should cause the counter to roll over in some cases, which should make the N flag unpredictable. If anyone could help clarify what is going on, I'd be grateful.

Joe Lee 14:40, 3 Jun 2005 (UTC)


 * The cmp does compute y-($f4), but the N flag is simply copied from bit 7 of the result. So if you want the N flag, you should use a value only slightly bigger than Y, e.g. Y+2. $00 - $02 = $fe = N flag set. $7f - $81 = $fe = N flag set. $ff - $01 = $fe = N flag set. Blargg (discuss • contribs) 04:51, 23 January 2014 (UTC)

needs major rewrite
I have several problems with this page. It is unnecessary long, unorganized, not specific enough, and contradicts itself on several occasions.

First of all the SPC loading routine does not match the SNES loading routine. In the SPC loading routine, it says that the spc700 waits for the 65816 to load $cc into audio0, in the SNES loading routine, the 65816 never loads $cc into audio0, implying that the spc700 would be waiting forever.

Another problem is the artical tells you to do it one way without an explanation of why it works. The SNES loading routine should just say to load this here, load that there, but instead it tells you to do some calculations with a counter that isn't hardware specific. Then it says "there are some problems with this method." If there are problems with this method, why is this method still on here? And why is this artical explaning "methods" when the purpose of hardware documents are to show facts?

-- 20:44, 25 May 2010 75.57.185.158

Thanks for the feedback. The textual description of the SNES loading routine does indeed have an incorrect constant, which is why the routines don't seem to match. Note that the assembly code is correct, however, and does send $cc to audio0.

The "problems with the routine" are not fatal -- as noted in the article, it is used successfully in open-source demos. They are merely problems using the routine in the context of this particular program. Perhaps the phrasing could be improved to make this more clear.

As far as the other feedback, it seems you have misinterpreted the purpose of the page. As it says at the top, this is tutorial, not a hardware reference. The goal is to instruct the reader on how create a program that actually plays something on the SPC, without getting into the details of the DSP, SPC assembly, or advanced SNES/SPC communications. It sounds like you want a page like the one on Wikia that just explains how the IPL ROM works, but of course this by itself will not leave you with a program that makes sound. Note that that page also describes "a counter that isn't hardware specific", because the counter is part of the protocol, and the protocol is effectively part of the hardware, since it is loaded on the SPC automatically on reboot.

I'm not sure what to make of the twin criticisms that the page is too long and that it doesn't explain itself enough, since the length is directly due to the amount of explanation. If you know how to reduce the length while improving the explanation, I'd love to hear more about it.

Joe Lee (talk) 14:01, 6 January 2011 (UTC)

Error Message
An "unknown symbol" message appeared when I compile the ROM, could you rewrite it? --LucianoTheWindowsFan (discuss • contribs) 23:49, 12 July 2020 (UTC)