Talk:MOS Technology 6502/Archives/2011

This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Poor Wording

The 6502 was released to the market in September 1975 at $25, while the 6800 and Intel 8008 were selling for $179. At first many people thought it was some sort of a scam, but before the show was over both Motorola and Intel had dropped their prices to $79. Instead of saving them, the 6502 was now legitimized and started selling by the hundreds.

Before the show was over... what show? It isn't otherwise mentioned. "Instead of saving them" is a bit of a vague pronoun reference. Instead of saving Intel? Might also want a comma after "At first". I'm not a grammar nazi, but this paragraph struck me as being pretty bad. --Jmccorm 04:48, 3 February 2006 (UTC)

From other articles on Wikipedia I gather it was a trade show and that all the 6502 samples were handed out (free?) by the time the show was over.

I don't know what "show" is being referred to, but I do know that the print ads for the 6800 prior to the introduction of the $20 6501 and #25 6502 priced the 6800 at $250 in single quantity, so the 6502 was actually introduced at 1/10th the price of the Motorola product, not just "less than 1/6". Motorola's print ads dropped the 6800 to $125 after the introduction of the 6502. —Preceding unsigned comment added by 75.18.164.205 (talk) 22:25, 16 August 2009 (UTC)

It was later used in the Atari home computers, the BBC Micro family, and a huge number of other designs now lost to history, such as Ohio Scientific.

Here is, IMO, more poor wording. "other designs now lost to history" makes it sound as if all of these other platforms were destroyed by invading hordes, perhaps burned in a fire like the library at Alexandria. Examples of all of these "lost" platforms exist in the hands of collectors/users today, so... What is meant to be conveyed here? That platforms like the Ohio Scientific Challenger are obsolete? All of the listed 6502 platforms are obsolete, so pointing out that some are defunct seems bizarre. Did the writer mean the OS (and other platforms) were less popular?

I'm hesitant to alter this paragraph without knowing the intent of the original writer, but I feel like it needs to be changed to something a little less poetic, and a little more factual. Student Driver 05:54, 8 April 2007 (UTC)

2A03's extra A/V features

The 2A03 lacked the 6502's decimal mode but added 23 memory-mapped registers for sound generation, object drawing, and joypad reading.

