The Story of the Team Behind the 6502 | Hacker News Reader

The Story of the Team Behind the 6502

team6502.org

232 pointssohkamyung43 comments

The website's video cover is a remake of that classic photo by EE Times that shows the 6502 team members holding the chip layout, which is excellent. Unfortunately, it copied the original mistake by EE Times in print [0] as well: the image is improperly mirrored by the Y-axis, it makes all people left-handed and the flipped the layout as well!

If you compare the 6502 layout using the dieshot by the Visual6502 team [1], you can clearly see that the layout is flipped. Note the location of the T-shaped and L-shaped circuits at the bottom-left and bottom-right.

[0] https://research.swtch.com/6502

> An EE Times article from August 1975 shows a picture of the 6502 team, along with a caption listing Harry Bawcom as a “layout designer” and Bill Mensch as a “design engineer,” which seems to corroborate Bawcom's note. (Note that the photo printed in the article has been mirror-image reversed.)

[1] http://visual6502.org/JSSim/index.html

Here's the EE Times photo: http://www.commodore.ca/gallery/magazines/misc/mos_605x_team...

What's really interesting is how long 6502 variants lasted. They mentioned the NES, but the SNES also used a 16 bit variant similar to what the Apple IIgs used.

Starting in 1995 Nintendo included the SA1 chip in some cartridges, which was a 6502 variant running at a little over 10Mhz.

I actually think that Nintendo could have come out with a SNES Pro CD system in the mid 90s by including SA1 and SuperFX2 chips and having 4MB of RAM.

CD based systems with sprite & tile based hardware seem to have all failed due to lack of RAM. Just too memory hungry, especially once you start increasing the number of colours. The Neo Geo hardware (Motorola 68k & Z80) was able to produce hits after 2000 by using giant, expensive, cartridges.

They could have kept a 6502 based system going as a budget system (keeping the N64 as their "cadilac" system) until 2000.

Nintendo did start development of a SNES based CD system in 1988 with Sony, but they had a falling out, leading to Sony's entirely independent version of the Playstation.

Lack of RAM wasn't the primary issue; the load time was just too jarring in the early systems (Sega CD, Neo Geo CD, PC Engine CD), and so consumers tended to prefer cartridges. The g65816 and m68000 had 24 address lines, which allowed direct access to up to 16mb of RAM (paged internally in the g65816). The real difference came in the speed (3 vs 7mhz). But there still remained the issue of load time on a 1x CDROM drive, which is why the Neo Geo CD was so godawful slow. The first gen 32-bit systems did better because they were powerful enough to decompress on-the-fly, but even that took years after release to figure out.

But if it had 4MB of ram, the size of a large SNES ROM cartridge, it could get away with only loading the base game once. Then do additional loading for the occasional enhanced feature.

The Sega CD only had 512 KB of normal RAM. Far less than the ROM in a standard cart, so constant loading was necessary to grab different bits of game data. Leading to a worse experience than a cart and to a lot of developer headaches.

RAM was too expensive back then to put 4MB of it in there. Even the PS1 and Saturn which came out later could only afford 2MB of it.

PC Engine introduced the Arcade Card in 1994, which gave it 2MB of RAM (all cartridges except Street Fighter II were max 1MB), but the loading time was still terrible (especially the SNK conversions like Art of Fighting).

The Neo Geo CD had 7MB of RAM, and yet it took an ETERNITY to load games on its 1x CDROM drive.

They had the exact problem I was looking to avoid -- the SNK games were giant ROM cartridges, up to 41MB. Later larger.

Chopping up the data and loading just the graphics needed for each fighting game match is what created the loading times.

The devs decided load times weren't a big deal if the matches looked and played great. They were wrong. Loading times are just something game designers have to accommodate, cut back the graphics as needed.

Being able to start with a back catalog of SNES games, enhance them, then publish on a medium with better margins like CD would have been very attractive to publishers.

