6502.org

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

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.

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

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).

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.

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

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.