This can't be correct. All 6502 based systems use memory mapped IO, as the 6502 doesn't provide any other means of doing IO. All the sound and specialized graphics are provided by other specialized chips. --jay kominek (i'm not outright correcting this as there is a small chance that it is correct. comments?)

I looked this up and if there is any error it appears to be related to it being audio-only. I think you may be confusion memory-mapped I/O with I/O _register_? I assume the difference would be the ability to work the registers directly without any memory accesses. User:Maury Markowitz

I presume - without having checked - that they're memory mapped registers that access internal (to the chip) hardware - so certain addresses are handled internally rather than causing an external memory cycle. That's certainly plausible given the processor's architecture - but I haven't checked it. User: AndyArmstrong

Andy, accesses to the on-chip components *do* cause an external memory cycle. This was used in a 'state saving' device (GameMaster?) that could detect and store all the data written to the on-chip components by the 2A03, and then write them back so a program could resume where it was saved.

6501<>6502 slot converters?

The fact that the processor only had a different pin arrangement than the 6501 makes me wonder if anyone made converters (much like the slockets that became common with Athlons and/or Pentiums of more recent times). Anyone know? —Mulad, May 29, 2003.

It wouldn't be too hard, except for the clocking stuff, which is different on the 6502. Simply get a 6800 datasheet (remember, the 6501 had the same pinout as the 6800), and a 6502 datasheet, and match the pins.

There weren't enough 6501 chips shipped that it made any commercial sense to offer such a product. --Brouhaha 03:41, 20 November 2005 (UTC)

The point is that it would make it possible to plug a 6502 into a 6800 slot - nothing to do with the 6501. The existence of the 6501 just confirms that it's possible. I remember Elektor publishing a project that allowed a 6809 to be plugged into a 6502 socket. There may have been some glue circuitry - but there was clearly some electrical compatibility between 68xx processors and the 6502. AndyArmstrong

Fine, but why would you want to plug a 6800 into a product designed for a 6502, or vice versa? --Brouhaha 21:31, 13 December 2005 (UTC)

The 6501 was designed to be pin compatible with the 6800 - so you could take a 6800 SBC and build it up with the (cheaper, better) 6501. With a suitable adaptor you could use a 6502 in the same way. AndyArmstrong

It's somewhat debatable as to whether the 6501 was any "better" than the 6501. In any case, you haven't really explained why someone would want to do this. In what 6800 system would it be useful to substitute a 6502? Or vice versa? It's not going to make a system run faster or do more; in general all it's going to do is break it. For instance, the Apple I was designed to be usable with a 6800 instead of the 6502, by adding jumpers and additional components, but there's no record of anyone actually having done this, because no Apple I software would run on it. --Brouhaha 01:23, 15 December 2005 (UTC)

Obviously a 6501 isn't any better than a 6501... I don't see what you're missing; 6501 was pin compatible with / cheaper and faster than a 6800 which means it could be plugged into an existing design and immediately improve it. Sure, it wasn't code compatible but that wasn't such a big deal - at most you'd be talking about rewriting a few K of assembler. Andy Armstrong 08:50, 15 December 2005 (UTC)

So rewriting a few K of assembly is no big deal, but a minor hardware change is? Okay...Mirror Vax 13:21, 15 December 2005 (UTC)

An entirely different processor that costs less than half as much - at a time when the cost of the processor was a significant portion of the system price is not a minor hardware change. What part of this are you not getting? You need to understand that these processors weren't designed for home computer applications - they were designed mainly as embedded processors.

Most embedded applications are too cost-sensitive to spend money on an extra adapter. If they were willing to rewrite their 6800 application to run on a 650x, after the 6501 was discontinued they would have done a minor board revision to switch the the 6502. And for applications that weren't cost-sensitive, they just stuck with the 6800. --Brouhaha 20:10, 15 December 2005 (UTC)

Clock multiplication

I think the 6502 was a static design and the comment about internal clock multiplcation is plain wrong. I had to write a grant application comparing processors mid 80's the real difference was that Z80 et. al. had clock dividers where the 6502 did not. I also have no knowledge of it ever doing 2 instructions at the same time. Archivist 23:57, Nov 13, 2003 (UTC) (For the application at the time, 6800 Z80 6802 6502 65C02(2Mhz), the 65C02 won hands down and was designed in.)

AFAIK the 6502 used a lot of dynamic logic, as was common in the NMOS days. It does not have a clock multiplier, but several phase shifted clocks that are internally generated. Check here for more information than you ever wanted to know http://impulzus.sch.bme.hu/6502/6502/6502_kapcs.php3 (oh wait, its hungarian..)
Btw, the Z80 did not have clock deviders, but a state machine. --Qdr 16:53, 13 Jul 2004 (UTC)

WDC's current line is now fully static, at least the 14mhz are from what I remember. --PZ

The NMOS processors were all dynamic; this can most easily be verified by looking at the maximum clock pulse widths in the data sheet. All of the CMOS processors other than some relatively obscure ones from Commodore Semiconductor Group were fully static. There was no clock multiplier in either. --Brouhaha 23:58, 3 September 2005 (UTC)

Terminator 6502 code

Thanks to Fixative for contributing the checksum program fact to the Trivia item on Terminator! Does someone by any chance have access to a copy of that exact code, either the complete program or the Terminator snippet? (yes, I plan to buy the DVD and press "still picture" at the magic moment, but I still think it strange that Google is unable to find me that code; also, since I was and am a Commodore man, I didn't read Nibble back in the day... come to think of it, Nibble probably never was available in Norway anyway). --Wernher 23:25, 22 Feb 2004 (UTC)

Update: Having checked out the DVD and received friendly assistance by Nibble 's founder, Mike Harvey (http://www.nibblemagazine.net), I've been able to make the Terminator item a tad more precise. However, the assembly program "OVLY OBJ" (?), which the "KEY PERFECT 4.0" checksum utility is run on in the movie sequence, is still very much a mystery. Anyone know more about this? Also, we've yet to identify the asm programs from which the other code segments are excerpted. They may or may not be from Nibble. --Wernher 21:35, 3 August 2005 (UTC)

Parts of the 6502 source code that appears in Terminator make little sense, but the labels or comments indicate that the code performs operations on VTOC (kind of FAT in 8-bit Atari filesystems). The code was printed in Polish magazine "Tajemnice Atari" (http://tajemnice.atari8.info), but I cannot remember which issue. --0xF 09:40, 12 April 2006 (UTC)

MOS Technology?

There is evidence that the company is not named "MOS Technologies", but rather "MOS Technology, inc.". See for example this datasheet: [1]. Anybody else has input on this? --Qdr 16:55, 13 Jul 2004 (UTC)

I'll have to check it in my databooks/sheets. I'd guess there's probably a reason the MOS articles started out under the "Technologies" name in the first place. --Wernher 21:34, 13 Jul 2004 (UTC)

I'm in the process of editing pages containing refrences to "MOS Technologies" to "MOS Technology", to give it it's proper name. This website has early MOS Technology, Inc. documents, dated January 1976. [2] It is a common mistake to refer to MOS as MOS Techonolgies. I for one made that mistake years ago. Saying "MOS Technologies" sounds right, where as saying "MOS Technology" sounds slightly awkward (for me at least). (Bill Bertram 00:16, 14 Jul 2004 (UTC))

Memory Access

Re: "History & Use" "The 6502 had one feature that made it particularly good for a home computer system, a small delay in which it was guaranteed to not be accessing the bus. Video display hardware could use this period to read out a line of the screen without having the 6502 pause while this happened. In general terms this sped up the performance of a system using the 6502 by about 25%." vs "Description" "Although all operations took between 2 and 7 cycles, a simplification made in design meant that the 6502 performed a memory access every cycle. According to the original design criteria this wasn't a problem due to the speed advantage of RAM over the CPU. For the microcomputers of the mid-80s this proved a serious disadvantage as slow memory access, especially in systems with a unified memory architecture, would often require CPUs to be significantly underclocked."

I wrote the latter and fully believe it to be true, based on documents such as c64doc and home computers such as the BBC Micro which shipped with 4Mhz RAM coupled to a 2Mhz 6502 so that video could be collected without undue CPU halting and the Acorn Electron which shipped with 2Mhz RAM and a 2Mhz CPU and saw significant CPU halting.

Can anybody clear up which paragraph is right?

A 1Mhz 6502 accesses memory at 1Mhz, every cycle. If you run 2Mhz memory cycles (possible even with 1970s technology), you can neatly interleave CPU and graphics. That's how it's done on the Apple II, where the CPU always runs at full speed. The C64 is similar, but the CPU is blocked sometimes (for character pointer and sprite fetches). The Atari 800 is different. The CPU and memory run at 1.79Mhz, so there is heavy contention. I suppose there is some disadvantage to the dummy cycles in that case. How much? You'd have to simulate it to find out. It's all pretty academic. Take away the dummy cycles, and the 6502 still needs to access memory most cycles. So it wouldn't really change the system designs. Mirror Vax 28 June 2005 11:59 (UTC)

So you'd entirely disagree with the statement "The 6502 had one feature that made it particularly good for a home computer system, a small delay in which it was guaranteed to not be accessing the bus." as the only time in which the CPU is not accessing the bus is time in which its clock is stopped?

The way I read the two allegedly contradictory statements they are not contradictory—rather, they reinforce/confirm each other. I agree with all the other posters that it was possible to interleave CPU and video access to memory and thus totally prevent CPU halting. This is only possible if you can synchronize the CPU and video clocks (with the right phase) so that the CPU is never accessing.memory when the video wants it. For this you would have to know that the CPU is not accessing memory during some specified part of each cycle—not that it doesn't access memory at all during that cycle. That's why the BBC needs 4MHz memory for a 2MHz processor: during each processor cycle there are two memory accesses, one from 2MHz CPU and one from 2MHz video. The guarantee you need is that the access from the processor will happen only at the right point in the cycle, so it can be interlaced with the access from video without collision. This is exactly what the original paragraph said, "a [period in each cycle during] which it was guaranteed to not be accessing the bus". I'm reinstating it. —Blotwell 05:35, 17 August 2005 (UTC)

Why don't you include a little ASCII sketch of the 6502 bus cycle? Then you can make hard statements about it rather than argue about vague generalities. Mirror Vax 06:31, 17 August 2005 (UTC)

" I agree with all the other posters that it was possible to interleave CPU and video access to memory and thus totally prevent CPU halting" - that isn't really the point. The article says "The 6502 had one feature that made it particularly good for a home computer system, a small delay in each cycle during which it was guaranteed not to be accessing the bus". We have all agreed that the 6502 has no such feature. It is possible for an external bus controller to interleave accesses but this is completely independant of the hardware in the 6502. To put it another way - the sentence is clearly trying to suggest that this is something that made the 6502 more suitable for home computer systems than other CPUs. But clearly it's an implementation decision completely separate to the 6502 that doesn't favour it over the z80, 6809 or anything else. The statement is clearly 100% false as phrased and irrelevant to this article if phrased correctly. ThomasHarte 11:53, 29 August 2005 (UTC)

Furthermore, what utility does the statement "In general terms this sped up the performance of a system using the 6502 by about 25%." I only get that figure if I assume a 1Mhz 6502 outputting a 40 byte pitch display (e.g. 160 pixels, 4bpp) with 200 scanlines on an NTSC display. In other words, the Commodore 64. Given the wide variations, and regardless of the rest of the paragraph, I certainly feel this should be removed as it is impossible to come up with a meaningful generality. ThomasHarte 12:25, 29 August 2005 (UTC)

I don't understand what ThomasHarte is saying here. "We have all agreed that the 6502 has no such feature"—I certainly didn't intend to agree to this (as I understand it). The point is that there is no external bus master and the CPU never has to wait for the bus. The entire system is synchronous and the bus operates at twice the CPU frequency, thus it is always free when the CPU wants it but it alternates this with servicing other requests from the video CRTC. The CPU and CRTC are synchronized using their external clock inputs. This setup would not work if the CPU were not designed to guarantee its bus accesses to be synchronous with the external clock, hence it is a feature of the 6502 design. —Blotwell 05:18, 1 September 2005 (UTC)

Apologies, I will try to explain in a clearer fashion. It's a shame that unlike other additions I might make to wikipedia, nobody is in the position of being able to come back and reformat my thoughts! I believe I have been in the wrong here, and I hope to explain the confusion and, in a minute, have a hack at modifying the wording of the article so that people who think as I do will not be confused in future. This message is meant to explain the edit, and I hope it will be acceptable to all. I'm just going to go ahead and do it because it is a wording fix and I am not going to attempt to remove or add new information.

You say the following: "The point is that there is no external bus master and the CPU never has to wait for the bus ... This setup would not work if the CPU were not designed to guarantee its bus accesses to be synchronous with the external clock, hence it is a feature of the 6502 design."

The article says: "The 6502 had one feature that made it particularly good for a home computer system, a small delay in each cycle during which it was guaranteed not to be accessing the bus."

These statements are not contradictory. But the article continues "Video display hardware could use this period to read out of screen memory without having the 6502 pause while this happened." For me, pause and delay are synonymous. For example, Roget's thesaurus (with 1991 supplement) lists both 'pause' and 'delay' as alternatives to 'hinder'. So the meaning of that text becomes confusing as it appears to say "The 6502 had one feature that made it particularly good for a home computer system, a small delay in each cycle during which it was guaranteed not to be accessing the bus. Video display hardware could use this period to read out of screen memory without having the 6502 delay while this happened."

Confused by this I note your comment "If you run 2Mhz memory cycles ... you can neatly interleave CPU and graphics." which further implies you have some sort of external logic as I read the sentence as being from the point of view of whatever is running the clock. Hence "YOU can neatly interleave" strongly implies something external to the CPU doing some smart interleaving of memory access.

Anyway, it was because of my general confusion that I first posted here, then only commented out the sentences that I believed you had confirmed as incorrect rather than removing entirely and I thank you for clearing up this topic. I hope that I am about to give some the article the benefit of this discussion! ThomasHarte 23:05, 1 September 2005 (UTC)

Excellent, I think this is what talk pages do best—and it certainly isn't news to me that my explanations are incomprehensible the first few times I try to write them :). I notice you've left unaltered what it sounds as if you might agree is the most poorly-chosen word in the paragraph—the "delay" in "... a small delay in each cycle ...". As you point out, the CPU isn't waiting for the bus in that time, it's probably doing something productive like instruction decode or arithmetic/logic. (It would be different things in different cycles since one instruction took 2–7 cycles to execute.) What would a better expression be? A "short period during each cycle"? —Blotwell 10:46, 2 September 2005 (UTC)

You're right, my edit is somewhat imperfect. I think period is right as a direct replacement word. Probably the best replacement would be if anybody knows exactly what period of a cycle the 6502 is accessing the bus? ThomasHarte 17:18, 2 September 2005 (UTC)

Here's a datasheet I believe to be relevant. I couldn't make anything meaningful out of it, you're welcome to try. —Blotwell 12:39, 3 September 2005 (UTC)

The 6502 "expects" to have control of the bus during the entire clock period. It starts driving the address bus and R/W* partway into phase one; for simplicity some hardware designs don't require them to be valid until the start of phase 2 even though they will actually be valid some time before that. The data transfer occurs at the end of phase 2. In systems like the Apple II, external multiplexers and buffers are used to keep the 6502 from driving the memory address and data during phase 1, in order for the video circuitry to use the memory during that time. However, there's nothing in the 6502 design that would preclude more complicated hardware from using more or less than half of the cycle for other purposes, provided that on reads the memory data makes it to the 6502 within the necessary window of setup and hold time. The use of phase 1 for an alternate bus master is simply a convenient way of designing the hardware. As Blotwell previously pointed out, this is a matter of synchronous bus design rather than any designed-in "delay" in the memory cycle. Inside the chip, it simply takes a certain amount of time from the leading edge of phase one until it can provide a valid address on the bus, and clever designs stole a portion of the cycle. There were 8080 and Z-80 based systems that did similar things, but the designs were more complex because although the 8080 and Z-80 did have synchronous busses, they used more than one clock cycle per memory access. --Brouhaha 23:37, 3 September 2005 (UTC)

"Inside the chip, it simply takes a certain amount of time from the leading edge of phase one until it can provide a valid address on the bus" - I feel I am probably now straying far from the topic of "how to clarify things in the article" but does this mean that a 6502 rated at 2Mhz which expects to reach phase 2 after 50% of a cycle will reach phase 2 after only 25% of a cycle if the input clock is 1Mhz?

"There were 8080 and Z-80 based systems that did similar things, but the designs were more complex because although the 8080 and Z-80 did have synchronous busses, they used more than one clock cycle per memory access. " - is this the reason that, e.g. the Amstrad CPC is usually said to round instruction lengths up to the nearest 4 rather than having the somewhat more complicated timing characteristics of a ZX Spectrum (which just raises the halt line when a clash is detected and otherwise operates a floating bus)? ThomasHarte 14:38, 4 September 2005 (UTC)

"but does this mean that a 6502 rated at 2Mhz which expects to reach phase 2 after 50% of a cycle will reach phase 2 after only 25% of a cycle if the input clock is 1Mhz?" - Yes, in a sense that is true., depending on the external hardware. The actual timing of the phases is determined by the external clock input (known as phase 0). The 2 MHz rated part has minimum clock high and low specifications of a little less than 250 ns, vs. a little less than 500 ns for the 1 MHz rated part. Most commonly the 6502 is run on a symmetric clock, but it is also possible to run the 2 MHz part on a clock that is 250 ns low, 750 ns high (1 MHz), or any other asymmetric timing that doesn't violate the minumum clock low and high times. The 6502 won't "reach phase 2" until shortly after the rising edge of the clock phase 0 input, but on a 2 MHz part that can happen about 250 ns after the falling edge of the input, even if the actual frequency is substantially lower than 2 MHz.

The 2 MHz part also has a better (lower) maximum address delay specification (the maximum time from the falling phase 2 clock edge to the address bus and R/W* signals being valid), so even if you run the 2 MHz part at 1 MHz, you potentially can use slower memory parts with it (depending on your hardware design) because the address is valid for a larger portion of the cycle. In practice, though, many hardware designs simply assume that the address will be valid by the rising edge of phase 2, which is guaranteed by the specs because the maximum address delay spec is less than the minimum clock low time spec. --Brouhaha 21:29, 4 September 2005 (UTC)

Despite the discussion above, the misleading paragraphs were still in the article, so I cut them. To summarize:

There is never a time when the 6502 isn't using the bus.
Some bus cycles are useless, "dummy" cycles. Most are real. For example, LDA $1234,x requires four memory accesses (3 for the instruction and 1 for the load) and takes four cycles, except when it crosses a page boundary, in which case there's an extra cycle. With or without the dummy memory accesses, the 6502 - or any cacheless CPU - is memory dependent, and obviously cycle-stealing DMA is going to effectively halt the processor. Mirror Vax 13:17, 21 October 2005 (UTC)

Huh? Pursuant to the discussion above, the misleading paragraphs were carefully reworded to, I thought, everyone's satisfaction. So I reinstated them. If you have a problem with their wording feel free to modify them, but don't just remove the information. —Blotwell 10:54, 19 November 2005 (UTC)

The information is not consistent with Brouhaha's description above, or my summary. Perhaps you could point out where anyone agreed with the "carefully reworded" version? Mirror Vax 20:31, 19 November 2005 (UTC)

If anything needs to be said about it, the significant fact about the 6502 (and 6800 and 6809) is not that they only need memory data during part of a clock cycle. That's true of all microprocessors. What made interleaved video easy is that all 6502 memory cycles take exactly one clock cycle (unless external hardware requests wait states), so the memory is used by the processor with consistent, uniform timing. (Some processor cycles actually ignore the data from memory, but the plain 6502 doesn't provide any indication of this to the external hardware.) By comparison, on an 8080 or Z-80, memory cycles can take from 2 to 5 clocks, so the processor requests for memory occur at less predictable times.

However, I'm not completely certain that the main page needs a description of this at all.--Brouhaha 03:48, 20 November 2005 (UTC)

Incidentally, the MOS ~~65SC02~~ eliminates most (all?) of the 'dead' cycles. The datasheet claims a 25% performance improvement at the same clock frequency. Note that this in no way ameliorates the so-called "serious disadvantage" (according to the other wrong paragraph) of accessing memory every clock cycle (which is shared by cacheless CPUs in general). Mirror Vax 06:40, 20 November 2005 (UTC)

Whoops, make that the 65CE02. Mirror Vax 00:17, 27 November 2005 (UTC)

MHz

Didn't the earlier 6502s run at 1.024 MHz (i.e. 1024 Hz), not (unless you're rounding) 1MHz (i.e. 1000 Hz)? I recall seeing "1.024 MHz" in one of my Apple ][+ manuals, but I think it's in landfill. Just wondering; Binary_prefix indicates Hz is always in decimal.

The rating was 1 MHz exactly. Apple ran it very slightly above the rating, so technically it may have been "overclocked". It's also possible that Apple obtained a specification waiver from the manufacturer.

The processor clock cycle timing in the Apple II was not constant; it consisted of a repeating series of 64 "normal" cycles followed by a single "long" cycle. This was done in order to keep the color carrier phase constant for each scan line; in a normal NTSC signal there are 227.5 cycles of the color carrier per scan line, so consecutive scan lines within a field have opposite carrier phase. In the Apple II, there are 228.0 ccyles of hte color carrier per scan line, and in that same time there are 65 processor cycles.

The "normal" Apple II CPU cycle is 3.5 cycles of the color carrier (~977 ns, ~1.023 MHz), and the "long" cycle is 4.0 cycles of the color carrier (~1117 ns). Thus the average cycle time is ~979 ns, which is ~1.020 MHz.

It has always bothered me that most microprocessor timing specifications give a hard limit on frequency (or equivalently, cycle time) that is an "exact" frequency, e.g., 1 MHz, 1.5, 2.0, 4.0, etc. Thus if you use a 1 MHz crystal oscillator with a 1 MHz microprocessor, there's about a 50% chance that you're overclocking the processor, due to the tolerance of the oscillator frequency being distributed both above and below its nominal frequency. It would technically be more appropriate for the microprocessor vendors to spec (and test) to perhaps 0.5% high, so that a crystal at the nominal frequency can guarantee operation within spec. --Brouhaha 23:32, 10 March 2006 (UTC)

When you see in a spec that a part is rated at xMHz that means that the part is tested beyond that frequency and it is guaranteed to work at that frequency in all operating conditions (i.e. supply voltage / temperature / crystal tolerance).89.137.187.188 (talk) 15:28, 4 April 2008 (UTC)Apass

Branch range

"Relative was used for conditional branch instructions, which could move the program counter 126 bytes backwards or 129 bytes forwards (commonly incorrectly documented as being 128 and 127 respectively)".

It's -128..+127 if you count from the address of the instruction that follows the branch. This is how branch ranges are normally specified for processors. Saying about 126 and 129 is thus very confusing. --0xF 09:57, 12 April 2006 (UTC)

Agreed. The offset is added AFTER the program counter was incremented with the branch instruction's 2 bytes. Jan olieslagers (talk) 13:55, 22 May 2010 (UTC)

Non-Wikipedia Style

The entire style of this article is very strange for Wikipedia. The most serious problem is the informal and un-encyclopedic language, as in the phrase "At first many people thought it was some sort of a scam...." The use of asterisked footnotes (without even #anchor links) is also non-standard and off-putting for a Wikipedia article.

Was this information adapted from some other, unattributed source? (I know the FOLDOC entry is attributed, but very little of this article comes from that entry.) Is there a possible copyvio here? Falcotron 04:48, 18 June 2006 (UTC)

I also suspected copyvio, but didn't turn up anything that substantiated that. The asterisks first appeared in this edit. While they do appear to be a well-meaning edit, they severely break style and just don't belong. Best course of action is probably to work the important bits into the normal text. Aluvus 03:51, 20 July 2006 (UTC)

I'm the one to blame for the asterisked footnotes — they were an attempt to make the notes more "local" (i.e closer to the text they aim at), as I find it somewhat ugly that every footnote ends up at the end of the whole article. However, as there are probably no standard way to achieve this (?) it's probably better to integrate them into the main text, as suggested. Still, I must say I find factual errors much more problematic than errors regarding style, conventions, and language ;) — my edits actually corrected a few, quite severe, technical errors and misconceptions. -- HenkeB 02:07, 23 July 2006 (UTC)

Opcodes

In "Dubious Features": The 6502's instruction decoding is implemented in a hardwired logic array (similar to a programmable logic array) which is only defined for 151 of the 255 available opcodes. The remaining 105...

But 151+105=256, not 255. 256 makes more sense, and saying "255" is an easy error to make. I would modify the page but I don't know anything about the 6502. Elektron 13:59, 18 June 2006 (UTC)

I started programming the 6502 back in the 70s, so I took care of it. :-) --Dennette 11:30, 21 June 2006 (UTC)

