The 6502 microprocessor is 35 years old as of September 16th | Hacker News Reader

The 6502 microprocessor is 35 years old as of September 16th

leoville.com

66 pointspietrofmaggi48 comments

Ah, memories, memories.

The BBC micro model B was the first ever computer I programmed, at the tender age of 8 or 9. My dad was (still is, in fact) working in the computing department at a university all those years ago and managed to get us all kinds of nice little extras.

Like duel floppy drives - no tapes for me! And I didn't even realise how lucky I was until I visited a friend and we spend 20 minutes loading a game from tape. And visited another friend who saved some of his work to tape, only for the tape to get corrupted somehow, so it never loaded again.

Like sideways RAM. I always thought it was called this because it plugged sideways into the motherboard, but apparent this is not so: http://en.wikipedia.org/wiki/Sideways_address_space. This supported an extra 16kB (I think) of memory, and allowed us to run a complete word processor, and my dad used a Pascal compiler - which took up to half an hour to compile his code! I remember him setting it going over dinner... But it used to die on the first compile error found, which did tend to slow things down even more. And we had a daisy-wheel printer, which gave fantastic quality so long as you only required one font at a single size.

Then, a couple of years later, we got a 6502 co-processor connected via the 'tube' (http://en.wikipedia.org/wiki/Tube_%28BBC_Micro%29) - an expansion port on the BBC micro. This more than doubled the memory, and ran faster. But various optimizations didn't work. You could no longer write directly to screen address-space, as this was still in the hosts address-space, whereas user programs now executed in the co-processors address space. But, excitingly, there were API calls that allowed you to read/write to/from memory in the host system, so I wrote a (very simple) windowing system that stored the graphics contents beneath each window in the host memory, while executing on the co-processor.

The most ambitious programme I ever wrote was a sideways scrolling shooter game, which was written almost entirely in assembly, and could have up to 50 moving sprites on the screen at the same time without dropping frame-rate. Sadly I never fully completed it, as my dad had just got his first PC at the time and I moved over fairly quickly.

And of course, no discussion of the BBC is complete without mentioning Elite, which was a truely awesome game. They completely re-implemented line drawing routines, as the inbuilt ones weren't fast enough. And they used two screen modes _at the same time_ to allow high definition at the top of the screen, but only in black and white; and lower definition, but in colour, at the bottom of the screen. Try doing _that_ on a PC!

Sigh... Wonderful times... And all in less than 32kB of memory...

I have a copy of Beyond BASIC, the BBC Micro 6502 manual, here on my desk!

The Tube version of Elite was amazing.

The book that really rocked my world was 'advanced programming techniques for the BBC micro' by McGregor and Watt, I still have it somewhere. 3D graphics, animations sorting & searching, all the good stuff, and explained in a way that made sense to me.

That rings a bell - I may even have a copy of it at home!

Having an assembler built in to the basic interpreter was pretty damn cool as well, even if you had to manage the passes and origin your self

I must be getting old, but there was an accessibility in those systems that is hard to replicate today.

I have fond memories many hours spent typing in game listing from a magazine ... and learning that you should always type 'save' before 'run' in case it crashed. And that was before we ever had a disk drive. I can still recall the tape noisy perfectly!

My son has expressed an interest in wanting to write a game rather than just play them, but it always seems to stumble on the fact that he is used for 50fps full 3D and the learning curve to produce anything like that is huge. 25 years ago you could type something in an afternoon that was comparable to something you could buy off the shelf.

Don't forget what the 6502 was in. The NES used it, the Apple II used it, and the C64, and a few early arcade games, and the early Ataris. The SNES used the 16 bit variant of it called the 65C816, as did the Apple IIGS.

Interesting side note: The Apple IIGS could run normal Apple II 8bit software and GS-only 16bit software... Nintendo had planned the same for the SNES, but bailed on the idea early on, afraid of the backwards compatibility cannibalizing SNES game sales.

Sony, who was an important part of designing the SNES, produced the SPC700 sound DSP (which had a 6502-like instruction set, its own RAM, and a normal DSP companion core to do mixing, panning, volume, and filtering).

Incidentally, Sony had a working prototype for a add-on CD drive for the SNES (it used the expansion port on the bottom most people didn't know existed, and the SNES would sit on the drive). The drive also included a secondary independent 65C816, sorta like SA-1 chip used in Super Mario RPG (which ran 3x faster, had its own RAM, could MMIO and DMA to hardware in the SNES and interrupt the main CPU to do so).

By the time Sony was ready to ship the device with Nintendo, the SegaCD add-on for the Genesis had already crashed and burned, and Nintendo decided to back out because they thought CDs had no future for gaming.

Sony decided to make their own console, replacing the Super Nintendo "component" of their CD add-on, and produced the Playstation. The Playstation sound chip was similar to the SPC700 (but vastly enhanced for CD quality audio), but the rest of the Playstation was decidedly not like a SNES.

Sony, during the development of the Playstation 2, decided to add backwards compatibility as a feature when Nintendo didn't.

My first language that wasn't. I taught myself 6502 asm before I have even seen it run. The local British Council library (UK sponsored library going back to colonial times) had 3-5 books on computer programming, all of which I memorized. Among those books was one on the BBC Micro assembly programming.

It had a few worked examples. I used to cover the examples with a sheet, read the problem, then try to solve them before looking at the answer (since I didn't have a physical machine to test things.) -- I quickly came to appreciate that there was no canonical single "answer" in algorithms, and the only way to compare the "equality" of two solutions is see they leave the machine in the same state, given identical initial configurations .. very disturbing thoughts for a self-taught newbie programmer.

I did that for a few weeks and was bored. Then got Robert Lafore's book "Assembly Language Programming for the IBM PC and XT", and I killed it. Hard to explain this, but my first working assembly programs were quite advanced, because I have been "paper hacking" for quite some time by then. I wrote my first apps off of a floppy disk that I used to insert into internet cafe or library computers, when no one was looking (I didn't do any of the PC speaker tricks until much later, when I got my own computer.)

Not quite on topic, but as for PC speaker tricks: I once found if you control the tape-interface relay switch on a BBC B (or BBC Electron), from a BASIC loop, you can make it click really fast and make silly noises! Doesn't work in an emulator though.

So you taught yourself 6502 assembly language while there were already internet cafes? When was that?

1996

After all these years the 6502 (in his reincarnations) it's still alive, selling million of pieces (but at 200MHz). http://www.westerndesigncenter.com/wdc/index.cfm

Wow! Just imagine a 200 MHz Apple II!

In 1979, at age 16, I saved money from my paper route and purchased my first computer, an Ohio Scientific (OSI) C2-4P, from Allied Electronics in West Allis, Wisconsin. It had a 6502 microprocessor and 4K(!) of RAM. I used a cassette tape recorder for mass storage (transfer rate was 300 baud), and an RF converter and a television set as my video monitor. This provided a stunning monochrome 80×40 character display!

Within a few months I grew tired of the 15+ minutes it took to load BASIC into RAM from cassette and decided to learn assembly language. This was better since there was a "monitor" program in ROM and therefore always available immediately.

Today, I flip-flop back and forth between thinking, "Those were the days!" and "How could 30 years have gone by so quickly?"

Wait, you had 80 columns through an RF modulator on a TV? Wow. I thought it would be pretty fuzzy at 40 columns.

My memory is probably failing me. Gads.

As it does for many others, news of this chip brings back fond memories.

I was hired for my first programming job at the age of 19 and was tasked with writing a macro assembler for the 6502 from scratch. My manager/mentor had already designed the basics, and handed me a big pile of notes and flowcharts on my first day or work.

Before diving in I wrote a FORTRAN version of the hashing algorithm that we planned to use, and found that we could improve performance considerably with a slight change (I got a raise for doing this).

I wrote the assembler in 6502 assembler, using an existing non-macro assembler that ran on our Ohio Scientific machine. I got it to the self-hosting point as quickly as possible so that I could use the advanced features that I had built into my version. We wrote a set of "default" macros to make the instruction set more regular, filling in some holes.

After some fine-tuning, I was able to compile macro-dense code at several thousand lines per minute. This was on a machine with two floppy disks and 48KB of RAM.

This was an incredible "first project," given that all of my 6502 programs before starting the job had run on my Apple ][ and would fit on a printed page.

I still have the listings for the assembler, and pull them out from time to time to reminisce.

BTW: Commondore keeps a page on the history of MOS and the 6502 with a lot of insights: http://www.commodore.ca/history/company/mos/mos_technology.h...

A couple weeks back I was catching up with the Retrobits podcast and listened to this interview with Chuck Peddle:

http://retrobits.libsyn.com/index.php?post_id=505602

http://retrobits.libsyn.com/index.php?post_id=514107

http://retrobits.libsyn.com/index.php?post_id=517736

http://retrobits.libsyn.com/index.php?post_id=521785

Simply amazing.

Awesome - thank you for sharing. Excellent interview. Chuck Peddle was the guy who made / marketed the 6502. Lots of history here including mentions of the C64, Apple I, Steve Jobs, Bill Gates, Basic, TI.

Ah memories :)

Well, actually more like a lot of moving things around in memory...

MOVEDOWN LDY #0

         LDX SIZEH

         BEQ MD2

MD1 LDA (FROM),Y

         STA (TO),Y

         INY

         BNE MD1

         INC FROM+1

         INC TO+1

         DEX

         BNE MD1

MD2 LDX SIZEL

         BEQ MD4

MD3 LDA (FROM),Y

         STA (TO),Y

         INY

         DEX

         BNE MD3

MD4 RTS

I first* learned programming on a 6502-based machine with 1K of RAM and no assembler or basic (Microtan 65, in case anyone remembers that.)

Luckily the 6502's instruction set is pretty easy to memorize, used to know it back to front. Only 56 base instructions and once you understand the way the addressing modes affect the opcode for LDA it's easy to work it out for the others.

Glad I don't have to do that anymore, but it was a great grounding for all the high-level stuff that came later.

(*Well, unless you count my dad's 31-step programmable TI calculator.)

Just to be explicit: you mean you programmed it purely with opcodes, presumably compiling by hand a program you'd figured out earlier?

Yes, I programmed it purely with opcodes. The machine was just running a very basic "monitor" that let you write instructions and data into memory in hex and then let you run them.

At first the machine did not even have a cassette interface, so there was no way to save programs and you had to type them in every time. The machine came with some examples, like Conway's "Life". Given that the machine really only had about 256 bytes of usable program storage (half the 1k was used for video) this wasn't quite as bad as it sounds but still pretty tedious.

Actually when I first got a cassette interface I still had to type the cassette loader in by hand to boot :( Eventually I got the rom expansion that included the cassette loader and an assembler.

Obviously writing a program directly into memory in opcodes does involve some upfront thinking, but you'd be surprised how "REPL-like" the coding experience could be :)

I was surprisingly impressed by meeting Brad Templeton in Silicon Valley in ~2006, not because he was a board member at the EFF, nor that he founded Clarinet, but because he wrote PAL, an assembler for the C64 that I used back in the day.

After all these years, I think the 6502 instruction set is still the one I know best.

I only remember 0x00 and 0xEA these days :)

All the rest of them have slid in to the swamp of time. The 6502 was a funny chip with it's zero page access and lack of a 'mul', to some extent not having a mul makes you a better programmer (you'll have to roll your own, and that will lead you to discover look up tables for nibble sized chunks pretty quickly because of a perceived lack of performance), and the 'zero page' was a good preparation for knowing how to deal with memory with different degrees of accessibility (think of caching and demand paging).

I worked a lot with the 6809 as well, and that was a much richer instruction set (and more orthogonal too), but I did not learn as much from that as I did from the 6502 because of the more restricted environment on the 6502.

I believe my first 6502 based computer had all of 1K of RAM :)

