I did reflect carefully on whether to dive in on not.

I reasoned that it's very hard to learn good HDL design practices without a non-trivial example. I think we now have this here.

Very few non-professionals bother to simulate stuff (myself included most of the time). But it's a really powerful technique for developing a design, and is surprisingly easy if you stick to 100% Verilog (and use iverilog or verilator). Or 100% VHDL (and use ghdl).

I plan to stop now (or very soon), and let Jon drive what even needs doing next.

Dave

Understood - it's a difficult call, when someone is struggling. Hopefully things are in a better place now, for further exploration and learning.

And surely the illustration, of the kinds of fixes made and the techniques used to find what's needed, should be of great value to Jon and to many others.

Right, then. The merge is complete.

-Jon

PS Thanks Dave & Ed.

Agreed - there are many, many "me's" out there who will be exceptionally grateful for these lessons.

PS on the topic of learning to debug... does anyone know how to create debug cores in vivado?

Hi!



I'm following, but I don't have time right now to invest in this, and you are advancing really fast.

I have used the 6502 core from Arlet, and that core is cycle accurate, so you could switch to that if cycle accuracy is needed - but you will lose the CMOS enhanced instructions and address modes, but the core is really simple and fast.

Also, I use the open-source FPGA toolchain (yosys + nextpnr), Yosys allows you to generate verilog from the synthesis, so you can simulate the real implementation using icarus verilog - this was really useful to debug glitches in my 6502 FPGA project - having a working interleaved VGA/CPU memory accesses was not trivial!

Have Fun!

I'm going to see what happens if I try and connect a physical 65c22.

Just to note, Dave and I did tweak Arlet's core to provide the CMOS instruction set. (As did Arlet, it seems.)

(overlapped with Ed, but I'll post anyway)

Yes indeed, let me clarify one of my early comments, because the term "Arlet's core" is ambigious.

There are at least three versions:

1. Arlet's original NMOS 6502 version is cycle-accurate, but not bus-cycle accurate.

2. In 2016 BigEd and myself spent a fun few days extending Arlet's core to create a CMOS 65C02 version. This may not be cycle accurate, as all we cared about then was it working, passing the Dormann tests, and booting in an FPGA Acorn 65C02 second processor.

3. In 2020 Arlet started work on his own CMOS 65C02 version. This embodies two seperate implementations: a generic version and a Spartan6 specific version. This is not cycle accurate - by design to maximise system performance.

Jon's 65C02 SOC now has a choice (at compile time) of:
- Arlet's core with + BigEd/Hoglet 65C02 extensions (variant 2 above)
- AlanD's core (which originated on Stardot)

Finally, for my 6502 instuction stream decoder to work flawlessly, it needs the core to be bus-cycle-accurate. Which none of the above mentioned cores are.

The only bus-cycle-accurate 65C02 core I know of is Jen's core, which is huge!

Dave

Jen? Which core is that?

By bus cycle accurate, is that literally what it sounds like, as in you could just drop it into a system that uses a physical 65c02 (as a replacement)?

And, back to our little project here, is it possible that there is something that vivado is doing that is causing it not to work for me on a spartan-7? Or, maybe is there some constraint or other I need to add? I'm at a total loss.

-Jon

Sorry, another long post, but you ask several interesting questions...

It's called 65c02_tc:
viewtopic.php?f=10&t=2609

(tc = true cycle)

Bus-cycle-accurate means that each bus cycle has the same function as a real 6502.

For example, the consider the following JSR instruction:

And assume SP=01FF.

If you looked at the 6502 bus, you would see 6 cycles used as follows:

Specifically, the 3 bytes of the instruction appear on the data bus in cycles 1, 2 and 6. Most FPGA cores re-order the cycles, so the instruction appears in cycles 1, 2 and 3. This plays havoc with my 6502Decoder, which functions by looking just at the data bus.

Generally a core doesn't have to be cycle accurate to be compatible with original hardware. But it does have to emulate the bus timings.

In terms of replacing a real processor in original hardware, I have a couple of projects that do this.

- The most mature is called ]AtomBusMon (for historic reasons). This replaces a 6502, 65C02, Z80 or 6809 with an FPGA module and gives you a full in-circuit emulator. This runs at the original clock speed.

- A more recent one is called BeebAccelerator. It's basically a CPU accellerator. It will run at (upto) 80MHz, unless the external hardware (IO or frame buffer) is accessed. It's currently specific to the Acorn BBC Model B/Master/Electron.

Both of these needed careful attention to the timing (i.e. how soon after the falling edge of Phi0 do the outputs change). Being bus-cycle-accurate matters less, unless you are running demo software that cares about this.

Sorry if I'm repeating myself, but please be a bit more specific about "not work". Are you still at this stage:

So the issue is the VIA?

Can we narrow this down about...

1. I assume you are using the latest code (after the merge last night)?

2. In WozMon, what do you see if you do 8800.88FF:

3. In WozMon, what hook an LED (or multiple LEDs up to port B) and try the following:

8802:FF
8800:00
8800:55
8800:AA
8800:FF

Record the terminal session and paste the whole thing into this thread.

I'm trying to figure out whether it's VIA writes, VIA reads or both that are broken.

Dave

That is so interesting! I've watched these very cycles on logic analyzers many times, and I've always wondered about the logic behind them. Fascinating! Sorry for the "starry eyes," but this really is quite cool.

Yes, I'm working with the most-up-to-date version in our repository. In vivado, it synthesizes and implements just fine. I confirm that the ROM file is loaded into ROM. I upload it to the Arty S7 and hook up the UART to USB to the ACIA as usual. I have the WDC seven-segment module hooked up to the VIA (tested, always works with a physical VIA). Then - nothing. And by "nothing," I mean I fire up PuTTY and - nothing. I try with extra PuTTY - nothing. And, by "nothing," I mean the UART to USB connects just fine, but the ACIA doesn't seem to work.

I've not changed any of the external connections, so that is controlled. That setup had worked, as I had written in earlier posts. I've used a logic probe to prod the acia wires.

So, that's where I'm at.

-Jon

I suspect a Vivado synthesis issue.

I'm trying to get myself setup with Vivado here, but it's a slow process.

In the mean time, can you zip up and post:
- your Vivado project file (it will have a .xpr suffix)
- your Vivado constraints file (it will have a .xdc suffix) [ I know this is in git, I just want to double-check what you are actually using]
- any log files you can find of the sythesis and implemetation phases

Dave

Dave,

Here is everything:
https://github.com/jmstein7/65c02_errata/blob/main/dave_gamma.zip

That is the entire project created from the most up-to-date github.

-Jon

PS Yeah, setting up Vivado is hella slow.

Thanks. As an aside, it's not a great idea to check large binary objects in git repositories. Over time it causes the repository to become quite large, and that just slows everything down.

Dave

Duly noted