NEC, SNK, and Sega offered the same promises for their CD systems, but it never worked out that way. As soon as more storage was available, the games used it all. I doubt that Nintendo's playstation would have resulted in a different outcome.

In fact, Nintendo was so spooked by the user experience of their competitors' 16-bit CD systems that they stuck with cartridges all through the 32-bit era, which hurt the richness of their games and caused a much stronger focus on gameplay vs visuals (due to limited storage space), and pushed them permanently out of the spec race between Sega, Sony, and Microsoft.

You can still buy them from WDC, part #W65C02S: https://www.mouser.com/ProductDetail/Western-Design-Center-W...

Price is a bit high, but factory lead time of 1 week is amazing! Also very interesting Product Change Notification: “0.6μm process currently being used at TSMC”. Interesting, that TSMC still used such ancient node in 2013.

> Interesting, that TSMC still used such ancient node in 2013.

I guess for these type of products, where the wafers is not what costs (the 6502 is ~3.5k transistors), but overheads of dealing with small runs and packaging or investing in upgrades...

Anyone looking for large quantities of 6502-compatible cores presumably are mostly licensing cores to embed into something else.

Sure, the node is ancient, but the factory is long ago written off which means that (aside from energy, materials and labor expenses) all income is pure profit. As long as there are enough orders to cover the expenses plus a couple percent of profit margin, it makes sense to continue operating that factory.

Lower-resolution nodes are still very useful for analog parts - transistors, regulators, op-amps and so on.

I suspect that is to make it as close to compatible to the original as possible with respect to its ability to resist EM interference. Lots of chips from the 80's and 90's ended up in military hardware and some of that stuff is still being manufactured or in use. I wonder if a milspec 6502 version was ever made?

I think you don't need to use state-of-art node process to make an opamp, a battery-charging controller or a 8-bit microcontroller, and I guess the vast majority of chips we use are those things, not CPUs and GPUs, and it's reasonable to keep some old production lines and operate them.

As with any infrastructure, once a fab is built you keep it alive as long as it's cost-effective.

You could shrink the die, but what package will you put it in?

They do have some in smaller packages too, e.g. [1] that uses a PLCC-44 package, so ~16.7mm per side instead of ~5.2cm x ~1.5cm. The package above is that big because it's pin-compatible going back to the original 1975 version, and mostly drop-in compatible (barring some issues such as different levels of support for undocumented opcodes).

But of course even a PLCC-44 package is big compared to that die.

[1] https://eu.mouser.com/ProductDetail/Western-Design-Center-WD...

And that's kind of my point. If most 6502s are needed as legacy drop-ins, then there's no reason to shrink the die if you're just going to weld it into a massive DIP package.

Yes, I agree with you; sorry if that wasn't clear - absolutely don't think they'd gain much from shrinking it further. Anyone who cares about shrinking it down further would probably gain even more by licensing the core and embedding it together with other functionality anyway.

You can also find the Bulgarian clone of the 6502 on eBay. It's called CM630P.

The 8 Bit guy builds a new computer around it. https://www.facebook.com/groups/CommanderX16/

In one of my first companies, InformAsic, we developed and shipped a small ASIC that implemented encryption for serial communication. The control was handled by AT-commands. And the parser and rest of the control functions was actually implemented in SW on the 6502 core in the chip. We clocked the chip at 33 MHz, making it one of the fastest 6502 clones in the early 2000s.

Nope. Most modems used in the '90s using the Rockwell chipset used a 6502 derived controller which was clocked at over 60 MHz. The NDA we had to sign to get access to the source code (to just modify some strings) was from another world and that's probably why it is not a very known fact.

I first learned the ins & outs of the 6502 from hobbyist hardware developers that cloned it as part of the NES. It's such a generally useful processor and great as a stepping stone for learning about just how you make the leap from logic gates to a full instruction set.

[1] For example: http://fpganes.blogspot.com/2013/01/luddes-fpga-nes.html

To give you an idea of how underreported this chapter in computing history is...

