6502.org

Except the reason I encourage people not using JMP () is not because of the bug, but because using pha/pha/rts is shorter (and in some cases, faster). I would still use JMP () if for some reason this would be the optimal solution, but in all my cases where I had to use jump tables, rts happened to be a more efficient solution.

In the rare cases where using JMP () was actually a possibility, the vector has *always* sat in zero page for me, making this bug irrelevant.

[this message is removed by its author]

Since putting jmp() into use just because, I've found that it fits my application very nicely. I'm kind of upset that I never used it before. I actually have a situation where JMP() even makes more sense than JSR() would. I need to have a JMP as a return. Well, don't need, but it sure simplified things.

In the past, I would have modified a JMP abs. But this works, so I'll do it this way. I don't like to use self modifying code if I can avoid it, anyway.

I'm pretty sure my assembler will fail or at least issue a warning for a boundary vector. I could look to be certain, but I sure seem to remember implementing that. In fact, in a previous incarnation, it would insert an NOP to avoid the situation, I know that for certain. But since I reduced it to two passes, it couldn't be doing that anymore.

If you don't see that I can't help you.
see below
You are right. There are 6 more BASIC vectors $300-$30B. The 13 IO vectors I was referring to are at $314-$32D. $313 is the unused byte. There is 2 more vectors for LOAD and SAVE after that.

This discussion ends for me now. Believe what you want. I don't care.

Indirect threading is a popular method for implementing a Forth virtual machine on the 6502. It is an interactive environment, whereby the user can incrementally compile his or her own definitions on-the-fly, which essentially causes a header and an array of addresses for each action being compiled. These addresses grow up in memory, tacked on to the current dictionary. The inner interpreter called "NEXT" is executed between each action, and an important part of its job is to update the interpreter pointer in ZP (usually the address field of a JMP (IP)), and execute the JMP (). Care must be exercised when compiling "words" that may contain an address split across a page boundary. This would cause a sneaky "bug" in your Forth environment, whether or not you choose to call it a "bug" in the NMOS 65xx. The issue completely disappears for the CMOS 65xx running the same environment.

Mike B.

Off topic, but just to lighten things up, anyone who says the C= 8 bits all work fine is not very familiar with the P and B series machines! :<)

I can vouch for the crankiness of those machines.  The B128, in particular, was as ornery as a hungry bear and due to the stupid design of its 6509 MPU, a real pain to program in assembly language.

All Commodore eight bit hardware had issues, sometimes due to chip errata, the 6526 CIA timer B interrupt bug present in the C-64 and C-128 being a classic case that messed up the fake RS-232 functions.

[this message is removed by its author]

This is nothing new. The boundary between what is a "features" and a "bug" have always been extremely unclear at beast, if it's hardware we're talking about, then it's even worse. As I said, bug exploit is nothing new, and if you find interesting ways to exploit a bug/feature, then it's very cool.
To be honnest, I haven't heard much about Forth outside of 6502.org, where for some random reason this language/environment seems extremely popular.
I don't get where you got the emotional part, personally I couldn't be any less emotional about this.

At the risk of exciting your ire, that statement doesn't make any sense, to me at least. A bug is a bug, and Rockwell, having been the second largest producer of 6502s after MOS Technology, would know if the 6502 had bugs.

If a bug involves hardware it means there is some aspect of the hardware's behavior that doesn't follow published specifications. The 6502 and all NMOS derivatives have two distinct hardware bugs that meet that definition, one being what happens in the case of JMP ($xxFF), and the other having to do with what happens when a hardware interrupt hits just as a BRK instruction is being fetched. Asserting that these are not bugs is like insisting the sky is green.

I think part of litwr's argument is that data sheets (some, not all) do document the actual behavior (after the bug was discovered), so he's saying it's not a bug (even though it works wrong).  I just checked what my 1985 Synertek book says about the NMOS '02 though, and it was still not updated to reflect the bug that was found.  It was still saying, "The next memory location contains the high-order byte of the effective address which is loaded into the sixteen bits of the program counter."  As we know however, it won't be the next one if the address record starts at xxFF.

If the published specifications were clear then that'd be a valid outlook. But even the original MOS specifications are not clear.
IMO, anyone who has a right-vs-wrong, black-and-white perspective on this debate is being blind to some important subtlety. Arguably litwr is guilty of this, but he's not alone.

The doc does and doesn't imply a page crossing. And, for the coders out there dealing with the reality of the silicon, cases have been illustrated for the desirablility and the undesirablility of a page crossing.

(FWIW, I become more and more receptive to the notion the ambiguity in the spec was intentional, as I suspect the company was reluctant to be 100% candid regarding errata in their yet-to-be-accepted new product. But the reason for the ambiguity doesn't affect my point above.)

It would be good to start a topic, or have an article, about easily overlooked uses for various instructions.  I'm sure we're all forfeiting some efficiency we could be using.  (The same goes for self-modifying code.  We had somewhat of a start on such discussion at viewtopic.php?f=2&t=1255 .)

Well, I certainly won't argue with that, given that the early versions of the 6502 had a broken ROR instruction (carry wasn't propagated into bit 7). MOS Technology addressed that problem by simply not including ROR in the list of instructions supported by the processor. Of course, they did fix the problem and then ROR magically appeared.

I've been trying to recall when I first run into the JMP ($xxFF) bug in a program that I had written. I do recall that the documentation that my employer in the 1970s was given when a prototype device was designed around the 6502 made no mention of the JMP ($xxFF) bug but did list the addressing mode in the detailed instruction description. That would have been in 1976, which was when I learned the 6502 assembly language. I do know I ran into the JMP ($xxFF) bug later on. The earliest I remember it being mentioned in any literature was in 1979 in 6502 Assembly Language Programming, by Lance A. Leventhal. My copy, which is the second edition that was published in 1986 (my original 1979 edition completely fell apart from much use) describes the problem on page 3-13. This same edition of that book also mentions that the JMP ($xxFF) bug was fixed in the 65C02.

Thanks BDD, that's very interesting - although we don't know exactly when Leventhal wrote the book published in 1979, there is usually a fair delay between writing and publishing, and evidently he was aware of the behaviour. (Edit: I see the book's references include one to an article from April 1979)

From page 63 of this PDF of the first edition, page 3-13 of the book: