I have another small correction. DEC PDP-11 architecture supported BCD but in a very odd form. It provided a special optional co-processor unit (very costly) for this! They were so called commercial instructions. It was the strange world. IMHO without 6502 and ARM we were forced to live in it.


Thanks for this nice anecdote.
Sorry I was inaccurate 144 is the time for the best case. DIVS (signed division) with an operand in memory may take up to 186 cycles. Maybe it had prevented to use the high density floppies with 68000 based Mac, Amiga, Atari.


Agreed, 6502 has fast interrupts. This allows to create the nice demos using different video modes for the each raster line. Z80 based computers missed this. Only z80 at 7-8 MHz had become fast enough for these tricks.
The bird-monitoring system at 6502 looks impossible for me... How to run it without HDD? Or did it have one or two?


IMHO it is not so easy problem. 6502 has paged architecture. The logic above is too abstract, not practical. I gave the practical example which shows that NMOS 6502 works right and CMOS 6502 wrong. Is there any reversed example? In any way I prefer to use word "quirk" instead of "bug" or "error".
If we have to force theoretical logic then we have to say that addressing modes (zp,X) and zp,X are bugs too. 6502 without these "bugs" would have powerful stack manipulation instructions making 65816 stack addressing modes almost redundant.
IMHO "the fix" of JMP for 65C02 looks like the change of one detail only in the big picture full of the similar details.


I can try to explain this. I was sure that 6502 is 3 times faster than z80 3 years ago. Then I had an opportunity to meet an 8080/z80 expert programmer. He showed me how to write fast z80 codes. It is much more difficult than for 6502. So I am sure now that a good z80 programmer spending enough time may give z80 code which maybe only 2.1-2.2 times slower than the equivalent code for 6502.


I dare to suggest a better 6502 variant

So the code for PUT is only 4 bytes and maybe left without JMP too. Of course, 65816 is much better any way: 12 clocks against 26 and 4 bytes against 13.


They might add it and something else if they got the vision of CPU without BCD and V-flag.
The main question of my dreams is around legendary Chuck Peddle. What IF he had the opportunity to continue the work under 6502? Intel made 8086 at 1978 after 4 years since 8080 was appeared. Motorola were making 68000 during 5 years. Only 80186 (appeared at 1982) or 68020 (1984) might compete the speed of 6502... IMHO if MOSTEC might survive the "shark" attacks then we would have the different reality today. Without BBC Micro, Commodore 64, ... Maybe we could even see the Terminators around.


I am surprised by the slowness of 6809 systems. It looks like that 6502 may outperforms 6809!


I agree that z80 and 68000 are not too slow but the used frequency is also used by RAM and ROM. So 4 MHz 6502 may use the same memory as 4 MHz z80 without wait states. Commodore 128 could use 4 MHz - it is proven. BBC Micro second processors use even higher frequencies. It is obvious that 6502 at 4 MHz is much faster than z80 at 4 MHz. However z80 may use the wait states to use slower memory and this allowed to have the cheap systems like Spectrum or Amstrad CPC/PCW which have the speed matching 6502 at ≈1.5 MHz.
IMHO z80 had also hidden support from Intel which didn't try to spread its 8085. Microsoft explicitly supported z80. z80 had the common OS (CP/M). 6502 systems were isolated: no common OS, no common disc formats, etc. It was possible to make the common 6502 OS too. It maybe GEOS or the special version of CP/M. This demanded support from the big market players. IMHO Motorola might provide such support...

_________________
my blog about processors

_________________
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?

No, it is a genuine bug (I see Gary also provided details). If your assembly program just happened to be assembled so that the 16-bit address label address you used ended up just there, then your program would fail. Add one line of code anywhere, and reassemble, and it works. The bug is that the 16-bit address would be split so that the two parts were not contiguous. I don't see any relation to the other addressing modes you mentioned.

MOS wasn't really a victim of anything back then, it was simply acquired by Commodore because Commodore was bitten by relying on TI for their chips, and TI then turned around and underbid them with their own TI products. "Never again", said Commodore, and bought MOS so that they could have an in-house chip provider.

The 6502 legacy lives on in WDC, with Bill Mensch from MOS. And therefore we have a 65C02 that is still in production, at higher speeds, unlike the otherwise very nice 6809 which is only old stock and runs at original slow speeds.

This is only true for zeropage and implied stack addressing modes. Absolute addressing modes should generate a 16-bit address likewould load from $1080 in a "paged architecture" but correctly loads from $1180 both on CMOS and NMOS.

The example would not be executed correctly on the NMOS CPU.

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

Let's see at the next code

What is the location of a byte to load into AC register? Is it $100? No, It is 0. The same as JMP ($FF). Is it bug?
Let's see the other code

