SoylentNews is people
SoylentNews
http://www.e-basteln.de/computing/65f02/65f02/
The 6502 was the CPU in my first computer (an Apple II plus), as well as many other popular home computers of the late 1970s and 80s. It lived on well into the 1990s in game consoles and chess computers, mostly in its updated “65C02” CMOS version. Here’s a re-implementation of the 65C02 in an FPGA, in a pin-compatible format that lets you upgrade those old computers and games to 100 MHz clock rate!
The concept
The idea of implementing a CPU core inside an FPGA is not new, of course. In fact, the CPU core I am using is not my own, but was developed as a 6502 core by Arlet Ottens, and extended to cover the 65C02 opcodes by Ed Spittles and David Banks. A big thank-you to Arlet, Ed, and Dave for developing the core and sharing it freely! Links to their original work are on the Files & Links page.
(Score: 2) by Rich on Thursday October 14 2021, @02:22PM
They write that they can work in an Apple II including the floppy, and they are working on the language card, but could not access more than 64K due to the Spartan's SRAM size. Apparently that SRAM is fast enough to make a 6502 at 100 MHz happy. They also write that the IO layout needs to be written to the FPGA specifically for the machine. For the language card, they have to decide whether a RAM access, or a ROM access is done, according to the soft switches. Because they pre-load the ROM to FPGA, the RAM access would have to be slowed down (which has the nice side effect that a 128K Saturn card, which my II+ has, would also work (slowly)). They COULD use the remaining 4K (C000-CFFF) for caching language card content, UCSD Pascal would be happy, but that's quite an effort for such a hobby project. It might be worth it, because the alternate bank (or banks, with a Ramworks III) on the //e&c would benefit from caching.
There is no cache logic like in the ZIP chip, it's either a host system access in which case the fast core syncs to the external clock, or a local access that runs at the 100 MHz on-module clock. The matter of HOW the host system is accessed is the interesting part. Some addresses might just need syncing on read/write. With the Apple II floppy, however, one must throttle as soon as the floppy motor spins, not just on accesses, because timing loops for the head stepper and nibble writing are critical. On the other hand, the video ranges can be read fast, but have to be written through, or nothing would appear on the screen - but the write through can be "detached" and run in parallel. The fast core would then only stop if a write is pending (or, more advanced, a write queue is full).
By the way, there is actually some real-life benefit to such exercises. A customer of mine had to replace 68HC11 motor and sensor controllers after the CPUs were end-of-lifed. Rather than re-writing the software for dozens of little modules, they made a replacement with a Spartan (I just don't remember if 3 or 6). I've heard the term "neo-retro-computing", which I like. Because if development is constrained to about 1985 technology, it is feasible to replace the hardware core without all the software and periphery, which might have grown to magnitudes more of complexity than the CPU core.