Single board job with a hex calculator keypad and 6 7 segment displays and an fsk based tape interface.

Did any peer chip have a mul in the late 70s/early 80s?

6809 did 8x8 mul.

6809 was one of the first to have a mul instruction, and was used in the initial development of the macintosh: http://www.folklore.org/StoryView.py?story=Good_Earth.txt

Awesome! In 11 clock cycle (not counting the set-up, i.e. loading the hardcoded source registers with the desired values).

That's interesting, thanks, I remember writing my own on the Z80.

I vaguely remember that at least one version of the 6502 had half a mul instruction, that is, an attempt was made to add one, but it was buggy: it only worked for some multiplicands (ones without any neighboring one bits or something like that). That made for interesting programs, where, depending on the arguments one would compute a times b, b times a, a1 times b plus a2 times b for some a1 a2

Perhaps the most satisfying hack I ever did was with the 6809. Making it handle high speed communications directly. It was done by decoupling its address bus during instruction fetch and then feeding it instructions from a separate ROM. The effect was to let external logic handle the control flow even if the 6809 did the data processing.

That sounds like a ROM driven bus master to me, how did you manage to get the 6809 to disenage? Using DMA/BREQ ?

NMI to let the active process save its state. Then the busses were taken over during instruction fetch. Feeding NOPs when nothing to do and appropriate instructions when needed. No jumps nor branches. Just the essential processing. A normal interrupt routine couldn't have a tight loop fast enough, so control flow was handled in parallel externally in programmable logic.

