Rearchitecting the 6502

This was my introduction to your channel. You earned the sub within the first 30 seconds! But just so you know, if my boss complains about my productivity for the next few days I'm blaming you, as I will likely be binge watching these videos for the foreseeable future.

Your best video yet! I love how far your production quality has come. And the content remains top notch.

Good. You have seen a flaw and addressed it. In for a penny, in for a pound!

A reasonable approach, given that your target speed is two orders of magnitude lower than the native FPGA clock, LOL. Another trick I saw in an old 1972-era minicomputer was to generate the instruction clock from an 8x oscillator (1 MHz insn cycle from an 8 MHz clock), and use a counter and decoder (74LS138 idea) to generate eight distinct phases of the clock. The designers sequenced (or micro-sequenced? not quite the same as the modern concept) the flow within an insn by clocking flops or enabling latched on each of the distinct phases when they needed it. So you might increment the PC on phase 1 but load the instruction from memory in phase 2, load the register read data indexed by the opcode on phase 3, and so on. It worked quite well in practice for the mostly 74xx TTL design. But would be a nightmare in an FPGA unless you use them strictly as clock enables in a natively 8x fully synchronous clock design, which is sort of what you're doing.

Beautiful!

This is basically how i handle load-balancing within single thread applications to tie the fps rates to the desire position.....but I adjust the individual load timing on-the-fly in order to maintain rather than gate them, this way it attempts to maximize calculations until the core starts to suffer, then just raise the wait time for the following cycles (since the individual calculations performed are never known ahead of time, they are just added in as class callbacks into a list). soooo....in short, I create my own multi-thread using count triggers lol.

That is nuts!

Wow, I was totally riveted to this video and I have nothing to do with hardware. Subbed!

So 6502 is running with an effective clock jitter, to allow for other bus activity or SDRAM being unresponsive. It doesn't hurt your project since all of your other subsystems have flexible timing as well, and might as well go to sleep and catch up as needed. But i wonder how it would affect interfacing with legacy hardware, say Commodore IEC bus and 1541 drive, or emulating the 1541. The basic IEC protocol is explicitly clocked, so an endpoint can cycle stretch, but wouldn't have fastloader compatibility?

personally i would've gone exactly the opposite way, adjust the RISC-V CPU to have a 6502 compatible async. 8-bit bus. and then have the RISC-V CPU's clock just be the 6502's run through a PLL (multiplied by 50 or something). that way they're always in-sync with eachother and you can use some much much simplier logic to connect them to the same bus (before the width adjustment/cache). plus it allows you to adjust the 6502's clock to whatever system you're emulating and the RISC-V's clock will automatically follow. though overall, your idea of using a large master clock for both CPUs and just letting it get 1 cycle out of a set amount of cycles is way better.

I was going to upvote this, but it was at 42- so I left it as is.... oh wait! Now I can. Great discussion.

The venerable 6502, the original RISC design, should be the first architecture implemented in graphene.

won't matter if a couple of clocks run after a longer delay... laughs in IEC bus.

would that screw up all non-apple 2 usage of your fgpa 6502?

I was thinking of how DEC made the Virtual Address Extension to turn the 16 bit PDP-11 into a modern for the time 32 Bit CPU while making sure PDP-11 code would still work. I think something similar could be done for the Zilog eZ80F917, Motorola 68060, WDC 65C832 and Vortex86DX3 to allow them to run modern 64 bit code with 256 Bit Vector Extensions, a 64 bit address bus, Cryptography acceleration, 4 way SIMD, EPIC instructions, and a hardware PCIE Express controller without breaking backwards compatibility. To escalate from the original instruction set to the 64 bit expanded instruction set, there would be a VAX instruction that would be used by the bootloader to switch to the expanded instruction set and address bus.

Actually the 6502 is considered one of the first RISC processors not CISC like your video description states.

Fyi, the background music seems a bit too much foreground.

Personally, I don't care about accuracy. I'm not even sure if I would start with a 6502, but definitely I'd make refinements until it was basically a whole new chip anyway. I understand that most who pick up an FPGA are looking to make a completely accurate simulation of an old chip, and if that usage makes them happy then great. I suppose they'd label me a heretic for thinking emulation is a better option if you just want to play games, but I'd really like to design my own processor and eventually produce a physical piece of hardware from my design. I figure an FPGA is great for experimentation in that regard, especially as you scale up beyond what an emulator can adequately do.

Someone made a 100Mhz 6052 on FPGA already 😂

Why?