Talk:MOS Technology 6502

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (marked as High-importance).
 

Error about nature of MDT-650[edit]

However, this left MOS with the problem of getting developers to try their processor, so Peddle designed the MDT-650 (for "microcomputer development terminal") single-board computer. Another group inside the company designed the KIM-1, which was sold semi-complete and could be turned into a usable system with the addition of a 3rd party computer terminal and compact cassette drive.

The MDT-650 was NOT a single board computer. The following article [1] appeared in the April 1976 issue of Microcomputer Digest (Vol 2 Num 10).

MICROCOMPUTER DEVELOPMENT TERMINAL
MOS Technology has announced the MDT650 Microcomputer Development Terminal for modeling new 650X designs. The MDT650 terminal is used to evaluate and debug the user's programs and system hardware. The unit can be configured to a wide range of designapplications through user-system emulation.
The MDT650 incorporates a completely separate processor and bus structure for application emulations, thus eliminating emulator executive overhead time during real time execution.
Interaction with the MDT650 is normally with the integral keyboard/display. However, a TTY or other terminal device can be used. The expandable port configurations are TTL compatible.
The standard MDT650 system allows the user to assign up to 65K of memory as desired (with independent address and data bases). The ROM resident system monitor includes all necessary functions for program loading, debugging, and execution. A resident assembler may be used to assemble machine instructions. Interpretation of machine codes is linked to original op-codes, labels and mnemonics. A resident editor provides source language editing capability.
The MDT650's bare system price of $3950 includes dual microprocessor module, RAM memory module, program trace and address trap board, I/O b~ard, resident monitor ROM module; chassis with 14 board slots, power supplies, cabinet, keyboard and display, system monitor, assembler text editor, user's manual, MCS650 assembly language programming manual, and MCS650 assembly language reference card.
Options planned include a PROM programmer available for 82S115, 2708 or 1702A, wirewrap board for custom designs, extender board module, address and data bus display board, 4K RAM board, 8K PROM board, 2K RAM/4K PROM board, I/O board, user RAM write protect option, high speed ports for printer, card readers, floppy disc interface, In-Circuit Emuiator, and system s6ftware source listings.
MOS Technology reports availability of the base system in the second quarter, 1976 with the various hardware options becoming available in the second and third quarters, 1976.

Also, the MDT-650 was NOT designed by Peddle, as stated on Page 25 of "Commodore: A Company on the Edge", but by an outside firm by the name of Monolithic Systems.[2] — Preceding unsigned comment added by 72.190.74.67 (talk) 14:29, 15 July 2012 (UTC)

Pronunciation[edit]

Who says it's supposed to be pronounced "sixty-five oh two"? I'll pronounce it any way I want - its a number. — Preceding unsigned comment added by 110.174.108.101 (talk) 06:57, 16 August 2014 (UTC)

I agree that "sixty-five-oh-two" isn't the only way, most I know call it the "six-five-oh-two" so that comment should be removed from the article. But untold numbers of engineers have used just one of these two for over 35 years so a convention *has* been established. You don't pronounce it any way you want though, you adhere to pre-taught conventions to ease conversation with others so please don't demand freedom that you don't need. It's not a numerical quantity, it's used as a proper noun for this microprocessor. Try calling a 7432 logic IC a "seven--forty-three--two" in conversation and see how sharply you get stopped: everyone says "seven-four" or "seventy-four" something. The article is trying to inform typical usage, incorrectly. It should still be scrubbed. — Preceding unsigned comment added by ToaneeM (talkcontribs) 09:37, 30 April 2015 (UTC)

Retracting my previous point, I don't think that the comment has to be scrubbed from the article. But I maintain the two pronunciations of "six-five-oh-two" "sixty-five-oh-two" are the two and should stay.

Buggy example code[edit]

The code that is supposed to move a block of memory is buggy in two was because SRC's and DST's high bytes are increased when the Y register (i.e. the counter) turns zero - this only works when the counter is a multiple of $100. Once this is fixed, I'm not sure whether SRC's and DST's high bytes can then be increased at the same time as their overflow may be different from each other and from the counter. — Preceding unsigned comment added by 87.151.165.189 (talk) 23:36, 3 October 2014 (UTC)

The original sample was uploaded by Loadmaster on 1 June 2013 and corrected on 16 June 2013. [1] A lot of random users have hacked at it since then. -- SWTPC6800 (talk) 01:24, 4 October 2014 (UTC)
The purpose of the example code is to illustrate to the reader what 6502 assembler source code and opcodes actually look like. Also note that code need not be optimized, for the same reason. In other words, feel free to correct the code, but don't be obsessive about the operational details of it. — Loadmaster (talk) 20:06, 8 October 2014 (UTC)