I love how it describes the strange actions. It'll either do nothing, or do everything, or crash :)

Derivatives & Variants section needed

6502B, C

I know there were addition 6502 chips, such as the B and C revisions. The C had some additions asked for by Atari, and they used this chip in several of their 8bit systems. Not sure who (MOS or WDC) created it. Would be nice to have this info included.

If memory serves after all those years, 6502B was 2Mhz and 6502C 4MHz. These designations may however have varied between manufacturers. —Preceding unsigned comment added by Jan olieslagers (talk • contribs) 13:48, 22 May 2010 (UTC)

6510 and 6512 links/descriptions needed

I added a small section on the major 6502 variants, the MOS Technology 6507 used in the Atari, and so on. The MOS Technology 6510 and the 6512 (which required an external clock).

BCD status flags

In "Dubious Features": The N (result negative) and V (sign bit overflow) status flags are invalid while the processor is operating in BCD mode. Only the Z (result is zero) and C (carry) flags are valid. This was also fixed in the CMOS derivatives.

In official datasheets is stated that N, V and Z flags (are) invalid in decimal mode. (W65C816S 16-bit Microprocessor p. 56). Moreover the Z flag bug is used in processor type detection routine to distinguish CMOS from NMOS CPUs [3]. More detiled information can be found here. Any suggestions why previous statement including Z flag being invalid was removed? --Laoo 13:30, 10 January 2007 (UTC)

