A new article about 6502

[litwr]

I dare to share a link to my translation from Russian of an article about 6502 - https://litwr.livejournal.com/2773.html
It will be interesting to get some comments and additions. I am not a native English speaker so please excuse me my a bit not proper language. Indeed, I will be glad to get any corrections of grammar or stylistic. Thank you.

[GARTHWILSON]

It's always fun to read this kind of stuff. Wow, this one sure was critical of the CMOS improvements though, which are many, and they do improve program efficiency. The same goes for the '816 which is a bigger step up, and can do things the '02 cannot do at any speed. Even on the NMOS however, the JMP(xxFF) bug can be gotten around by putting it in a macro that looks to see if the operand will straddle a page boundary, and if so, put a NOP before the instruction. Problem solved, with no further human attention. No need to avoid the jump-indirect. I remember seeing a Rockwell 6502 ad even in 1984 touting 2MHz, and at the time, I thought that was humming right along pretty good! I think I came across it again not long ago. Now I just need to remember where I filed it.

[litwr]

Dear GARTHWILSON, thank you very much for the link. It points to some materials unknown to me. Indeed, CMOS provides better technological background.
EDIT. CSG offered NMOS 6502 @3MHz even at 1981. I'm not sure but maybe 4 MHz NMOS or HMOS 6502 was also possible, for example, in 1984 or even earlier.

[litwr]

It a surprise for me that Wikipedia has completely missed 6502 in https://en.wikipedia.org/wiki/Rockwell_International

[ArnoldLayne]

I'm a bit puzzled about how the article tries to make Bill Mensch a controversal figure. Or did I miss something?

[litwr]

ArnoldLayne wrote:

I'm a bit puzzled about how the article tries to make Bill Mensch a controversal figure. Or did I miss something?

I have written that the history of the 6502 is still not clear and Bill Mensch has been a part of it.

[litwr]

Bump! I've made some work with my English and now my article can be read easier. I also added some new materials.
As before, I will be glad to get any comments, additions or criticism.
It is fascinating for me that the idea of using the zero page memory as registers was implemented in the https://en.wikipedia.org/wiki/ICT_1900_series computers.
Thanks.

[BigEd]

(A little bit OT:

litwr wrote:

It is fascinating for me that the idea of using the zero page memory as registers was implemented in the https://en.wikipedia.org/wiki/ICT_1900_series computers.

Oh, look, another 24 bit computer! We're looking at those over here. And with a Ferranti provenance - another of our current interests.
)

It's an interesting architectural choice to place the registers in the memory map: as noted in Wikipedia, it doesn't mean the registers are necessarily on the far end of a memory bus, but it does mean they can be, in a cost-reduced implementation. TI's TMS9900 is a prominent example of this - it allowed their architecture to have many registers (indeed, register windows) without needing to find room for them on chip. Of course there's a potential performance penalty if the registers really are in memory.

Another interesting point is that 'zero page' can be a variety of sizes depending on the instruction format. In a word-addressed machine each location can hold an address, usually, whereas a byte-addressed machine like the 6502 gets rather fewer pointer locations for the same number of address bits. The 6502's 256 bytes of zero page are very restricted compared, say, to a machine with 4k words of zero page. Nonetheless, as we know, 256 bytes is enough for an OS and an application to have plenty of space for frequently used data.

[GaBuZoMeu]

IIRC the LINC and/or the PDP-8 have had a few "auto increment memories" that usually were used as pointers. These were located within the first 128 (64?) words of the whole memory, that could be accessed from everywhere. You may consider that as forerunners for memory mapped registers and "zero page address mode".

[BigEd]

Ah yes, "do something" locations are rather a good trick. Also known as "transport triggered architecture". A bit like a coprocessor.

[litwr]

A man helped be to find out that the CMOS 6502 in one particular case could be one cycle faster than the NMOS 6502 or even 65816. It is about RWM instructions with ABS,X addressing mode when no page boundary crossed.

BigEd wrote:

(A little bit OT:
And with a Ferranti provenance - another of our current interests.
)

It's an interesting architectural choice to place the registers in the memory map: as noted in Wikipedia, it doesn't mean the registers are necessarily on the far end of a memory bus, but it does mean they can be, in a cost-reduced implementation. TI's TMS9900 is a prominent example of this - it allowed their architecture to have many registers (indeed, register windows) without needing to find room for them on chip. Of course there's a potential performance penalty if the registers really are in memory.