It's still buggy, very buggy. I'll try to rewrite it when I am at a desxktop Si Trew (talk) 17:58, 26 February 2016 (UTC)

I changed the wording to say a buggy implementation that attempts to copy, that was reverted. I've thus removed the whole section, because if it is saying it is an implementation of memcpy – well it is, but a buggy one – then that is misleading our readers. WP:RS please if it is added back; or talk to me. I have coded up an example that actually works while attempting to keep the brevity of the original. Si Trew (talk) 16:57, 27 February 2016 (UTC)

Please, by all means, add your code example to the article. It's my hope that *every* CPU article can have a small sample code example. — Loadmaster (talk) 20:52, 5 April 2016 (UTC)

Apple II accelerators[edit]

Every computer and microprocessor ever made was soon too slow for users. The 6502 was used in more applications than home computers and Apple was only one provider. I am unsure that the Apple II accelerators article deserves such a prominent link in the 6502 article. -- SWTPC6800 (talk) 17:35, 23 March 2015 (UTC)

Agreed, although some content regarding acceleration should remain in the article. Accelerator boards and drop-in chips were also fairly common for Commodore 8-bit systems. I'd suggest that we strike the Apple II specific text and "main article" link, while retaining the remaining text (copyedited as needed). // coldacid (talk|contrib) 17:46, 23 March 2015 (UTC)

Seealso "For the year 6502"[edit]

Coldacid wrote on my talk page:

Hi Jeh, I just reverted your good-faith edit of the redirect notice to the MOS Technology 6502 article. Since 6502 redirects to the article, it's best to leave in the notice for those few people who do come to the page expecting the year instead. // coldacid (talk|contrib) 22:19, 23 March 2015 (UTC)

You don't really expect me to think you're serious, right? Can you think of any reason that someone might be looking for the specific year 6502? Let's see, is that year mentioned in the 7th millennium article? No. Again, per my original edit comment: Don't be ridiculous. Jeh (talk) 22:23, 23 March 2015 (UTC)
Just because something is very unlikely to happen doesn't mean it won't happen. There's no harm done in leaving the message there in the off chance that it does happen. And I'll thank you to be more civil in your responses and edit summaries. Please don't become the next Wtshymanski. // coldacid (talk|contrib) 22:33, 23 March 2015 (UTC)
The harm IMO is exactly that it looks ridiculous and silly, and it may waste a reader's time. (Reader: "Why do they think anyone would be looking for the year 6502?" (clicks on the 7th Millennium link) "Nope, nothing special about that year. What a waste of time." And don't say "no one will do that"; that's what I did.)
So, it's not only ridiculous and silly, it's misleading, in that it implies that there is some significance to the year 6502, and that there is some mention of it in the 7th millennium article. For those who come here looking for the chip, I do not think that the value of serendipitously learning "nope, nothing interesting predicted for the year 6502" outweighs the waste of time or the annoyance. It devalues the article, and by extension, Wikipedia. We're trying to look credible here. The probability that anyone has any reason to look for the year 6502 may not be zero, but it would be indistinguishable from zero even in 128-bit floating point. Do we do this for 6800, 8080, 8086? No. (And please don't.) Would we do it for 2525, if there was a chip of that number? Yes, because there are at least two well-known cultural references to that year. Lacking such for 6502, this seealso should go. Jeh (talk) 22:52, 23 March 2015 (UTC)
From a June 2014 Intersil Data Sheet – "HA-2520, HA-2522, HA-2525 comprise a series of operational amplifiers delivering an unsurpassed combination of specifications for slew rate, bandwidth and settling time." If the 2525 op amp becomes as popular as the 741, it may get an article. - SWTPC6800 (talk) 00:47, 24 March 2015 (UTC)
I'd say "as popular as the 741" is a pretty high bar! Jeh (talk) 03:33, 24 March 2015 (UTC)

The link to the 7th millennium sounds like an April Fools' joke. It was added on March 13, 2015 by Georgia Guy.[2] The User_talk:Georgia_guy page has several items about questionable disambiguation links -- SWTPC6800 (talk) 00:17, 26 March 2015 (UTC)