No objections so I've fixed. --Laoo 14:12, 24 March 2007 (UTC)

The "official documentation" statements regarding the validity of the Z flag in BCD mode are wrong and have been so for many years. In fact, the Z flag is *always* valid, whether the MPU is in binary or BCD mode. For example, consider the following code snippet:

CLC SED LDA #$50 ADC #$50 CLD BRK

Upon execution of the above, .A will contain $00, and both the C and Z status register flags will be set. The Z flag is indeed valid, as it indicates that the result of the most recent arithmetic operation is zero. Keep in mind that a result will either be zero or non-zero, therefore Z will always correctly reflect the result.

The N flag is not considered to be valid in BCD mode because it responds to the condition of bit 7 of the most recent result, seeing it as a binary, not BCD, condition. Therefore, if N were to be considered a valid flag in BCD mode, a BCD number like $99 would be "negative," even though the concept of sign in eight bit BCD arithmetic doesn't actually exist. Ditto for the V flag, which is primarily of interest in twos-complement signed arithmetic.

BDD 14:43, 25 April 2007 (UTC)

There is a very simple proof against above statement: actually running the code snippet. I've done it and content of status register after performing it was NV1BD--C (on machine equipped with 65c816 it was -V1BD-ZC though). According to http://www.viceteam.org/plain/64doc.txt Z flag is not affected by decimal mode at all (it behaves as in binary mode). N and V flags behaves the same in SBC. In ADC they are set before high nibble fix-up.

