[this message is removed by its author]

_________________
my blog about processors

I think more about the example provided and begin to have doubts in it. Let's see the general code of a complex structure

We have to calculate the absolute address of a jmp_field in order to use it then we should place these address to the JMP (). IMHO we may place the ADDRESS in JMP abs instead... I can also add that it is more common to keep addresses for JSR not for JMP... So I can imagine that it is very uneasy to create a practical example which shows the usefulness of CMOS JMP (xxFF)...

_________________
my blog about processors

Yup.

Yup. This statement doesn't contradict the one above -- they're both true.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Re. JMP ($xxFF), also see http://6502.org/documents/publications/ ... tive_2.pdf page 12 (page 16 in the PDF), this is Rockwell International's newsletter for the AIM-65 and related products.

Edit/addendum: And also Bob Sander-Cederlof's take on it (he refers to the same notice from Rockwell, although he names the magazine as 'Interface' - there may of course have been several Rockwell newsletters at the time). His favourite method for avoiding the problem? Staying away from the instruction altogether! http://www.txbobsc.com/aal/1980/aal8010.html, scroll to the bottom (or go there directly, with http://www.txbobsc.com/aal/1980/aal8010.html#6502bug)

-Tor

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.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

As I earlier said, you are beating a dead horse. This statement from Rockwell's newsletter is authoritative:

There is a error in the JUMP INDIRECT instruction of ALL 6500 family CPU chips, no matter who they were made by. This fatal error occurs only when the low byte of the indirect pointer location happens to be $FF, as in JMP ($03FF).

"Fatal error" means "bug," and truly is fatal if an errant jump lands the MPU on an undocumented opcode that causes a halt.

JMP (<addr>) is useful in many situations—I routinely use JMP (<addr>) and JMP (<addr>,X) in my software. JMP (<addr>,X) is analogous to the switch statement in ANSI C. In fact, POC V1.1's firmware routes the interrupt handlers and the SCSI bus phase dispatch code through indirect vectors. As a matter of tradition, I page-aligned these vectors, although it is unnecessary with the 65C816. However, long ago when I was writing for the NMOS versions, I didn't shy away from JMP (<addr>) just because it was buggy. I merely stayed aware of where jump vectors ended up in my code.

If working with an NMOS part and using JMP (<addr>) there's no magic to it: just page-align your vector tables. However, we consistently advise those interested in building hardware to not use the NMOS 6502, not only due to the JMP ($xxFF) bug, but due to weak fanout, low clock speeds and the inability of RDY to halt the MPU during a write operation, the latter a characteristic which could, I suppose, also be considered a bug.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

And you don't need those instructions because its faster to realize it with tables. In fact, CISC processors just incorporate large tables to do math faster, aka the famous pentium division bug. So if you consider that, what you really want is larger memory and faster access. I would really love to see a 65cXXX with built-in memory done at 12nm process..

@litwr : So what ? Because you find *one* possible way of clearly exploit a bug, it doesn't make it any less a bug. Bug exploit is not something new either, so having something that is exploitable doesn't mean it is not a bug. I agree "fixing" the bug might not be a good idea as it breaks compatibility with programs that does bug exploit - but that doesn't make the bug any less a bug.

Again, I never use jmp indirect myself so I don't care.

I used JMP (ind) today just to say I did. I don't know if I've ever used it before.

I assume I must have when I was developing my assembler. But probably nothing more than a simple test to make sure the code came out correct. If memory serves, it was one of the few op codes that for years didn't work and I never noticed.

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

Which makes debugging all that much more difficult.

That depends on if "normal usage" involves self-modification of the JMP (xxxx) operand bytes.

I would think "normal usage" uses fixed-location indirection vectors as Klaus2m5 mentions. Those have 0% chance of bugging in a dynamic state. Though the static state of the assembler dropping a vector at $xxFF could exist, it would bug all the time and be caught & fixed. It's only the dynamic state where the vector address changes at runtime that would hide an unpredictable bug.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Specially round here where there are concrete corridors under the sidewalks!

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.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5