A little early, but it's possible. Since we've heard nothing from coldacid for two days, and I feel my previous point is definitive (and so far un-countered), I went ahead and re-deleted the seealso. Jeh (talk) 00:37, 26 March 2015 (UTC)
I support the removal. At first I thought it was a who care's issue, but I agree with your above comments that a link to 7th millennium at the top of this article is a waste of time: it has nothing to do with "6502". Johnuniq (talk) 00:41, 26 March 2015 (UTC)
@Jeh: After you went all off with your two-paragraph reply, I simply decided "fuck it" and not to bother further. // coldacid (talk|contrib) 02:01, 26 March 2015 (UTC)

6502acme syntax highlighting lost[edit]

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for '6502acme' was unfortunately dropped, as can be seen with the plain text formatting on this page and any others. If you want specialised '6502acme' syntax highlight support again, it will need to be added to Pygments. I changed Interrupts in 65xx_processors to use 'asm', however a patch has been merged to map '6502acme' to use the 'asm' handler, which does the right thing as far as I can see. John Vandenberg (chat) 11:42, 12 July 2015 (UTC)

Dubious reference for "the original RISC processor"[edit]

There is a claim that "A Byte magazine article once referred to the 6502 as 'the original RISC processor' ". I could not find that article in the Byte magazine archives so I reviewed the history of MOS Technology 6502 on Wikipedia.

The 17 August 2006 version of the article had this addition to Instruction set features: [3]

6502 - the first RISC µP – With link to concise 6502 programming chart in PDF (Eric Clever).[[4]]

On 12 November 2006 this was "reworded" and moved to the 6502 trivia section. [5]

A magazine article once referred to the 6502 as the original RISC processor, due to its efficient and simple instruction set and its 256 zero-page "registers." It is technically not a RISC design, however.

By 20 November 2006 it was changed to read:[6]

A magazine article once referred to the 6502 as the original RISC processor, due to its efficient and simple instruction set, as well as its 256 zero-page "registers." It is technically not a RISC design, however, as it has a number of instructions that directly modify memory (e.g. ROR <ADDR>), contrary to the basic "load/store" philosophy of real RISC processors.

On 20 February 2007 the paragraph was changed from "magazine" to "Byte Magazine".[7]

The quote started on a personal web page and was promoted to Byte magazine.-- SWTPC6800 (talk) 23:37, 12 September 2015 (UTC)

The whole section appears to me to be problematic as it then goes on to describe all the ways in which the 6502 was not typical of ISAs. Personally I think the quasi-quote is just wrong; the PDP-8 is a much better candidate for "the first RISC processor". But that's beside the point. I would drop the opening sentence and change the tone of the whole paragraph to merely descriptive without passing much judgment on its RISCness. I would also suggest that it needs far more references. Jeh (talk) 23:42, 12 September 2015 (UTC)
Removing the RISC paragraph would probably be best. I think the original idea behind the RISC comment in Byte was that the 6502 was a single-chip processor (unlike PDPs) where it was largely possible to examine a binary opcode and deduce what it was going to do from fixed-width fields (with lots of exceptions). Regardless of how it was actually implemented, one could imagine CPU hardware executing opcodes with mostly standard logic gates and comparatively little complex microcode. My guess is that the current text in the article is the result of editors adding their analysis. Johnuniq (talk) 04:54, 13 September 2015 (UTC)

Internal clock or not?[edit]

Under the 6512 heading the article says, "...instead of using an internal clock generator like the 6502." Then later under Acceleration it says, "As the 6502 is externally clocked..." So, which is it? These statements seem to directly contradict one another. 66.225.134.125 (talk) 17:56, 21 December 2015 (UTC)

Example removed[edit]

I see User:Loadmaster added a small example code on June 1, 2013, [8], and it was reverted today [9] by User:SimonTrew, with comment "RM sectiion, buggy code. Please provide a source and RS if inserting an example of what purports to be a memcpy routine". I've not looked at it in detail, but I do think short examples are useful. So if anyone wants to sort this out, whether the current or original versions are correct, or a better short example can be found, I offer this reminder here of what was removed. Tom Ruen (talk) 17:55, 27 February 2016 (UTC)

I have written a non-buggy example but my sodding laptop has not got the example I written with the opcodes in it. Here it is so far, to show my good faith:
          SRC = $80
          DST = SRC+2
          CNT = DST+2
                  
          ORG $0400

A2 00 MEMCPY LDY #0  ; Y = the number of bytes to copy this chunk; 0=256=the whole chunk

                  LDX CNT+1    ; X = the number of 256-byte chunks left
                  BNE LOOPCH   ; Not the last chunk? Copy whole chunk
          LASTCH  LDY CNT      ; Copy remaining bytes from last chunk
                  BNE LOOPCH   ; if X=Y=0, there is nothing left to copy
                  RTS          ; Done