Regarding validity of N it's of course true that it has no meaning in eight bit decimal mode where numbers are positive, but 6502 designers decided that it should behave the same as in binary mode i.e. reflect most significant bit of the result and while it does not do it properly it has to be a bug. Furthermore Bill Mensch thought the same fixing it in CMOS derivatives (but leaving V flag intact - it has the same meaningless result as in 6502).

Laoo 17:58, 7 May 2007 (UTC)

The Zero status flag is standard. It is set to 1 when any arithmetic or logical operation produces a zero result. It is set to 0 when any arithmetic or logical operation produces a non-zero result.

Reread the wording: It is set to 1 when any arithmetic or logical operation produces a zero result. Note that Dr. Leventhal does not say anything about whether the MPU is running in binary or BCD mode. That's because result zero means the exact same thing in either mode.

I don't know what it is you are using to support your theory, but if it is one of the many 6502 simulators that you can download from the Internet you should consider that a lot of them do not accurately portray the NMOS 6502's operation.

The only significant effect of operating in BCD mode is the automatic generation of half-carry or half-borrow and the limitation of the accumulator to the range $00-$99. Full carry still affects the C flag and result zero still affects the Z flag. The N flag will be set if the seventh bit in the accumulator is set, which, as is well known, is anomalous in BCD mode on a NMOS part.