I was born in the 1970s and grew up in the 1980s. Huge computer nut since an early age, devouring computer magazines many years before we even owned a computer. Used Apple ]['s in school and knew which game consoles used 6502's and their descendants.

And I still had no idea that WDC was based a few miles from where I grew up.

I learned that only a few years ago!

From a local perspective, perhaps this is because they promoted themselves as being based in historic Valley Forge, PA. When in reality, they were based in nearby Norristown, which is kind of a downtrodden town and obviously lacks the name recognition of a national landmark like Valley Forge. I'm sure Norristown would have loved to trumpet their role in the computer revolution, but that would have been tricky to reconcile with MOS's (understandable) claim to actually hail from the next town over. Awkward!

(....or maybe it's because MOS left behind a superfund cleanup site....)

The (awesome) youtube electronics teacher Ben Eater has just started a series of videos building a 6502 based computer on a breadboard, and he sells kits.

I just got my kit, so I'm really looking forward to the rest of the videos. He also offers the schematics for those wanting to jump ahead.

https://www.youtube.com/watch?v=LnzuMJLZRdU https://eater.net/6502

I've been watching this series as well. Can definitely recommend.

My first programming experience was on the 6502 in the BBC micro, absolutely loved it, especially the programming manual where it gave you the number of clock cycles for each instruction.

I was programming professionally in Fortran but, when I got my Apple II+, I became totally caught up in learning how to program it in both Apple Basic and assembly. A Apple-centric magazine at the time published an assembler which I laboriously typed in, corrected mistakes, and finally got working. The opcodes were easy to learn and Woz had printed the ROM code he wrote at the back of the manual so that served as a great way to learn the language. What I learned from that helped me later when I had to do some assembly program on the Motorola 680x0, a DEC PDP/11, the Intel processors, and on an IBM main frame.

I remember seeing that the "zero page" instructions were all significantly faster and thinking "This Changes EVERYTHING!"

As if I could rewrite my code to run in only 256 bytes of working memory.

You would put only your data (or the most frequently used values, at least) in the zero page. Your code would then be smaller and faster.

You would save a byte every time you had to load/save a value from zero page into/from a register.

BBC Basic puts the work area for maths functions in the zero page.

You can check at http://commodore64.se/wiki/index.php/Commodore_64_Memory_Map what kind of stuff goes in the zero page for Commodore's kernal and Basic.

In particular, Basic puts the whole "get next byte" routine there at $0073. It is self-modifying code where the address of the next program byte is the operand of an LDA instruction. Placing the whole routine in zero page saves enough cycles on incrementing the next program byte that it's worth spending 5% of the whole zero page on it.

Cool stuff. I've seen something similar for handling interrupts when reading from floppies. It didn't use the zero page, but it could have.

65C816 and also Motorola 6809 could set any page as 0 page (called direct page).

I am keen to build one of these if the SMD soldering doesn't drive me insane.

https://monster6502.com/

If you want more context to the story I recommend the following, fascinating book.

https://www.amazon.com/Commodore-Company-Edge-Brian-Bagnall/...

It's great, and the two follow-ups are also out (less interesting for people mostly interested in the 8-bits, though Commodore kept a staggering amount of 8-bit R&D going way longer than they probably should have spent money on it; a lot of it going nowhere)

Commodore: The Amiga Years

Commodore: The Final Years

(Note that there's also an older edition - "On The Edge, The spectacular rise and fall of Commodore" also by Bagnall. That one covers most of the history of Commodore in a single ~500 page book; the three new ones are ~500 pages each; which one to prefer I think largely depends on how much you care about Commodore and/or whether or not you're only interested in a particular subset of its history - that said I don't regret having bought and read both the original and all three new ones)

The Amp Hour interviewed Chuck Peddle in this episode, it's a worthwhile listen:

https://theamphour.com/241-an-interview-with-chuck-peddle-ch...

Interesting to see that KIM-1 documentation again.

back when we all dressed more formal lol :)

Reply on news.ycombinator.com