6502 redundant, missed, and suggested features

[litwr]

[this message is removed by its author]

[litwr]

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

Code: Select all

base_of_structure
   VARIOUS UNALIGNED DATA
   jmp_fiels .word ADDRESS

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

[Dr Jefyll]

litwr wrote:

So NMOS 6502 JMP (xxFF) has the disadvantage for programs which use very complex data structures.

Yup.

litwr wrote:

My example shows that it also has the advantages.

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

litwr wrote:

Excuse me, how is it possible to call [...]

BigEd wrote:

(But I'm not sure if it's even interesting to keep arguing about what we call something. Much more interesting to talk about how things work and how to program them.)

[Tor]

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

[Klaus2m5]

litwr wrote:

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

Code: Select all

base_of_structure
   VARIOUS UNALIGNED DATA
   jmp_fiels .word ADDRESS

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

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.

[BigDumbDinosaur]

litwr wrote:

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

Code: Select all

base_of_structure
   VARIOUS UNALIGNED DATA
   jmp_fiels .word ADDRESS

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

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.

[kakemoms]

litwr wrote:

kakemoms wrote:

26 cycles. One 256 byte table. If you had a swap function you could shave off 6 cycles, but it would still be faster with the extra table.

I'd only written that LSR4 maybe almost always used instead of SWN. SWN might be realized easier though...

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

[Bregalad]

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

[KC9UDX]

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.

[BigEd]

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

[KC9UDX]

BigEd wrote:

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

Which makes debugging all that much more difficult.

[White Flame]

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.

[BigDumbDinosaur]

BigEd wrote:

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

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.

[KC9UDX]

BigDumbDinosaur wrote:

BigEd wrote:

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

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.

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

[Klaus2m5]

BigEd wrote:

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

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.