BTW, I started writing 6502 code in 1977 (on a Commodore PET) and still do now and then. I was published a number of times in Transactor magazine and my Commodore 128 BCD math package found its way into a variety of programs. There are numerous instances in that package where result = zero while in BCD mode was depended upon. I'm sure I would have heard about it if there was something wrong with my code.

BDD 01:57, 10 May 2007 (UTC)

I have enormous respect that you have been writing in 6502 assembly before I was even born, but facts don't lie. Maybe it was a matter of coincidence that your software haven't broke.

Fact that N and Z aren't properly set is not intentional - it was a bug that was fixed in 65c02/65c816. So no wonder that official programming manuals don't cover it.

I am from Poland where is a strong Atari community which members still have real hardware and some of them (including me) have 65c816 upgrades. So I've run a test of adding each and every of 32896 distinct combinations of two bytes in decimal mode on REAL Atari: one equipped in original Rockwell 6502C and one with WDC65C816. Results can be (temporarily) found on my site.

With these tests it is clear that Z flag is not affected by and decimal correction and N flag is set before high nibble fix-up.

Laoo 13:42, 10 May 2007 (UTC)

errata: 6800 clock, 16-bit 6502, clock interleaving

    re 6501, the 6800 was an older nmos design which required high

power clock driver (6875 chip, which also provided clock stretch for wait states) and original chips had internal substrate bias generator.

