Probably they didn't feel like adding too much detail to the text, when the description below shows exactly what's happening.

Or, the designers intended to use the PC, and get a full 16 bit increment for free, but ran into some problems and switched to ALU increment late in the design process.

My suspicion is that by the time that manual was written, some knowledge was lost.

The usual use case for JMP(abs) is surely a single JMP to indirect a vector. It's unlikely that the vector will be placed at the end of a page, so almost everyone will be unaware of the bug.

Edit: I see that indirect threaded code could possibly hit this, if it didn't take care.

Just for historical interest, I had a look to see what's the earliest mention of this bug, and the earliest I found is a note by Heinz J Schilling in 6502 User Notes newsletter, issue 15, June 1979.
http://archive.6502.org/publications/65 ... df#page=24
http://www.classiccmp.org/cini/pdf/KIM% ... df#page=24

It would be interesting to hear of an earlier mention.

Edit: I see that Bob Sander-Cederlof's newletter "Apple Assembly Lines" trumpets this bug note in the first issue, October 1980. I'm thinking therefore that it would not already be common knowledge.

(Again, a confusion between the address bus and program counter!)

Edit: downthread, BDD notes that Leventhal's 1979 book describes the misbehaviour, and it looks like the book was finalised no earlier than April 1979.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

For some time I've thought about a 65c02 upgrade board for the C64.

Someday, I will. It will break a lot of software, but for my purposes, I won't be too concerned.

If I get time this winter, I'd like to put a 65c02 in a PET and see what the consequences are. Unfortunately most of the PET software I have already doesn't work, so I might not find out.

I did have possession of a couple Apple //es that were dealer "enhanced." I don't have any recollection who the dealer was, but apparently they had forged ROMs. Visually they looked just like Apple ROMs should look, but they must have relied on the 65c02. Several times over the years I put known good NMOS 6502s in them and they both failed to boot. Unfortunately I think I sold both of those machines in recent years.

The Apple IIe enhanced is *exactly* an Apple IIe where the processor has been upgraded to a 65c02, and the ROMs rewritten to use the new opcodes (and in the process, freeing up enough space to add functionality - notably, the mini assembler).

See https://en.wikipedia.org/wiki/Apple_IIe#Enhanced_IIe.

That's what I always believed until a few years ago.

If you have an Enhanced //e, you can take the 65c02 out and put in a 6502, and it will run all day long. Except for the two that I had, and maybe others, but I've not heard of anyone else with this situation.

At least this is what has been reported to me by other owners who were perplexed when I told them that the Enhanced ROM requires a 65c02.

How the code below can be used with 8-bit XR?

it may work only with 128 entries instead of 256...

It is exactly the current code for 6502. One man spent hours trying to find out why this program working at C64 is not working with SuperCPU (65816) - http://www.lemon64.com/forum/viewtopic.php?t=58674&postdays=0&postorder=asc&start=19#top. So I had to add one byte for 65C02 "feature". Of course,

is better than the code for NMOS 6502. It is 3 bytes shorter and 3 cycles faster. This discussion helps me to realize this. So it is the way I should use to prepare the specialized 65C02 version for BBC Micro. It is the only advantage of 65C02 usable in the spigot but the byte division is not exactly in the main loop so the advantage in speed will be less than ≈0.1%.

You'd written about 65816 instructions. They are good and powerful indeed. I can only think that they can be better and faster. I bet for the segment registers, for example. I also bet for Z register of 4510 - it is much better the plain (zp) mode.


6502 development was beheaded so without "political cover" it was easily influenced by men who did not think primarily about this development but might have other aims.

_________________
my blog about processors

I just use tables for whatever function that's missing. You can often combine it with some operand (ORA, AND) to shave off cycles.

For example 4bit*4bit math (x*y):


14 cycles. Two 256 byte tables. And it disregards the upper 4 bits (if they are present).

Without the shift table:


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.

Depending on how crucial speed is, I would put the compatibility into the code, not into the data structure. If the index is always odd, then a simple DEX brings it back into 0-254 range with even numbers and there's no page overflow.

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

Thanks again for working with my code. However I don't see any "the very special case" - it is just an ordinary code, natural for this case. I can even assume that there are no coders at all who were "bitten by the lack of the carry into the upper byte of the indirect address". Could you show any practical example which shows the situation in reverse? IMHO The problem of JMP (xxFF) is completely contrived and artificial.


My point is in fact that the writers of this enormously big amount of software never complained about JMP (xxFF). Another my point that the advancement from NMOS 6502 to CMOS was very tiny and it has even several back steps (the creation of JMP (xxFF) incompatibility, the occupation of valuable opcode space by the unimportant instructions, slow down the redundant BCD mode, ...) that it can't be called the advancement at all.

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

The fastest speed for different platforms is the aim of the spigot project.

_________________
my blog about processors

Nobody ever complained, because everyone was aware of the behaviour, and acted accordingly.

I was aware of the JMP ($xxFF) nearly 40 years ago and, in fact, tripped over it back then. It is a real bug and everyone who has professionally developed for the 6502 (not the CMOS hardware) knows it's a real bug. Using Commodore as example, in page $03 are the kernel and BASIC indirect vectors. CBM page-aligned those vectors precisely because of JMP ($xxFF). They knew it was a bug back when the paint on the PET 2001 was still drying.

Methinks you are beating a dead horse.


I'm sure Apple didn't agree with you about the 65C02 when they started using it in place of the NMOS part. In fact, they disagreed even more when the 65C816 found its way in the Apple ][gs.

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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Fair enough. First let's notice that in your application the 16-bit destination values accessed by JMP (abs) are stored together, adjacent to one another in a table. But in other circumstances a programmer may wish to store the destination values separately from one another, with other fields (of varying length) in between. IOW you might have a destination value, then one or more unrelated fields of arbitrary length, then another destination value, then some other unrelated fields, and so on. It's not uncommon. The dictionary used by Forth is an example of this.

When creating a mixed data structure like this it's desirable to freely allocate space exactly as needed. But if you allocate space exactly as needed then occasionally a destination value will straddle a page boundary. With NMOS 6502 this is a dangerous anomaly.

In the bad old days folks were forced to check for this condition every time before allocating space for a destination value. If the next available space happened to be at $xxFF then remedial action was required, such as sticking an extra, unused byte into the structure -- ie, wasting the byte at $xxFF -- to ensure proper alignment. Does that sound messy? It was!

Now we have the 'C02, and no anomalies. JMP (abs) just works.

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