65C02 instruction timings

[hoglet]

Returning to the original topic...

NollKollTroll, I have a few further suggestions:

1. NOPs

There are several different NOP opcodes that have differing instruction lengths and cycle counts.

These are summarised here:
http://6502.org/tutorials/65c02opcodes.html#8

It would be good to include these in your document, as they form part of the defined behaviour.

2. Manufacturer specific variations

Even if your document is specific to the W65C02, it might be helpful to indicate which instructions are:
- Rockwell and WDC additions (BBR, BBS, RMB, SMB)
- WDC only additions (STP and WAI)

The CMS/GTE G65SC02 doesn't implement either of these groupings. Neither does the NCR 65C02.

3. Register Naming

There was some debate eariler about register naming.

I've very much with Ed on this:
- use S for the Stack Pointer (as in TXS and TSX)
- use P for the Process Status Register (as in PHP and PLP)

Western Design Centre would seem to agree with this:

I'll certainly be using your document as a handy reference.

Dave

[GARTHWILSON]

hoglet wrote:

Returning to the original topic...

NollKollTroll, I have a few further suggestions:

1. NOPs

There are several different NOP opcodes that have differing instruction lengths and cycle counts.

These are summarised here:
http://6502.org/tutorials/65c02opcodes.html#8

It would be good to include these in your document, as they form part of the defined behaviour.

Good point. Jeff Laughton has made extensive use of these, and has a handy table at viewtopic.php?p=36187#p36187 which I incorporated (with his permission) near the end of the article on the differences between CMOS and NMOS 6502's at http://wilsonminesco.com/NMOS-CMOSdif/ . He also pointed out that in self-modifying code, you can increment or decrement an op code to a neighboring one with the desired behavior for the situation, which is included about 70% of the way down the page in the article on self-modifying code at http://wilsonminesco.com/SelfModCode/ . Search for the "incrementing or decrementing an op code" bullet point.

[nollkolltroll]

I've updated the doc:
- Use SP for Stack Pointer, SR for Status Register.
- Changed the wording on BIT.
- Changed to a compact text-document, 78 chars wide.

A text document was what I really wanted in the end, but it was so much simpler to edit text in a spreadsheet. If anyone wants a pdf or the spreadsheet, tell me.

I will not insert comments on variants from other manufacturers. I really want to keep this a simple doc with less chance to misinterpret anything. I think it would be better to make separate documents with info pertaining to other CPUs.

EDIT: latest version available at first post

[BigDumbDinosaur]

nollkolltroll wrote:

I've updated the doc:
- Use SP for Stack Pointer, SR for Status Register.
- Changed the wording on BIT.
- Changed to a compact text-document, 78 chars wide.

A text document was what I really wanted in the end, but it was so much simpler to edit text in a spreadsheet. If anyone wants a pdf or the spreadsheet, tell me.

I will not insert comments on variants from other manufacturers. I really want to keep this a simple doc with less chance to misinterpret anything. I think it would be better to make separate documents with info pertaining to other CPUs.

Code: Select all

------------------------------------------------------------------------------
BRA                                  addressing syntax       op b cyc NV*BDIZC
Branch always                        imp        BRA $12      80 2 3   --------
------------------------------------------------------------------------------
BRA                                  addressing syntax       op b cyc NV*BDIZC
Break                                rel        BRK          00 1 7   ---101--
Interrupt, push PC+2, push SR
------------------------------------------------------------------------------

The second one should be BRK instead of BRA. Formally, BRK is a software interrupt that takes an 8-bit operand (the "signature"), like SWI in the MC6800 or INT in x86. Most assemblers do not enforce the signature, but technically it should be there. Although BRK is most often for debugging purposes, the instruction can also be used to call an operating system API (e.g., BRK $21 to call routine $21 in the API)—or in a historical role, to patch PROMs when a bug is discovered.

Also, it should be noted that the B(reak) bit's state exists only in the stack copy of SR, not in SR itself. Doing PHP - PLA - AND #%00010000 in the IRQ handler will not work as expected. This is why IRQ handlers will push registers and then "sniff" the stack to determine if the interrupt was hard or soft.

Code: Select all

