If you compare the 6502 layout using the dieshot by the Visual6502 team , 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.
> 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.)
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.
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.
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.
The Neo Geo CD had 7MB of RAM, and yet it took an ETERNITY to load games on its 1x CDROM drive.
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.
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.
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.
But of course even a PLCC-44 package is big compared to that die.
 For example: http://fpganes.blogspot.com/2013/01/luddes-fpga-nes.html
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....)
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.
As if I could rewrite my code to run in only 256 bytes of working memory.
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.
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.
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)