Loop to copy Y bytes (0=256) from SRC to DST. We have a separate case
for Y=0 to keep the main copy loop as tight as possible. See Duff's device.
An equivalent, simpler version is two bytes shorter at the expense of 3 cycles
per iteration
LOOPCH DEY
LDA (SRC),Y
STA (DST),Y
CPY #0  ; Optimized version eliminates this 3-cycle compare
BNE LOOP

MOVCH LDA (SRC),Y

      STA (DST),Y

LOOPCH DEY

      BNE MOVCH
      LDA (SRC),Y ; For Y=0
      STA (DST),Y

Get ready for next pass
      INC SRC+1    ; Get ready for next chunk
      INC DST+1
      CPX #0       ; Was this the last chunk?
      BEQ LASTCH   ; Yes, copy remaining bytes from last chunk (if any)
      DEX          ; X is the number of whole chunks left
      CLC          ; Unconditional JMP to loop; Y=0
      BCC LOOPCH   ; Use relative addressing so routine is relocatable


I have made this somewhat better because I don't want to, e.g., do the optimisation of the relative jump of CLC/BCC at the end which takes the same number of bytes but fewer cycles and is relocatable – I have a version that has all the opcodes listed which I have hand-assembled and run through a simulator.

I appreciate that it is an example, but it should be a correct example, I think. I've only assembled mine, not tested it. Si Trew (talk) 18:22, 27 February 2016 (UTC)

Incidentally the routine could add back CNT+1 to SRC+1 and DST+1 before the RTS to restore their values; however it is handy that at exit CNT can point to the end of the bytes copied as a half-open range which could be useful for a subsequent copy. Si Trew (talk) 18:29, 27 February 2016 (UTC)
Also I think indirect Y addressing takes 6 cycles normally, but 7 if addition of Y crosses a page boundary - which will be true half the time (on average) with this implementation; a better implementation (like strcpy in the GCC distribution of C libraries, but not strncmp, at least not ten years ago) will hedge up to a decent boundary then copy quickly (even with just bytes copied, rather than double bytes or quadruple bytes, it saves two cycles each time around the loop at the expense of more work to do the fiddling fore and aft, which I assume we are not trying to show here). Let alone that this assumes that the source and destination do not overlap... I appreciate that is not the point of a general memmove; f'rexample memcpy makes no guarantees of that in C. Si Trew (talk) 18:48, 27 February 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Blatantly removing an entire section without some discussion beforehand is not proper WP etiquette. I provided the example code to illustrate to most interested readers what 6502 assembly code actually looks like, just like I did for various other processors. It's not critically important that the code be efficient or even useful, but rather that it be sufficiently illustrative of typical code for the processor being discussed. Yes, the code should be correct, inasmuch that the routine actually does something non-trivial. Perhaps I was a bit ambitious trying to write up a general memcpy routine on such a limited architecture; but any reasonably non-trivial example will do. As for sources, we certainly do not need to cite any particular external source just to provide a simple assembly language routine for this article. I wrote it and generated the opcodes myself (probably using an online 6502 emulator, of which several such websites are available). If anyone is concerned that any given memcpy routine won't pass muster, then I suggest providing a simpler example. But not providing some example code in an article about a CPU seems like a major omission for an encyclopedic article. — Loadmaster (talk) 21:02, 29 February 2016 (UTC)


The proposed replacement above is also buggy -- it loops infinitely for a copy 0 < len < 256 bytes. Tested under emulation. This occurs because it attempts to reuse the main copy loop for the final partial page, but there is no mechanism for it to exit again after doing so. I recommend adapting the version from this older revision: https://en.wikipedia.org/w/index.php?title=MOS_Technology_6502&oldid=622480872

It was reverted for style, but appears to be correct. Would be good to get a second confirmation before putting it back in, given the history of code samples on this page. I've repeated it below with opcodes from an assembler listing to save whoever does that some time. It is slightly weird in that it does an ascending copy by pages and a descending copy within pages, and calls within itself to reuse the same copy loop. That said, it correctly does nothing for CNT=0, copies only a partial page for CNT < 256, and does whole page copies + final page for CNT >= 256.

                         ; memcpy --
                         ; Copy a block of memory from one location to another.
                         ;
                         ; Entry parameters
                         ;      src - Address of source data block
                         ;      dst - Address of target data block
                         ;      cnt - Number of bytes to copy

                                 org     $0040   ; parameters at $0040
0040 00 00               src     dw      $0000
0042 00 00               dst     dw      $0000
0044 00 00               cnt     dw      $0000