------------------------------------------------------------------------------
DEA                                  addressing syntax       op b cyc NV*BDIZC
Decrement accumulator by one         imp        DEA          3A 1 2   +-----+-
A - 1 -> A
------------------------------------------------------------------------------
INA                                  addressing syntax       op b cyc NV*BDIZC
Increment accumulator by one         imp        INA          1A 1 2   +-----+-
A + 1 -> A
------------------------------------------------------------------------------

DEA is a non-standard alias for what is formally DEC A, the A meaning the accumulator. Similarly, INA is non-standard for INC A. In MOS Technology/WDC assembly language standard syntax, instructions that can operate on the accumulator or memory use this distinction (the reason is historical and has to do with parsing the operand field). However, many assemblers don't require it, in which case DEC or INC is used without an operand to tell the assembler it is the accumulator that is being decremented or incremented.

Regarding the Rockwell extensions BBR, BBS, RMB and SMB, there has been historical disagreement on the correct assembly language syntax for them. The 65C02 assemblers I have used treat the bit number as one of three fields of the operand, not part of the mnemonic. For example, BBR0 $12,$34 would be written as BBR 0,$12,$34. The primary reason for doing so is the first method makes the mnemonic a non-standard four characters, which means the assembler's parser has to treat the mnemonic field specially by checking for a fourth character and processing it as though it is an operand. In contrast, the second method doesn't require the assembler to do anything special with the mnemonic field, other than look it up in a table to determine what the instruction is. With the bit number being an operand field, parsing, checking and assembling is much simpler.

[Dr Jefyll]

GARTHWILSON wrote:

Jeff Laughton has made extensive use of these [different NOP opcodes], and has a handy table at viewtopic.php?p=36187#p36187

Yes, some of these can certainly be useful. A one-byte, one-cycle NOP is great when you need to pad execution time to an exact number of cycles. And the 2- and 3-byte NOP's are a good choice for the well-known trick that saves memory by replacing a BRA which skips forward by only 1 or 2 bytes. That's explained in the same post. Traditionally, folks have used BIT or CMP for this, but using these NOP's instead means the flags won't get altered.

The stuff about incrementing or decrementing an op code is admittedly pretty far out, and clearly won't be widely applicable. But Self-Modifying Code is a powerful way to solve some otherwise impossible problems, and it helps to brainstorm lots of different ideas. I would recommend reading Garth's entire article (rather than focusing on this particular tidbit).

BigDumbDinosaur wrote:

WDC says in the data sheet that all memory and I/O accesses should be qualified by VDA and VPA. I'm merely doing what they recommend.

If you say you found the OR-gate route using VDA and VPA to be convenient then I have no quarrel with your choice. As for the WDC recommendation, it strikes me as excessively cautious or just plain carelessly written. What would be the benefit from protecting memory from invalid addresses??! I've tried at length to identify some justification for this (and hence for the OR gate), but what I came up with is awfully tenuous:

• it means IO is enabled during code accesses. But most of us don't wish to fetch code from IO devices.
• it means memory is disabled during dead cycles. But memory usually doesn't require this protection. Are there any exceptions? Certain specialized memory devices have paging features built in, and it may be that access to those features involves a specific "knock" sequence -- accesses to certain addresses as a means to unlock the feature. But AFAIK the knock sequence involves writes, and dead cycles are always reads. Edit: except the one in the Modify cycle of an '02/'816 R-M-W, but as I said these attempted theories do seem awfully tenuous.

BigDumbDinosaur wrote:

I don't believe the prop time of a single OR gate is an issue at any speed at which the 65C816 will be usable.

8 ns for an 'AC32 OR gate will almost double the access time for a system using commonly available 10 ns RAM. No doubt there are situations in which this penalty can be tolerated. But I've explained alternatives to the OR, including a VDA-only solution with zero gates. Engineering is based on identifying, weighing, and choosing between alternatives, in light of prevailing circumstances and priorities (which of course can vary widely). In a new design I'd begin by evaluating VDA-only solutions, and deviate from those only if other factors outweigh the loss of simplicity and timing margin.

-- Jeff

[nollkolltroll]

Thanks for your sharp eyes BDD! I've mixed and matched way too many sources to be sure what way is up
Updated doc with:
- BRA -> BRK
- BBR, BBS, RMB and SMB uses official syntax
- INA, DEA -> INC A, DEC A
New version 0.2.1 available in first post.