What is the address of a location of a byte to load to AC? Is it at $ff and $100? No, it is at $ff and 0. The same as JMP ($FF). Is it bug?
What is the definition of word "error" ("bug")? The word "error" means that the system behavior does not correspond the documentation. Is JMP (xxFF) not documented? No. So it is not bug.
Let's see at NMOS JMP (VALUE) closely. VALUE is not a variable, it is a constant. So it is easy to have a VALUE at the proper address. In the worst case we have to spend one more byte for the word alignment for the whole program to ensure this. I agree that in this case CMOS 6502 is in the microscopical scale better - it allows to save this one byte.
JMP (VALUE) is often useful to make fast jump tables. It was shown in my example above that NMOS 6502 works better in this case. I have to repeat it with more details. For example, we have two 256 bytes jump tables for odd and even arguments. Let's see the code

The both tables occupy exactly continuous 512 bytes for NMOS 6502 but they requires ugly 513 bytes for CMOS 6502. This example is not just artificially theoretical. I met such situation with my code http://forum.6502.org/viewtopic.php?f=2&t=4185. This ugliness of the code for 65816 in this case even made me a bit ill. I have to say that 65816 is very good but it is not perfect. CMOS 6502 additional features over NMOS 6502 are mean very little for the programming. IMHO JMP (xxFF) "problem" only creates excessive incompatibility. I have also to say that some of NMOS 6502 undocumented instructions are useful...


It is the point of Commodore. Did MOSTEC want to be sold?
I had read an article about MOS Tecnology about 20 years ago. Sorry, I can' t find it now. It showed that the situation around MOS financial problems were artificially created. It was namely a kind of the shark business. Commodore got credit money for this case...
Anyway, MOS Technology was sold and the development of 6502 was stopped. Intel and Motorola had made the next generation of their chips to the late 70s. IMHO MOSTEC might do the same. 65816 was a bit too late and can't match 80186 or 68000.


IMHO x86-64 at 1 Ghz can easily outperforms 6502 at 10 Ghz. X86_64 can make 64 bit multiply with 128 bit result in 1 tick! An x86_64 instruction may require dozens of 6502 instructions. The same is true for modern ARM too.


The mentioned table shows that 6809 at 1.79 Mhz is 5 times slower than 6502 at 2 MHz with BBC Basic 4. The Basic benchmarks are very inaccurate but... So It is possible that 6502 may outperform 6809 with the same frequency.

_________________
my blog about processors

About the 6502 memory model: I'd say it's not a paged model. There are two special pages, and for people concerned with cycle counts there are page-crossing boundaries, but otherwise it's flat. And so the JMP bug is a bug.

For the case of the 256-way jump, that's interesting that your approach winds up using 513 bytes - and indeed, that seems ugly. (But it might be the fastest way.) But, you don't need that bottom bit of the index any more, I think...


Or, no doubt, something a bit more slick! (Or even, something correct, because that's probably wrong)

On the topic of MOS, yes, they got burnt by the Motorola lawsuit, Jack T stitched them up in a deal to buy components, and they were out of cash so could be bought for very little. Victory to Jack and Commodore.
(Edit: see for example the oral history of Bill Mensch)

There's a big problem comparing CPUs, not only is it certainly going to depend on the choice of benchmark, but you need comparably top quality coding in all cases. In the case of the 6809 Basic benchmark, it's possible the 6809 Basic is not as excellently idiomatic as the 6502 one.

@litwr: I must admit that I don't understand your example.
The thing with the jmp error is that it affects loading of a 16-bit address, not an 8-bit offset as with so many other instructions. And when you load a 16-bit address you're supposed to load two consecutive bytes, who've ever heard about a 16-bit address split over different memory areas?

When Commodore bought MOS, development didn't stop - quite the opposite, for two reasons:
1) Commodore went nearly insane with creating new variants of every chip. So much so that when some of their key engineers later started working at other places they had to adjust to not being able to simply order up a new variant of a CPU or other chip, as they had become accustomed to while at Commodore.
2) WDC. The next step in 6502 development was, of course, CMOS, and that's exactly what happened with Bill Mensch leaving MOS and starting WDC. Bill M. was essential in the development of the original 6502 (and he also originally came from Motorola, with Chuck Peddle). There was never a break in 6502 development. What's left out is moving to the kind of fab process that the large foundaries can use, e.g. Intel and Samsung (14nm or 10nm or whatever). That's extremely costly. Other than that, there's not much more that can be done with a 65c02.. if you change it it's no longer a 65c02.

IMHO CMOS 6502 and NMOS 6502 are good illustration to "bargain one trouble for another".
The example for CMOS 6502 is 3 (or 2) bytes shorter (it is good) but 1 tick slower (it is bad). And it also has to use 513 bytes ugliness.

What is about the rule exceptions? They maybe even more important than the main rule. I can repeat, the error is only a case if a system does not work according to the documentation. You may don't like JMP (xxFF) NMOS feature but it is your THEORETICAL position only. It is practically as useful as CMOS 6502 JMP (xxFF) behavior. The example shows this.


MOSTEC 6502 team was crashed by Commodore business. It is fact. Chuck Peddles couldn't continue to work under 6502. It is fact. So these and other facts show that the development was almost stopped. Can you compare the ways from 6502 to 65C02 and 8080 to 8086? 65C02 is almost the same as 6502: slightly better and slightly worse. The way from 6502 to 65816 took 8 years... The way to 4510 took 14 years...

_________________
my blog about processors

