instruction logic reference?

raejae · Post by **raejae** » Fri Oct 03, 2008 5:43 am

Hello all...

A couple of weeks ago I was browsing around at some sites with 6502 instruction information. I remember very vividly visiting a site that had each instruction, all of the opcodes and (here's the important part) a list of the logic steps for each instruction. I failed to bookmark the site, and now I can't seem to find it again! I remember it having a black background as well as a lot of green, blue, and red in the tables.

Does anybody know the site that I'm talking of? Thanks in advance...

GARTHWILSON · Post by **GARTHWILSON** » Fri Oct 03, 2008 9:21 am

I don't know about one with colors, but WDC's data sheets [Edit: used to] tell you what happens in every cycle of every instruction. You can download it from their site at http://www.westerndesigncenter.com/wdc/ ... 65c02s.pdf . Their excellent programming manual is at http://65xx.com/Products/Programming_an ... e-Manuals/

raejae · Post by **raejae** » Fri Oct 03, 2008 12:57 pm

I got home and thankfully the history on my other computer went back far enough for me to find it... for anybody that might be interested it is here:

http://homepage.ntlworld.com/cyborgsyst ... 2/6502.htm

And thanks for the links, Garth, much appreciated.

GARTHWILSON · Post by **GARTHWILSON** » Fri Oct 03, 2008 3:31 pm

Wow, someone worked hard on that. Still, I would recommend WDC's manuals. The Cyborg page has quite a few inaccuracies, and only covers the NMOS 6502, not the CMOS 6502 which has more instructions and addressing modes and corrected all the bugs of the NMOS one. The instruction set look-up table is only filled in for the first two lines too, and was never finished.

The WDC programming manual covers not only the CMOS 6502, but also the 65816 which has a ton of capabilities the 6502 does not have. It may look daunting at first, but it truly makes a lot of programming situations a lot easier to handle. And contrary to popular belief, the hardware does not have to be any more complicated than that of the 6502 either.

[Edit: I have posted an article telling all the many differences I can think of between the NMOS 6502 and the CMOS 65c02, at http://wilsonminesco.com/NMOS-CMOSdif/ .]

leegoukko · Post by **leegoukko** » Sat Oct 04, 2008 10:18 pm

I find this document very informative about internal working of the 6502.
http://www.zimmers.net/anonftp/pub/cbm/ ... data/64doc

Actually, used it as a basis and motivation when i designed my own 8-bitter.

cs.BlueChip · Post by **cs.BlueChip** » Wed Jan 07, 2009 12:08 pm

Garth Wilson,

I am responsible for the Cyborg 6502 page.

It was written mainly to force me to memorise 6502 for hacking a "Doctor v64".

I have no great enthusiasm for updating it to document the NMOS chip, unless it can be done in a couple of hours.

BUT

You mention "inaccuracies" ...bad-information is worse than no-information ...if you/others can/will highlight to me any mistakes on my page, they WILL be corrected!

BC

GARTHWILSON · Post by **GARTHWILSON** » Thu Jan 08, 2009 12:04 am

Welcome to the forum! I wish we could get everyone who has an interest in the 65 family to sign up and check back regularly.

Quote:

I have no great enthusiasm for updating it to document the NMOS chip

What you have is NMOS. The CMOS one came out in 1983 about 8 years (IIRC) after the NMOS one. The CMOS one has more instructions, more addressing modes, and all the bugs are fixed. It has a few other hardware enhancements too besides just taking a lot less power. The clock can be stopped, it has an onboard clock oscillator, and much higher clock speeds are available (all of them made today will do at least 14MHz, and I've heard of it going over 200MHz inside custom ICs). Its RST pin is a Schmitt-trigger input so you can just use and RC on it, the RST can be held down indefinitely without problems, and the ones made today have extra signal I/O, including a memory-lock (ML\) output (pin 5 on the DIP), a bus-enable (BE) input (pin 36 on the DIP) with weak internal pull-up resistor, and a vector-pull (VP\) output (pin 1 on the DIP).

[Edit: I have posted an article telling all the many differences I can think of between the NMOS 6502 and the CMOS 65c02, at http://wilsonminesco.com/NMOS-CMOSdif/ .]

As for inaccuracies, I must have just happened to look at the right part to see them before; but I don't see any with a quick look right now, and the page has so much information that it would take a long time to go through it with a fine-tooth comb to find them again. Can you at least finish the op code table near the top? Only the first two rows (out of 16 rows) have op codes and addressing modes, and the rest say:

XXX
mm

showing the capital X's where the mnemonic shoud be and lower-case m's where the addressing mode should be. After the first four rows, there are no byte counts or cycle counts either.

Thowllly · Post by **Thowllly** » Thu Jan 08, 2009 12:57 am

cs.BlueChip wrote:

if you/others can/will highlight to me any mistakes on my page, they WILL be corrected!

Not exactly mistakes, just thought I'd mention....

"oVerflow Flag (P.V)"
-Third use: Sticky input bit. Connected to the SO pin.

"What is an Interrupt?"
-Strictly speaking, it's the voltage itself that signals an IRQ, not a change in voltage. For NMI on the other hand, it IS a change in voltage that signals an interrupt.

"How can I disable Non-Maskable Interrupts?"
-By not acknowledging a NMI you'll effectively mask further NMIs

"How can I simulate an Interrupt."
-Personally I think it's much simpler to just consider BRK to be a 2 byte opcode (add an extra byte after every BRK) than doing return address correction in the IRQ handler.

I think that should be about right, but any corrections to this post are welcome!

kc5tja · Post by **kc5tja** » Thu Jan 08, 2009 1:44 am

Quote:

"How can I disable Non-Maskable Interrupts?"
-By not acknowledging a NMI you'll effectively mask further NMIs

This is actually false; the CPU will happily attempt to handle another NMI if the interrupt pin is strobed. "Acknowledging" the NMI is implicit within the CPU.

External logic is necessary to force the NMI pin into a negated state. With VIA or CIA chips, this can be accomplished by not resetting the interrupt enable flag.

Since not all hardware possesses an interrupt enable bit, it follows that the approach taken with a VIA or CIA chip necessarily is specific to those chips. The only sure-fire way to "disable" an NMI are as follows:

* external logic which, when enabled, forces the NMI pin high.

* Installing a do-nothing NMI handler, which executes an RTI instruction as its only task.

Hope this clarifies things.

Thowllly · Post by **Thowllly** » Thu Jan 08, 2009 3:33 am

kc5tja wrote:

Quote:

"How can I disable Non-Maskable Interrupts?"
-By not acknowledging a NMI you'll effectively mask further NMIs

This is actually false; the CPU will happily attempt to handle another NMI if the interrupt pin is strobed. "Acknowledging" the NMI is implicit within the CPU.

External logic is necessary to force the NMI pin into a negated state. With VIA or CIA chips, this can be accomplished by not resetting the interrupt enable flag.

That was actually what I meant by "not acknowledging". But I worded it very poorly, so thanks for the clarification.

Quote:

Since not all hardware possesses an interrupt enable bit, it follows that the approach taken with a VIA or CIA chip necessarily is specific to those chips. The only sure-fire way to "disable" an NMI are as follows:

* external logic which, when enabled, forces the NMI pin high.

* Installing a do-nothing NMI handler, which executes an RTI instruction as its only task.

Hope this clarifies things.

Didn't think about that, I only recalled what games on the C64 used to do to disable the restore key, didn't consider it might be specific to the hardware used. Thanks

GARTHWILSON · Post by **GARTHWILSON** » Thu Jan 08, 2009 5:44 am

Most I/O ICs will keep pulling the interrupt line down until you do something that changes their status register, even if that only requires reading a register. So if you RTI without doing that, in most cases, there will be no more NMI edges.

cs.BlueChip · Post by **cs.BlueChip** » Sun Jan 18, 2009 7:31 pm

Thowllly wrote:

"oVerflow Flag (P.V)"
-Third use: Sticky input bit. Connected to the SO pin.

As an input or output?
Ie. does the pin effect the register or vice versa?

Thowllly wrote:

"What is an Interrupt?"
-Strictly speaking, it's the voltage itself that signals an IRQ, not a change in voltage. For NMI on the other hand, it IS a change in voltage that signals an interrupt.

corrected

kc5tja wrote:

"How can I disable Non-Maskable Interrupts?"
* external logic which, when enabled, forces the NMI pin high.
* Installing a do-nothing NMI handler, which executes an RTI instruction as its only task.

This page is intended to be a programmers reference.
I'd like to think that any hardware engineer is able to infer that pulling an active-low pin high will stop it working!
"Do nothing" is very much /not/ "disabling"
...However, changes to the page have been made in this area

Thowllly wrote:

"How can I simulate an Interrupt."
-Personally I think it's much simpler to just consider BRK to be a 2 byte opcode (add an extra byte after every BRK) than doing return address correction in the IRQ handler.

Duly noted

GARTHWILSON wrote:

Can you at least finish the op code table near the top?

I'm very aware of the incompleteness of the table at the top ...it's a long horrible boring job for one person (much easier for two people in the same room (one reading, one typing)) ...does anyone else fancy typing all that data in? I guess if the hits on that page stay high for a while, I'd better just knuckle down and do it :/

Thanks for your feedback guys.

BC

Thowllly · Post by **Thowllly** » Wed Jan 21, 2009 7:44 am

cs.BlueChip wrote:

Thowllly wrote:

"oVerflow Flag (P.V)"
-Third use: Sticky input bit. Connected to the SO pin.

As an input or output?
Ie. does the pin effect the register or vice versa?

Input, the pin effect the register. I think it's edge sensitive, but don't remember which edge.

Quote:

kc5tja wrote:

"How can I disable Non-Maskable Interrupts?"
* external logic which, when enabled, forces the NMI pin high.
* Installing a do-nothing NMI handler, which executes an RTI instruction as its only task.

This page is intended to be a programmers reference.
I'd like to think that any hardware engineer is able to infer that pulling an active-low pin high will stop it working!
"Do nothing" is very much /not/ "disabling"
...However, changes to the page have been made in this area

I don't think you should try to actively pull the pin high, if you have any HW that might try to activey pull it low. Instead you should actively pull it low and not release it, so that if anything else tries to pull it low, nothing will happen.

kc5tja · Post by **kc5tja** » Wed Jan 21, 2009 2:36 pm

Quote:

I don't think you should try to actively pull the pin high, if you have any HW that might try to activey pull it low. Instead you should actively pull it low and not release it, so that if anything else tries to pull it low, nothing will happen.

Who said anything at all about shorting the pin high? I certainly never said that. Use an OR-gate instead. You eliminate the abject necessity for "interrupt disablable" hardware or sluggish open-drain parts. This comes in particularly handy if you expose the NMI signal to your expansion slot(s), where the designer of the system simply has no control what-so-ever over what hardware appears in the slots.

Code: Select all

          +-----+
          |     |---o  _ENABLE
_NMI <----| >=1 |
          |     |---o  _NMI_P
          +-----+

Assuming _NMI_P is the peripheral's view of the _NMI signal, then when _ENABLE is low, _NMI = _NMI_P (after propegation delay of course). When _ENABLE is high, however, _NMI is high at all times.

Thowllly · Post by **Thowllly** » Thu Jan 22, 2009 6:57 am

kc5tja wrote:

Who said anything at all about shorting the pin high? I certainly never said that.

Sorry, didn't mean to imply that you suggested shortening the pin high, I was still thinking in the context of what I wrote earlier. If you just pull it low with existing HW you don't need an extra or gate to disable further NMIs. But of course, if you want a more advanced higher speed system, yours is the way to go.

But I feel this is drifting oftopic, I just mentioned disabling NMIs in my original post because on old, existing HW, like the c64, it was possible to disable NMIs, even though it didn't look like it has been designed with that in mind. But if you actually add hardware to disable NMIs, then of course it is possible to disable NMIs.