Ideally, yes. Yet, as you say, they also could've directly muxed the IRQ line onto the databus in the break flag position. Regarding those options, it's possible the NMOS and CMOS 02's are in different camps. This bug-fix note from the 'c02 datasheet seems to imply that. But right now I haven't got my thinking cap on, and hesitate to say for certain. Anyway I'm guessing Emulation mode doesn't reproduce the bug.



Yes, that was my main point. I may've been slightly sloppy in expressing it.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Actually, the 65C816's emulation mode is not 100 percent compatible with either the NMOS 6502 or the 65C02. The "caveats" section in the '816 data sheet (page 51) explains the differences.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So here's the next problem. The MVN and MVP instructions (p. 367/368) state that C (as I have come to think of it by now) is $FFFF after the instruction has terminated. It also says that the move instructions do not affect any flag. Shouldn't I end up with N being set, or is that test really skipped? Thanks!

I believe no flags are set. It shows no flags being set on pg 36 of the datasheet, so I wouldn't count on them being set. It might be nice to have flags set based on the last byte/word moved. It likely has to do with keeping the processor pipelining simple.

_________________
http://www.finitron.ca

MVN and MVP affect no flags whatsoever. However, DB is left pointing at the destination data bank. Hence I usually surround an MVx instruction with PHB and PLB.

As an aside, it should be noted that both of these instructions can be interrupted during execution.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ah, that's a good tip. Maybe it should be in the 65816 tricks thread as well?

I thought that I posted it. I'll have to check.

EDIT: I did mention it in a post about MVN and MVP.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Apols, can't believe I missed that. Thanks!

It's time for me to be a man, quit hiding behind my desk chair, and face the horrors of bank and page wrapping. With the help of Bruce's great 65816 opcode tutorial (http://6502.org/tutorials/65c816opcodes.html) and Programming the 65816, I think I have condensed the logic of it all down to these pseudocode rules, organized by the addressing modes, since that is how I will be coding them.

First, Direct Page Addressing:Then, Stack Addressing: That seems straightforward, thought it took me hours to understand it. We have two more cases of wrapping at bank 0:The important part about Absolute Indrect Long is that the resulting effective address is 24 bit again, that is, we pull the Bank Byte, too.
Next, three cases of wrapping at the Program Bank Register (PBR): Last, we have instructions that use the Data Bank Register (DBR) and are not Direct Page or Stack addressing. This is pretty much only: which means MVN and MVP.

The last case hides an important rule: All X and X indexed absolute and long addressing modes that deal with the DBR extend into the next bank. Even more supremely important: This is true for Emulation Mode as well, an real, hard-core difference to the real 6502/65C02. The horror, the horror.

Or at least this is how I understand it. I'd be grateful if anybody sees something I might have missed?

EDIT: Corrected error in Direct Mode, must be DL instead of DH.
EDIT: DP and S mode always wrap on bank boundry, not only if we're not wrapping on page

You have emulation-mode Direct Page wrapping depending on DH rather than on DL... you might be right but Bruce says not!
(Related discussion at viewtopic.php?p=40853#p40853)

Ahhh, I think I know what the problem is: I'm different-endian here. . Let's put this differently: The MSB of D is zero, so D is on "zero page", and the LSB is the one that is changed, right?

I'm afraid you've lost me! D is the direct page register, and on the 816 it's two bytes. Bruce calls them DH and DL for the high and the low byte respectively. DH is something that's been seen in some 6502 variations but DL is new, I think. DL allows you to have a non-page-aligned direct page.

In your pseudocode, you're assuming that it's a Direct Page mapped exactly on Zero Page which is the special case. But Bruce's document says that the special case is a page-aligned Direct Page (which includes the case of placing it exactly on zero page.) Bruce has an example of D=FF00, which is page-aligned but not on zero page. By placing a pointer's low byte at FFFF, he can demonstrate the page wrapping: the high byte is fetched at FF00.

Now I've got it. Yes, you (and Bruce) are right, I let myself get confused by the paragraph on p. 283 of Programming the 65816, where methinks the paragraph could be clearer: Will correct, thank you!

I've changed the entries for DP and S a bit: Even if we wrap on a page, we also wrap on bank 0. Of course this is a bit silly, because if you wrap on a page, you never are in danger of wrapping the bank (if you never leave your city, you'll never leave your country). But I find this helps with the logic.

Sanity prevails! The "new" DP indexed instructions, that is, those that never ever have page wrapping because they are not found on the 65c02, all seem to have the LSB of the opcode set to 7. Of course, I only noticed this after putting together a nice arrary: I guess that is my useless typing exercise for today. Now we don't have to look through the table, just mask the MSB of the opcode and compare the rest to seven. Clever engineers!

EDIT: I should clarify: Obviously the .dil (direct page indirect long) instructions don't wrap, but we can include them in this word, because they will not call this routine and so are "don't cares".