Jump tables are shorter using rts instead of jmp indirect instruction (I assume the adresses in the jump table are stored pre-substracted with 1, to compensate for the PC increment the 6502 does after popping the adress of rts instruction). This makes the jmp () instruction almost useless, and the jmp () warp-arround bug (or feature, if you want to call it that way) irrelevent.

Exampe: Jump table implemented with jmp () instruciton:


The pointer doesn't have to be in zero page, but I just assumed it is to gain efficiency. jmp () is the only instruction which uses pointers outside of zero-page, but this feature is almost useless.

Using rts instruction instead:

Code takes the same time to execute, but is 4 bytes shorter. It also has the huge advantage of not needing any dedicated locations.


I agree, this is a fairly minor "bug" and fixing it wasn't really necessary.

Now, as to state my personal opinion on the matter...

I'd say we have to look at the original documentation coming from NMOS. If this is not documented from them, or if it is documented as a bug, then it is a bug. If it is documented as a feature, then it is a feature.

Not to start an argument, but both of you gentlemen are suffering from a bit of code myopia.

If using the 65C02 or 65C816, there is the JMP (<addr>,X) instruction, which requires no preparation of any jump vectors. You use it with a table containing 16 bit addresses in little endian order. The following code does the work:

Code:

         lda #index            ;zero-based routine index
         asl a                 ;double it
         tax                   ;now absolute index
         jmp (table,x)         ;goto routine

   ...

table    .word routine1,routine2,routine3 ... etc.

The above is the assembly language equivalent of ON...GOTO in BASIC. The 65C816 also has JSR (<addr>,X), which would be like ON...GOSUB in BASIC.

Unless working with old hardware, there is absolutely no good reason to constrain oneself with NMOS code limitations.

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

That's simply because it doesn't work. Another "lda INDEX" is required, or you use only the first loacation of the tables because of the "and #1".On NMOS I favour the RTS method shown by bregalad, on CMOS there is JMP (abs,x) as BigEd mentioned. And it even works without self modifying code.

However, for alterable ROM-vectors in RAM the JMP (abs) has its value, wether you have to allign the vector to an even boundary or not.

If you really want to do it your way and have it working in both worlds:

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

_________________
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?

6809 is hobbled by a wearisome prevalence of dead cycles. Even a simple operation such as an 8-bit load using Absolute address mode takes 5 cycles on 6809, as compared to 4 cycles on 6502. Using Direct-Page/Zero-Page mode the numbers are 4 cycles as compared to 3 cycles.

Hitachi's 6309 eliminated many or all of the dead cycles. And of course the 6809/6309's sophisticated address modes and large complement of 16-bit operations are unequaled by 6502.

Back in the day a pal o' mine remarked to me about the dismal performance of a 6809 machine he had encountered (probably the Tandy Color Computer, although I don't recall for sure). Just as a casual test he had typed an empty DO ... LOOP in Basic then hit RUN. "I couldn't believe how long it took for the loop to complete. I was beginning to think the machine had crashed!" We ended up speculating about the fact that 6809 is source-code compatible with 6800. My hunch was that the machine was running 6800 Basic, unmodified except for having been reassembled for 6809!

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

Does anyone remember the Williams Defender arcade game from 1980? It was a fast side-scrolling shoot em up, with a mad number of on-screen 16 color sprites. If you're not familiar with it, then try youtube for any one of countless videos of it in action.

I bring it up because what you see on the screen... Every object... Every animated particle... Every part of the scrolling image is generate and updated by a lowly 6809.

There's no hardware scroll register to shift the display. There are no hardware sprite registers.

The whole display is around 30-something K of 4-bit-per-pixel bitmapped graphics.

Every byte of screen memory holds two pixels, and adjacent bytes stride the y axis. That is, address 0000h holds the pixels for screen coordinates (0,0) and (1,0) ... In x,y notation... And address 0001h holds the pixels for screen coordinates (0,1) and (1,1). Thus a sequence of writes to consecutive addresses will result in a 2-pixel vertical stripe on the screen. The Defender code used multi-register PUSH instructions to rapidly write sprite data.

For the longest time I had always assumed that Williams had tons of fancy hardware in their Defender machines... Because all that happening on the screen couldn't possibly be done by a simple 8-bit CPU.

But I was wrong. It's all software. Smart hardware choices (re: the video memory layout) along with expert programming by Eugene Jarvis made the seemingly impossible possible.

It's quite telling that even the Atari ST with its 8MHz 68000 never had a Defender implementation that matched the speed of the 6809 original (and the ST also had a 32K screen).

Point being? The 6809 was a powerful little chip... As I think Williams Defender very well proves.

Oh yes -- absolutely! My post was not terribly well written, as it drifts in several different directions. Let me be clear I'm a big 6809 fan, and my observation about sophisticated address modes and 16-bit operations carries more weight than the point about all the dead bus cycles (which was in response to Garth's remark). Also the 6809 can hardly be blamed for suboptimal results when running 6800 code.

As for JMP (abs), I agree it's a bug but I almost wish they hadn't fixed it. The fixed version is one cycle slower -- and JMP (abs) is part of the performance-critical NEXT routine used by Forth.

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