The 6800 depended more on microcode (like 8080) and took more cycles

for instructions eg 16 bit index was 2 8bit registers through 8 bit ALU. (Motorola used 3 16bit ALUs in the microcoded "32 bit" 68000, per the

specs on the PC/370 emulation card.) 6502 took a full cycle for wait
states, on board clock (and looser tolerance on phase1 and phase2, like
6801) and per the Synertek manual used fewer cycles/instruction. (Most
people used text apps at the time, original PCs in 1980 came with

massive 16K and 1984 MACs came with 128K, 4k systems in 1977 when CPU debut.)

    Lit from MOS Technology second sources, like Rockwell lists 6512 as

6800 replacement part, their 6501 and 6511 are one chip 6502 microcomputers.

As to bus interleaving, Rockwell listed 65C102 and 65C112, later combined into a single "dual core" R65C29. One problem with interleaving is read-modify-write instructions, these processors had locking mechanism when these instructions ran. The most famous interleaved system of course is the Radio Shack Color Computer. (The Co-Co still lives and OS/9 resulted.) It used a 6809, which is pertinent here as both a 6502 successor (16bit X and Y registers) and 6800 successor (2 accumulators) (adding the extra instructions with escape codes like Z80), more like "source code compatible". The interleaving method was described in the 6545 literature (6545 was the graphics controller in the first IBM PCs). The Co-Co used a 6883/74LS783 DRAM controller and memory management chip to synchronize the 6809 and 6847 graphics controller. —Preceding unsigned comment added by 74.61.138.159 (talk) 07:11, 3 February 2008 (UTC)

"Original research" complaint

The section complaining of "original research" essentially REQUIRES such, as illegal/invalid opcodes were never intended to exist, let alone be used by end users, and thus were never officially or even unofficially recognized by primary sources. There is considerable research on these by members of reverse-engineering and especially computer and console emulation persons and groups; the thing has been picked completely apart, and "original" or not, is extremely accurate and more than likely the best we'll be getting. It will have to do, as this is necessary to record, as these illegal opcodes were used somewhat extensively by many programmers for various purposes. — [Unsigned comment added by 68.10.18.240 (talk • contribs) 23:50, 24 April 2010.] — [Unsigned comment added by 68.10.18.240 (talk • contribs) 23:50, 24 April 2010.]

It's OK if there is no primary source, but there should be secondary sources. Given that several of the editors who worked on this section (at that time called "Dubious features") in 2007 are still active (e.g. Bigdumbdinosaur, Laoo and Dennette), it's not unreasonable to ask them to source their contributions. - Pointillist (talk) 00:00, 25 April 2010 (UTC)

If someone researched the illegal opcodes and published an article in a magazine, or even on a web site, that qualifies as a primary source rather than original research as long as the reference is added to this article by an unrelated editor. For example, a published article about the ENIAC computer, written by someone who used it, is a primary source even if that person wasn't the designer of ENIAC. There were in fact published articles about the illegal opcodes of the 6502, e.g., in the March 1981 issue of Apple Assembly Line. --Brouhaha (talk) 06:53, 26 April 2010 (UTC)

Speaking as someone who implemented a very full-featured 6802-line emulator (including various undocumented instruction sets, features on later chips, etc.) and then used it in an NES emulator - albeit many, many years ago - I can vouch for most of the claims about undocumented opcodes and memory addressing bugs. Without them, later NES game code just wouldn't work - it expected the bugs to be there and took advantage of them. I wish that I could find the documents I originally used... I may have to do research on this. Sorry I'm not actually DOING it. I don't suppose my working code (which provides a clearly, easily readable C++ class that clearly separates undocumented instructions and their functions) could act as a primary source if I (managed to find and then) published it? Since it works? --Pokeme444 (talk • contribs) 06:40, 4 May 2010 (UTC)

The "undocumented" 6502 instructions have been documented for decades. I think a person should still keep the two group seperate, but it should be fine to document all aspects of well known "undocumented" features. Sbmeirow (talk) 05:28, 23 July 2010 (UTC)

Zero page

Quoting the "Technical description" paragraph, I disagree with the wording "as well as its 256 zero-page "registers". Surely the zero-page is mostly considered as 128 16-bit registers? Jan olieslagers (talk) 13:42, 22 May 2010 (UTC)

