News:

11 March 2016 - Forum Rules

Main Menu

65815 BIT immediate

Started by sleepydude, February 24, 2015, 10:48:39 AM

Previous topic - Next topic

sleepydude

Hello, new to the board. Just as a pet project I'm trying to write an SNES emulator in Javascript to run in the browser. Not sure if it's going to work or not, but ehh, it's fun.

Anyway, I'm trying to emulate the opcodes at the moment, going off of this doc:

http://wiki.superfamicom.org/snes/show/65816+Reference#fn:2

For the BIT operation in Immediate mode it says it only uses 2 bytes, but I'm wondering if this is true when the Accumulator is in 16 bit mode as well? Wouldn't you need 3 bytes for that?

STARWIN

Yes. You can check bsnes and snes9x source code for reference for these kinds of questions.

sleepydude


chillyfeez

#3
FYI, that document has some inaccuracies.
For one, it confuses the meanings of BCC and BCS.
I think I've also heard that it totally screws up the parameter usage of MVN and MVP too (but I've never used those ops in my coding, so I can't confirm).
:edit:
Looked at it some more... It gets ROL and ROR wrong too. These two ops use the carry flag in addition to the 16 bits indicated by the parameter (as an effective 17th bit).
Ongoing project: "Final Fantasy IV: A Threat From Within"

Latest Demo

KingMike

Also with MVN/MVP, it only quits when it underflows, so A = 5 actually means to transfer 6 bytes.
"My watch says 30 chickens" Google, 2018

furrykef

#5
So why didn't you guys correct the problems in the text instead of allowing them to persist? It is a wiki.

EDIT: I have made the above corrections. Did you guys see any other mistakes?

zhade

Just to make it clear, all instructions in immediate mode that work on A can take one more byte if the M flag is clear right ? and the same for X/Y and the X flag ? If so it would be nice to have the instructions table in the document appear as they are named in the adressing mode table so that for example for BIT it would be written "ImmediateMemoryFlag" instead of just "Immediate" or maybe "Immediate (M)" the bytes column could also show "3/4" instead of just 3 to make things perfectly clear. Also, these are the only case where the instructions can take more bytes right ? If it is the case and you think its a good idea, I could make the changes.

Disch

QuoteJust to make it clear, all instructions in immediate mode that work on A can take one more byte if the M flag is clear right ? and the same for X/Y and the X flag ?

Yes.

QuoteIf so it would be nice to have the instructions table in the document appear as they are named in the adressing mode table so that for example for BIT it would be written "ImmediateMemoryFlag" instead of just "Immediate" or maybe "Immediate (M)" the bytes column could also show "3/4" instead of just 3 to make things perfectly clear.

It would be.  I guess they figure it's implied because that's what the M flag does.  But yeah I agree it should be clarified in ref docs.

QuoteAlso, these are the only case where the instructions can take more bytes right ?

Every immediate mode instruction can be 2 or 3 bytes large depending on M/X flags.  The only exceptions are SEP/REP which are always 2 bytes  (and I guess BRK/COP if you count those -- but most docs list those as implied mode).

Non-immediate mode instructions are always fixed size.  Though they may behave differently depending on M/X flags.

It's worth noting that the M/X flags have other implications besides just the size of the instruction.  M, for example, effects how many bytes are written to memory on STZ.  And M/X change how many bytes are pushed on PHA/PHX/PHY.  Etc.