6502 redundant, missed, and suggested features

[Bregalad]

Quote:

That's been my point all along. JMP (<addr>) is defective in one specific case. If there is a hole in the middle of the sidewalk you don't abandon the sidewalk. You just go around the hole.

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.

[litwr]

[this message is removed by its author]

[KC9UDX]

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.

[Klaus2m5]

litwr wrote:

Klaus2m5 wrote:

Lets say you have a monitor program or a basic interpreter in ROM. You want to allow a user program in RAM to intercept essential system vectors like interrupts or standard IO. The ROM would initialize the vectors in RAM to the standard routines the ROM provides. Later you load a user program initializing the vectors to its own routines.

That is a standard technique used by ROM based 6502 computers from the KIM-1 to the C64.

Ok. Where do you see a problem with NMOS/HMOS 6502? I know Commodore 8-bit line good - all works fine.

If you don't see that I can't help you.

litwr wrote:

BigEd wrote:

Well, there's less than half a percent chance of hitting the bug, in normal usage.

My point is 0%. However I am not 100% sure. I still have 0.00000001% doubt.

see below

litwr wrote:

Klaus2m5 wrote:

That is per vector. If you have 13 vectors it is 5% (26 of 256 bytes with a 50% chance of being on an odd address). If you wonder about the number - the C64 had exactly 13 vectors. When looking at the data structure of the C64 you'll find an unused byte ahead of the vectors. Obviously the C64 ROM coders were aware of the problem and aligned the vector table to an even address, although it was not even near a page boundary.

Could you provide addresses of these unused bytes? C64 vectors known to me start at $300 and are placed in 2 bytes exactly.

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.

[barrym95838]

litwr wrote:

... Could you provide any example of such the dynamic state? ...

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.

[KC9UDX]

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! :<)

[BigDumbDinosaur]

KC9UDX wrote:

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.

[litwr]

[this message is removed by its author]

[Bregalad]

Quote:

I have to give up. I have to admit that Rockwell newsletter had successfully induced the new case for the meaning of a word "bug".

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.

Quote:

The same is true for Forth programming language too.

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.

Quote:

Anyway, thanks to all for this a bit emotional discussion and for the attempts to help.

I don't get where you got the emotional part, personally I couldn't be any less emotional about this.

[BigDumbDinosaur]

litwr wrote:

I have to give up. I have to admit that Rockwell newsletter had successfully induced the new case for the meaning of a word "bug".

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.

[GARTHWILSON]

BigDumbDinosaur wrote:

If a bug involves hardware it means there is some aspect of the hardware's behavior that doesn't follow published specifications.

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.

[Dr Jefyll]

BigDumbDinosaur wrote:

If a bug involves hardware it means there is some aspect of the hardware's behavior that doesn't follow published specifications.

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

[GARTHWILSON]

KC9UDX wrote:

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.

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

[BigDumbDinosaur]

Dr Jefyll wrote:

...as I suspect the company was reluctant to be 100% candid regarding errata in their yet-to-be-accepted new product.

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.

[BigEd]

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:

1979 warning from Leventhal

Quote:

Never let an indirect address cross a page boundary, as in JMP ($31FF). Although the high-order byte of the indirect address is in the first location of the next page (in this example, memory location 3200₁₆), the CPU will fetch the high-order byte from the first location of the same page (location 3100₁₆ in our example).