Very cool, I highly doubt anybody will ever fully appreciate what a neat hack that is. So you basically divorced the busses from the CPU for a while making it run in a little parallel universe of it's own.

A total perspective vortex of a sort ;)

I realize it would take some more to clearly explain the intricacies, but I see you got it :-)

BRK and NOP? Odd choice. 0x20 and 0x60 are still burned in my brain. (I couldn't afford the exotic "floppy disc drive" required to run the assembler, but the ROMs would disassemble what you entered so hand translating to machine code wasn't too bad.)

Nop to temporarily disable a call (nop, nop, nop that is), and BRK stop so I could have a look at what's going on. The reason I remember them is because those are the ones I would insert most often in binary rather than in code.

In high school I learned 6502 (Apple II) which prepared me for the college course that was in 6809. I enjoyed the 6809 more, but I still have a soft spot in my heart for 6502. I also had a course on 8088 in college and really didn't like it at all.

Looking back, I had college courses on assemblers for 6809 (EE dept), 8088 (CSci), and IBM 370 (CSci - the banana book rocked). I wonder if that goes on anymore today.

You also have the 6502 to thank for the design of ARM

Interview with Sophie Wilson, chief architect of ARM, October, 2001

Primarily the 6502. I learned about pipelines from it (by comparison with the 6800) and its designers were clear believers in the KISS principle. Plus the syntax of its assembler and general accessibility of it from the machine code perspective. I can still write in hex for it - things like A9 (LDA #) are tattoed on the inside of my skull. The assembly language syntax (but obviously not the mnemonics or the way you write code) and general feel of things are inspirations for ARM's assembly language and also for FirePath's. I'd hesitate to say that the actual design of the 6502 inspired anything in particular - both ARM and FirePath come from that mysterious ideas pool which we can't really define (its hard to believe that ARM was designed just from using the 6502, 16032 and reading the original Berkeley RISC I paper - ARM seems to have not much in common with any of them!).

Maybe this is a good time to toss up the half-finished 6502 simulator I have kicking around.

My first assembly language. Ahh, the beauty of limitation

A 6502 emulator in JavaScript, visualizing the actual core and its electric flow during operation, cycle by cycle, instruction by instruction. If this is not Hacker News worthy, I don't know what is.

Wow - that was made by extracting the gates & nets from de-packaged die photographs! It is actually a transistor & wiring simulator (in javascript) that has a 6502 description loaded (and a simulated memory device tied to the pads)

That is absolutely amazing. You should post that one separately, it's definitely worth it.

Wonder how fast it runs. I could dig out the old Apple //e load up kermit and transfer the hard hat mack runtime over. If I can find a kermit client for windows. And probably a serial port card. And a null modem cable. And if the old floppies are still readable.

Reply on news.ycombinator.com