SPC: binary storage of multiple operands

SPC: binary storage of multiple operands
by Disch on 2007-04-05 (#22897)

I've been using Anomie's spc700.txt that I got from romhacking.net (I would give a more direct link, but the site seems to be down now). Inside the doc it says:

Quote:

Operands are encoded little endian, with multiple operands stored last to first. For example, "OP A, B" is stored in memory as "OP B A". Mnemonics are represented as "OP dest, src" where applicable.

This is the only part in the doc which makes any mention of how multiple operands are stored. And while this appears to be true for direct page->direct page instructions (MOV $xx, $xx and similar)... I just spent the last hour debugging my SPC emu only to find that it's NOT true for CBNE (which has the direct page address stored first)

I began looking at other docs to see if they address the issue, only to find that none of them (at least none of the ones I have) even touch on this subject.

So my question is... how are multiple operands REALLY stored? If CBNE contradicted Anomie's doc.. I suspect other instructions do too (DBNZ is suspect, as are maybe BBC/BBS)... but I don't want to have to pick and guess. Can anyone give me a definative answer?

Thanks

by blargg on 2007-04-05 (#22899)

I'll chastise anomie in an e-mail for you, since that is blatantly wrong. I think you've covered the cases of two non-implied operands. Think of the order they're needed by the instruction, where the source is always fetched before the destination in a RMW instruction (so since dest is listed first, you get opposite order for the dp,ds addressing mode).

I looked and the much updated DSP doc isn't up yet (apudsp.txt). I'll have to find out what the holdup is, as should have a ton more timing information.

So, you're writing an SPC emulator. I better start posting my validation tests tomorrow; I've got tons. :)

by Disch on 2007-04-06 (#22954)

blargg wrote:
Think of the order they're needed by the instruction,

Makes sense. That explains CBNE -- can't branch unless you first compare the target address. I switched DBNZ, BBC, and BBS around as well, and everything seems to be working now. Now if I can only track down this elusive 65c816 bug! >=o

Quote:
Here's a URL to the most up-to-date spc700 doc that I know of (change the filename for the other docs):

Sweet -- thanks. ^^

Quote:
So, you're writing an SPC emulator. I better start posting my validation tests tomorrow; I've got tons. :)

I started a SNES emu as sort of an educational project. I'm just having so much fun ^^.

I am very interested in any test ROMs you might have. Those are invaluable! Especially anything involving the CPU -- as that's the hardest to track down bugs in.

by blargg on 2007-04-06 (#22955)

What form would work best for tests? I can generate any of these three easily: raw data that you put directly into the SPC memory space then execute, an SPC music file, or an SMC SNES ROM. The first two do text console I/O via the four I/O registers using a simple protocol. The SMC does this internally and provides a SNES-side driver that displays the text on screen and encodes it into serial data over one of the controller I/O lines, which you can decode using my handy Blargg_Serial emulator. You can run the SMC in a normal emulator.

If it's any help I can also post my SPC emulator code, whose DSP is written in a clear style.

by Disch on 2007-04-06 (#22958)

An SMC would be easiest for me since I wouldn't have to write a seperate loader.

Emu source wouldn't be all that useful to me -- at least not right now. I already have the SPC mostly done except for the DSP (which I don't have much interest in at this point -- I'd like to get games running before I worry about audio).

Thanks blargg ^^

I don't suppose you have or know of a main SNES CPU test ROM? Something like nestest would be bliss. Wishful thinking, I know, but no harm in asking ;D

by creaothceann on 2007-04-11 (#23105)

Disch wrote:
I'd like to get games running before I worry about audio

Won't many games hang waiting for the APU to respond?

by tepples on 2007-04-11 (#23107)

creaothceann wrote:
Disch wrote:
I'd like to get games running before I worry about audio

Won't many games hang waiting for the APU to respond?

A lot of games don't block on the APU; they block on the PPU.

by Disch on 2007-04-11 (#23109)

creaothceann wrote:
Disch wrote:
I'd like to get games running before I worry about audio

Won't many games hang waiting for the APU to respond?

A lot will hang if the SPC doesn't respond, yes. However the SPC can still respond if you're not generating audio.

by blargg on 2007-04-11 (#23114)

Disch has implemented the S-SMP (the CPU inside the APU) but not the S-DSP. Probably only a few games will hang without a DSP, as most don't read anything back from it, only write to it.

by creaothceann on 2007-04-11 (#23115)

I see. Thanks.