Hacker News Reader

Comment by wmil | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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.

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?

> 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.

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.

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

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

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

Reply on news.ycombinator.com