0046                             org     $600    ; code at $0600
0600                     memcpy
0600 A6 45                       ldx     cnt+1
0602 F0 0C                       beq     memcpy_lastpage
0604 A0 00                       ldy     #0
0606                     memcpy_page
0606 20 14 06                    jsr     memcpy_loop
0609 E6 41                       inc     src+1
060B E6 43                       inc     dst+1
060D CA                          dex
060E D0 F6                       bne     memcpy_page
0610                     memcpy_lastpage
0610 A4 44                       ldy     cnt
0612 F0 08                       beq     memcpy_return
0614                     memcpy_loop
0614 88                          dey
0615 B1 40                       lda     (src),y
0617 91 42                       sta     (dst),y
0619 98                          tya
061A D0 F8                       bne     memcpy_loop
061C                     memcpy_return
061C 60                          rts

Regarding other comments: in a copy routine like this, modifying the high byte of the pointer variables and having non-relocatable code are both idiomatic 6502, and IMO should be left as-is. 24.130.133.67 (talk) 04:57, 19 April 2016 (UTC)

Example code, version 2[edit]

I added a short subroutine called TOLOWER in a new (resurrected) "Example code" section. It's short and sweet, and illustrates the immediate and indirect zero-page addressing modes of the 6502. — Loadmaster (talk) 17:49, 6 May 2016 (UTC)

Code fails with high bit characters due to signed overflow. The checks should use BCC/BCS instead of BMI/BPL. 24.130.133.67 (talk) 06:42, 21 May 2016 (UTC)

Power Requirements[edit]

My recollection of the 650x family is that the most remarkable characteristic of this processor was a phenomenally low power consumption, and broad voltage tolerance. I believe the specs on a 6503 I had but never hooked up were that it would run on under 2V and needed something like 2 mA. This made these CMOS processors applicable for a range of applications the other technologies could not touch. However, I don't have the specs at hand any more. I would hate for this aspect of these processors to be forgotten. Tomligon (talk) 01:19, 20 July 2016 (UTC)

The original processor was not massively low power about 400-800 mW. But the 65C02 was much lower power, about a mW. Datasheets are available if you google them.GliderMaven (talk) 01:45, 20 July 2016 (UTC)

Photo of 6800 board[edit]

Hi. Why is there a photo of a 6800 demonstration board? Although some of the same engineers designed both, I don't think it's relevant and it should be removed. - Richard Cavell (talk) 17:18, 12 January 2017 (UTC)

You mean the “Motorola 6800 demonstration board built by Chuck Peddle” in the “Origins at Motorola” section. This shows that Chuck Peddle was very familiar with the 6800 processor while he worked at Motorola. There was a bit of a dust up about Chuck copying the 6800 design. The board is notable and is on display at the Computer History Museum in Mountain View, California. -- SWTPC6800 (talk) 22:56, 13 January 2017 (UTC)
Fine, but why is it in the MOS (not Motorola) 6502 (not 6800) article? The same engineer designed the Pontiac GTO and the Chevy Vega, but the Vega article doesn't have a picture of the GTO. Jeh (talk) 23:12, 13 January 2017 (UTC)
The GTO engineers did not take General Motors documents to a new company to design a lookalike car. Chuck Paddle actually built this prototype board. It shows the background experience in microprocessors of one on the 6502 designers. -- SWTPC6800 (talk) 03:17, 14 January 2017 (UTC)
I don't think that's sufficient reason. Articles should be about their subjects. The subject here is the 6502, not the 6800. Chuck Peddle is a subtopic within this article it but this demo board shows his work on a different project for another company. Per the 6800 article, he didn't design the 6800 architecture; his role in the 6502 project was different. Nobody is saying the board isn't notable or isn't worth a picture, only that its picture doesn't really add to the presentation of facts in this article. I agree that the demo board has some relationship to the 6502, but that relationship is too tenuous to support the picture being here. Why isn't there a picture of an early demo board for the 6502? Or maybe of the justly famous KIM-1? Conversely, why isn't this picture in the 6800 article? Jeh (talk) 02:08, 17 January 2017 (UTC)

Transistor count[edit]

For NMOS (and PMOS) logic, depletion mode transistors are used in place of resistors. Since they don't have any transistor function, some might not count them. That seems about the right order of magnitude to make up the difference between the two numbers, but I don't know which number is traditionally used. Gah4 (talk) 18:19, 1 May 2017 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on MOS Technology 6502. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—InternetArchiveBot (Report bug) 23:50, 28 May 2017 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on MOS Technology 6502. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—InternetArchiveBot (Report bug) 14:08, 26 July 2017 (UTC)