Another interesting point is that 'zero page' can be a variety of sizes depending on the instruction format. In a word-addressed machine each location can hold an address, usually, whereas a byte-addressed machine like the 6502 gets rather fewer pointer locations for the same number of address bits. The 6502's 256 bytes of zero page are very restricted compared, say, to a machine with 4k words of zero page. Nonetheless, as we know, 256 bytes is enough for an OS and an application to have plenty of space for frequently used data.

Ferranti's processors were completely unknown to me! Thanks. However this case shows that Ferranti completely missed so promising PC market. Were their processors too slow?

Indeed it is interesting to think about a CPU architecture without accumulators, GPR, or indexes. IMHO using short zp-addresses and fast memory for zp would give an effect of use of registers. The TMS9900 in the TI-99/4 had only 256 bytes of fast RAM... It is really only few benchmark results available for the TI99/4. I could only find several benchmark results for Basic, for example http://lowendmac.com/2016/how-fast-were ... computers/ - the TMS9900 shows performance roughly equal to the Z80. If it had used more fast RAM it would have been much faster.

The JCL1900 was an interesting computer. It lost the market of the USSR and it was a very significant event for history. In the background it was a struggle between Germans (Eastern) who wanted to steal the IBM/360 and Poles who wanted to buy ICL1900 technology. Germans won and it was one of the main cause of the later events in the 80s and 90s.

[BigEd]

There are some interesting first-person comments on the Soviet standardisation on the IBM/360 architecture in the readable 200-page memoir
Pioneers of Soviet Computing by Boris Nikolaevich Malinovsky.

