nesdev.org

I just ran my minimal program without the while loop but with a return statement. The logger then constantly prints "brk #$00" and "rti" so I think it's doing nothing anymore. There has to be some other fault in my game that I need to sort out later then.

The data at 0x10000 is completely empty in the SMC. However the data from 0xC000 to 0xC080 in the SMC are the same as 0x10100 to 0x10180 in the SPC. Do the values in loadspc.asm have something to do with the definitions in the header.asm that contains the SNES header? Is there any place to read about these ROM bank things so I get a clue what I'm doing?

In the memory editor I can only select "S-APU bus" but I think that is what you meant.

I just ran my minimal program without the while loop but with a return statement. The logger then constantly prints "brk #$00" and "rti" so I think it's doing nothing anymore. There has to be some other fault in my game that I need to sort out later then.

Which implies that it reached the return-statement and returned to some area that doesn't contain any meaningful code/data.

The defines in loadspc.asm are related to parts of the header.. like the slot size, the rom bank size, the number of rom banks, and the memory mapping type (lorom/hirom).

I've tried compiling the program with the header.asm from your spc player. I had to add to .MEMORYMAP otherwise the SDKs WLA complains about not defined slots. But there's still only zeros at address 0x10000 in the SMC file. Am I still missing something or might that be a fault of the SDKs WLA (which is a modified WLA)?
edit: WLALINK seems to always use 8 rom banks as it prints the message "OBTAIN_ROMBANKS: Using the biggest selected amount of ROM banks ( 8 )." when linking.

There should only be one slot per bank. I don't see why it should complain about slot 1-3 not being defined when they're not being used (at least not in my code).

I think I've got WLA-DX 9.4 on this computer, but I've got 9.5something on another computer. Both of them are working for me with my code. I haven't tried the version of WLA-DX that comes with SNESC.

Yehawww it works
I think after the code change you proposed it was my fault that it didn't work. The wlalink in the SDK has the additional option of discarding unnecessary data that isn't used. This option was enabled and removed the included SPC from the bank 2 and 3. I saw that already some hours ago, but I didn't realize that an error popped up while linking and I didn't notice my batch file didn't create a new SMC as the old one was still there and so I thought that was the wrong way. But disabling this option and removing some "EmptyHandler" stuff from the header.asm made the linking work. So now I have music playing in my SNES app
Thanks for your support all day long!

Now let's come back to that SPC commands while it already plays music...

Darn. I tried scanning a Super Mario World and a Chrono Trigger SPC, using a program that tried every byte value on each of the four ports, checking to see if any caused the SPC to re-run the IPL ROM. None did. So it seems that each SPC driver will need to be manually examined to determine what, if any, command can be sent to tell it to re-run the IPL ROM. Many games probably lack this, as the IPL ROM uses a slow transfer mechanism. An optimized one speeds up song changing in-game. If someone is manually looking for this, they could probably just add a command to do so if it's not there.

I'm wondering whether the PowerPak has some kind hack to reset the SPC-700, or requires pressing the reset button when changing songs.

I'm wondering whether the PowerPak has some kind hack to reset the SPC-700, or requires pressing the reset button when changing songs.

The former. I don't know if it can reset just the SPC700 or if it resets the entire system, but it goes back to the PowerPak logo screen when you press Start, and then you can start playing another SPC.

From what I understood so far you have to program the SPC file (which is a program) to not just play a song but also listen on several ports in order to know that it has to do something if there is data on one of them. In loadspc.asm there are two sections that I think are SPC codes, namely spc700_init_code and spc700_fasl_code. So you'd have to extend them so they listen to changes on the four ports?
How would a custom loader look like? Wouldn't it use a similar way since otherwise control over the SPC700 ist lost?

blargg wrote:Darn. I tried scanning a Super Mario World and a Chrono Trigger SPC, using a program that tried every byte value on each of the four ports, checking to see if any caused the SPC to re-run the IPL ROM. None did. So it seems that each SPC driver will need to be manually examined to determine what, if any, command can be sent to tell it to re-run the IPL ROM. Many games probably lack this, as the IPL ROM uses a slow transfer mechanism. An optimized one speeds up song changing in-game. If someone is manually looking for this, they could probably just add a command to do so if it's not there.

I'm wondering whether the PowerPak has some kind hack to reset the SPC-700, or requires pressing the reset button when changing songs.

In some cases, you may have to reverse engineer the song upload protocols for the game in question, and upload an IPL rom enabling procedure specific to that games spc driver.

In the case of super mario world, Its song uploader is 99% the same code as IPL. the 1% difference is that upon getting a 0 on port 1, with an increment of at least 2/3 on port 0, it jumps back into its own main routine. However, the trick is to overwrite some code with the fake IPL loader instead. In this case, to Address 0x1338, upload the following data bytes. 0xCD, 0x80, 0xC9, 0xF1, 0x00, 0x3F, 0xC0, 0xFF, then set port 1 to 0, and increment port 0 by 2. This regains you full control of the APU, for this driver. To start the upload procedure, write 0xFF to port 1, wait for 0xAABB on port 0.

Finally, some games, like blazeon, don 't have any new data upload procedures at all, as All of the songs needed by the game are already part of the APU ram. In that case, you have to manually patch in some code before uploading the spc, otherwise, no amount of port manipulation will get you back to IPL.

In loadspc.asm there are two sections that I think are SPC codes, namely spc700_init_code and spc700_fasl_code. So you'd have to extend them so they listen to changes on the four ports?

Those are only used during the uploading process. spc700_fasl_code is overwritten when spc700_init_code executes, and spc700_init_code is (in most cases) overwritten once the song starts playing.