I would say it is completely wrong to refer to them even as "registers". Mostly considered? Citation please. Page zero can consist of bytes used for indexing, pointers, etc; words for indirect memory addresses, or data stuffed there by an operating system as the zero page addressed opcodes are a little bit quicker. To support this, please refer to the BBC Micro Advanced User Guide (PDF at http://bbc.nvg.org/doc/BBCAdvancedUserGuide-PDF.zip) pages 267 through 272, which describes how the BBC MOS uses these locations.

Page zero has no specific layout, it is just 256 bytes which relate to some special 'faster' addressing modes in which the upper byte of the address is assumed to be zero. These bytes have no meaning other than that which you assign yourself in your code, so to call these locations "registers" is erroneous.

HeyRick1973 (talk) 04:36, 23 July 2010 (UTC)

Registers are typically located in the internals of a microprocessor, where as zero-page is just RAM that can optionally be access using a special group of instructions. Zero-page should NOT be called registers in any way!!! Sbmeirow (talk) 05:25, 23 July 2010 (UTC)

Most of this is picking on terminology. My first aim was to improve the text as published. I do agree "registers" are internal to the CPU. Still, if one wishes to index a table of more than 256 bytes, the only way on the 6502 is to put its base address in two subsequent zero-pages bytes, which behave very much like an index register. Well it's not the only way of course, but it IS by far the most efficient. Also, I agree my words "mostly considered" are a poor choice. How then to amend the original text? Something about "16-bit pseudo-registers in zero page"? Jan olieslagers (talk) 06:00, 23 July 2010 (UTC)

Back in the day, I likely wrote maybe over 1000 pages of assembler code (so much that I don't even know), so I know the 6502 upside-down and backwards, so I know you are not targeting me as a reader, and that's fine. I just recently started reading the 6502 page, thus the only reason for replying to your comments, and not picking on you. For personal engineering documents, I like to use the phrase "conceptually like..." so that way people don't whine as much about it. I'm kind of in a hurry to get to work, so one thought is something along the lines of "Think of them conceptually as 16-bit pseudo-address-registers that are stored in zero page". I need to think about it more. Need to run. Sbmeirow (talk) 14:14, 23 July 2010 (UTC)

It was quite common for computer designers of the 1960s and early 1970s to treat an area of low memory as registers and describe it that way. The 6502's Zero Page addressing modes strongly resemble those usages. Wozniak's SWEET16 pseudo-machine for the Apple II did exactly that, and called $00-$1F "registers", but MOS Technology never used the term for the Zero Page. RossPatterson (talk) 13:12, 7 August 2011 (UTC)

Restrictions on efficient high-level language implementation

It should be mentioned that compared to competitors such as the Z80, the 6502 design introduces some hurdles to the effective implementation of compilers that compile ALGOL-derived languages (such as Pascal and C) to its native machine code. For example the lack of real 16-bit registers; the lack of an un-indexed absolute indirect mode (except for jumps), which makes it necessary to move the pointer to the zero page and clobber an index register for such accesses; the short possible distance of conditional branches; and especially the limited hardware stack size, which makes it necessary to manage the high-level stack "by hand" as e.g. the cc65 compiler does. So if you know a good source for this (I don't) please add it. --

77.189.120.126 (talk) 08:48, 28 June 2011 (UTC)

The Z80 was introduced later. The 6502 was introduced as a competitor to 6800 and 8080, and (barring WP:OR), the most apt comparisons are against the latter.

TEDickey (talk) 10:50, 28 June 2011 (UTC)

The 65C816 addresses some of these issues with its selectable 8-16 bit registers, 16 bit stack pointer, ability to relocate zero page anywhere in $00000-$00FFFF, and new stack-oriented instructions (e.g., LDA (<offset>,S),Y, which allows one to treat the stack as a portable zero page indexing resource). WDC produces a C compiler that exploits these capabilities to produce compact and efficient code.

As for the above individual complaining about inefficient Pascal or C compiler behavior, keep in mind that at the time, the Z80 was much more costly than the 6502, and measurably slower at the same clock speed (the Z80's interrupt latency is feeble in comparison). It's really not a good comparison to make, since no microprocessor from that era was targeted to the C and Pascal mindset.

Bigdumbdinosaur (talk) 05:21, 7 August 2011 (UTC)

Interrupt processing

I've updated the interrupts page with some detail about the 65C816's behavior when ABORT is asserted, as well as the extra steps taken by the '816 in response to any interrupt.

Bigdumbdinosaur (talk) 05:13, 7 August 2011 (UTC)

Suggest merge

I suggest merging in what ever is unique in the couple of paragraphs at MOS Technology 6501. That version of the chip never saw widespread use and its story is already described here. --Wtshymanski (talk) 16:39, 19 September 2011 (UTC)

Strongly support the suggested merge. The 6501 and 6502 are really minor variants of the same chip, and "6502" is the generic name that most people use to describe the entire family. If it is merged, there should be a redirect from the old 6501 page to the 6502 page. --Guy Macon (talk) 17:45, 19 September 2011 (UTC)

Not a proposal so much as a topic for discussion — would it also be worth merging with the WDC 65C02? – Kieran T ^(talk) 21:17, 19 September 2011 (UTC)

Support: The 6501 and 6502 were developed at the same time and both were introduced at WESCON in September 1975. See the introductory advertisement in the article. (It is fiction that the 6502 was developed in response to Motorola's lawsuit.) The 6501 stub should be merged into the 6502 article. The 65C02 was developed at a different time by a different company. -- SWTPC6800 (talk) 22:26, 19 September 2011 (UTC)

Need verifiability in the bugs & quirks section

Many interesting and extremely specific bugs and quirks. I am assuming these have been added from a reliable source, maybe some errata or pages in a book or manual. I have tagged the whole section as needing references -- perhaps this is easily addressed with one master reference (if they're all within it) or, worst case, a reference per bug listed. --Ds13 (talk) 05:35, 6 November 2011 (UTC)