Indeed, Ferranti were pretty successful making computers, before they were quite mass-produced, and then when it came to minicomputers it seems they started to concentrate more on the military market. So I think they got used to low volume, high reliability, hostile physical environment, high unit prices. They were not culturally orientated to consumer computing. (Actually, they were unable to pursue commercial computing as a consequence of selling the Ferranti-Packard division into ICT, which later became ICL. It's just possible this same constraint prevented them from pursuing consumer or personal computing.)

[litwr]

I have updated this article, or rather blog entry - https://litwr.livejournal.com/2773.html. It has become about 50% larger. I have also done a lot of job with English to make it better.
I will be happy to get more information about the 6502, any corrections will be kindly appreciated too. Than you.

[cjs]

Quote:

MOS Technology specialists claimed that their processor was up to 4 times faster than the 6800. I find this questionable: the 6502 can work much faster with memory, but the 6800's second accumulator greatly accelerated many calculations. I can assume on estimation that the 6502 was on average no more than 2 times faster.

The 6800 and the 6502 are roughly the same speed, if you're speaking generally. I'm not sure where you got "the 6502 can work much faster with memory." It does usually handle array-to-array operations of 256 bytes or less faster than the 6800, which is not an uncommon case, but nor is it a huge part of almost every program out there.

Quote:

...the 6501 and 6502 in particular, did not support working with three output states and therefore could not be used directly, for example with hardware with direct memory access.

Well, that was pretty easily fixed with couple of external buffers. The Apple II used DMA for the video system in exactly this way. If leaving a tri-state address bus off of the 6502 resulted in significant cost savings (I have heard this, but have seen no conclusive evidence) then it certainly made sense to leave that to external parts that could be left off on systems that don't need that feature.

Quote:

Although a "bug" strictly speaking it was not. Of course for a specialist accustomed to the comfortable processors of large systems of those years one of the features that is quite relevant and even useful among microprocessors, could seem something annoying, a bug. But in fact this behavior of hurting someone's feelings was described in the official documentation from 1976....

Well, I don't think there's any plausible description of the indirect jump bug other than "bug." It was a documented bug, certainly, but the behaviour caused problems that needed to be worked around and offered no advantages to anyone except people trying to obfuscate code.

Quote:

I raised this question on the forum 6502.org, where some participants had familiarity with the Apple ][ computers. I asked if anyone could give an example when the "bug" crashed the program. I received only emotional and general comments, a specific example was never offered.

Well the nature of the bug is that it would exhibit as "something is mysteriously wrong somewhere in the program" and would likely vanish if small changes were made to the program, so someone saying "I specifically encountered that" is low, but there could be many people who encountered it but never traced it down to that.

Quote:

On the other hand, the absolute majority of the new instructions only occupied the code space, adding almost nothing to the capabilities of the 6502, which left fewer free opcodes for possible further upgrades.

That's not a huge deal; there's no reason that little-used opcodes couldn't be removed in a new version of the CPU, to be replaced with other more useful things, should someone think of and implement them. The CMOS versions never had complete compatibility with each other anyway; Rockwell had instructions that Signetics did not have and so on.

Quote:

The last scene of the drama with the participation of the 6502 was featured in the prevention of computers based on the 6502 with a frequency of 2 MHz on the US market in the first half of the 80's. This affected the English BBC Micro, their manufacturing company Acorn made a large batch of computers for the United States, but as it turned out, in vain. Some kind of lock was triggered and the computers had to be urgently redone to European standards.

This sounds a bit dodgy, as if there's some sort of conspiracy involved or something. And, "Some kind of lock was trigered"? Do you have any documentation of this story?

Much of this part of the article comes across as quite speculative. Perhaps you should give your references for this stuff.

Quote:

The instruction system 6502 in some particular ways is unusually asymmetric, for example, there is an instruction to load register Y, LDY addr,X, but there is no pairwise unload to it. There is an instruction to reset the overflow flag, but there is no paired instruction to set it.

Both of these make perfect sense if you think about the design goals of the CPU (take out anything unnecessary in order to reduce cost) and how the instructions were used. Directly setting and clearing the overflow flag isn't something you'd typically want to do. But the 6502 does have an external pin that sets the overflow flag for use as a signal input, so of course you would want CLV to be able to clear that. LDY aaaa,X is conceivably useful for loading indices from a table, but there seems little call to store indicies to a table.

Given that the design deliberately left out much more useful instructions, such as BRA, to keep costs down, it's no suprise that they left out more obscure and less useful instructions.

Quote:

The main drawback of the 6502 is the small stack size, only 256 bytes. However, for a system with a memory capacity of 64 KB, this, as practice has shown, is usually quite enough.

I wouldn't call that its main drawback. As it turns out, for the kinds of things done on the 6502 the small stack isn't a drawback in most cases, much less its main drawback. And I don't see it as related to the memory capacity of the machine.

Quote:

The Commodore PET in the development of which Chuck Peddle was actively involved appeared on sale half a year earlier than the Apple ][, although its mass production started only half a year later than the Apple ][.

My understanding is that the PET was not for sale at all until 1977-10 (4 months after the Apple II); up to that point they were only demoing it. BTW, the Apple II is generally written as "Apple II"; the stylized "][" was only ever used on the boot screen, and never in Apple documentation or advertising as far as I'm aware.

Quote:

Interestingly, of the three mass PCs that appeared in 1977, "the holy trinity", two were based on the 6502 and only one on the Z80. Unfortunately, the most important American computer manufacturers (Apple, Tandy RadioShack, IBM), from the 80's did not publish information about the number of PCs they produced.

None the less, this information is available. See, for example, some of the information I dug up in this thread on retrocomputingforum.com. (EDIT: Link fixed to point to the right thread, and Ed has also mentioned this thread.) For what it's worth, especially through about 1980, the TRS-80 was by far the biggest seller of the Trinity, and Apple by far the smallest.

Quote:

However, it was unclear why it was then to implement support for decimal arithmetic, which is completely superfluous in controllers.

Is it? Are controllers never used for processes that count and display in decimal?

Quote:

One can only try to fantasize about what would have happened if the 6502 had developed at the same pace as its competitors.

It seems to me it more or less did, and went the way of the other systems that also tried to maintain binary compatibility.

Quote:

Why the 6502 was slowed down in its development and deprived of a much brighter future?

I don't think it was slowed down in its development; if anything it was one of the two 8-bit processors (along with the Z80) that had any real future at all in computers (as opposed to microcontroller systems, where the 6800 descendants pretty much stomped both of them).

[litwr]

cjs wrote:

The 6800 and the 6502 are roughly the same speed, if you're speaking generally. I'm not sure where you got "the 6502 can work much faster with memory." It does usually handle array-to-array operations of 256 bytes or less faster than the 6800, which is not an uncommon case, but nor is it a huge part of almost every program out there.

At first, thank you very much for reading and comments.

The 6502 team had benchmark results where the 6502 was up to 4 times faster than the 6800. The 6502 addressing modes are much better and two index registers are much better than one. Better addressing modes make the 6502 faster with memory.

cjs wrote:

Well, I don't think there's any plausible description of the indirect jump bug other than "bug." It was a documented bug, certainly, but the behaviour caused problems that needed to be worked around and offered no advantages to anyone except people trying to obfuscate code.

It was just a normal instruction, I used it in my code exactly according MOS documentation from 1976. Somebody for some reason didn't like this instruction specification and a faked "bug" appeared.

cjs wrote:

Well the nature of the bug is that it would exhibit as "something is mysteriously wrong somewhere in the program" and would likely vanish if small changes were made to the program, so someone saying "I specifically encountered that" is low, but there could be many people who encountered it but never traced it down to that.

People must have read MOS documentation carefully and didn't repeat this strange claim about the "bug".

cjs wrote:

That's not a huge deal; there's no reason that little-used opcodes couldn't be removed in a new version of the CPU, to be replaced with other more useful things, should someone think of and implement them. The CMOS versions never had complete compatibility with each other anyway; Rockwell had instructions that Signetics did not have and so on.

IMHO Rockwell only used its special bit oriented instructions, which were not used in others 65C02 and 65816. Is there anything else?

cjs wrote:

This sounds a bit dodgy, as if there's some sort of conspiracy involved or something. And, "Some kind of lock was trigered"? Do you have any documentation of this story?

It is a well known case, check Wiki's article about the BBC Micro. IMHO to make business in the USA is a tough task, read, for example, about the lamentable fate of Ferranty company there. IMHO the computer market of the USA was heavily protected in the 80s, popular computers like the ZX Spectrum, Amstrad CPC, MSX could not reach it.

cjs wrote:

Directly setting and clearing the overflow flag isn't something you'd typically want to do. But the 6502 does have an external pin that sets the overflow flag for use as a signal input, so of course you would want CLV to be able to clear that.
Given that the design deliberately left out much more useful instructions, such as BRA, to keep costs down, it's no suprise that they left out more obscure and less useful instructions.

IMHO even the CLV instruction was rather redundant.

I doubt that BRA is more useful because the 6502 has a fast JMP instruction and BRA would have been slower having 4 cycles for the quite often case of the page boundary crossing. Usually a programmer can place a proper jump, simulating BRA, using his knowledge of current flags value.

cjs wrote:

I wouldn't call that its main drawback. As it turns out, for the kinds of things done on the 6502 the small stack isn't a drawback in most cases, much less its main drawback. And I don't see it as related to the memory capacity of the machine.

Chuck Peddle mentioned this in his oral history. The relation is not straightly direct but it is definitely exists. The size of available memory defines the size of a particular project. More code means more subroutines, more parameters for them, and more nesting calls...

cjs wrote:

My understanding is that the PET was not for sale at all until 1977-10 (4 months after the Apple II); up to that point they were only demoing it. BTW, the Apple II is generally written as "Apple II"; the stylized "][" was only ever used on the boot screen, and never in Apple documentation or advertising as far as I'm aware.

The wiki's article about Apple II starts with "The Apple II (stylized as apple ][)".

cjs wrote:

None the less, this information is available. See, for example, some of the information I dug up in this thread on retrocomputingforum.com. (EDIT: Link fixed to point to the right thread, and Ed has also mentioned this thread.) For what it's worth, especially through about 1980, the TRS-80 was by far the biggest seller of the Trinity, and Apple by far the smallest.

I can only repeat "most important American computer manufacturers (Apple, Tandy RadioShack, IBM), from the 80's did not publish information about the number of PCs they produced". This is actual up to the current date. We have only some speculative estimations.

cjs wrote:

Is it? Are controllers never used for processes that count and display in decimal?

You are right. It has been fixed. Thank you. I were working little with controllers...

cjs wrote:

It seems to me it more or less did, and went the way of the other systems that also tried to maintain binary compatibility.

viewtopic.php?f=1&t=6184#p76794 - they had plans for an 16-bit extension in 1976. They were broken

cjs wrote:

I don't think it was slowed down in its development; if anything it was one of the two 8-bit processors (along with the Z80) that had any real future at all in computers (as opposed to microcontroller systems, where the 6800 descendants pretty much stomped both of them).

I don't understand your logic. MOS Technology was crushed. The developer team was disbanded. Only one its engineer and with a large delay continued working under the 6502. And his work was rather directed from Apple...