Decided to compromise... I created a bus that's compatible with Arlet's core and then created peripherals that respond to this bus. For the purposes of creating 6502 SoCs, all peripherals I create- except for those emulating 65xx chips- will use Arlet's core timing; the toolbox I use to write HDL ...

Yes. That said, I think I need to finish designing my current "toy" system and upload the code (I have your code linked as a git submodule).

I'd have to think whether I need more, but at the very least, I'd need a signal that denotes whether your core is "ready or not ready" to fetch the next address. Something akin to a pipeline stall signal.

But this is later. I can live with the halved performance on the Wishbone bus for now.

Could you improve performance by pretending to do bursts at incrementing addresses, and abandon data + start a new transfer when the 6502 doesn't read from next address ? I don't think your coree provides enough control signals to the outside world for me to do that (I use a set of Python modules ...

Just to make sure... all 6502 clock cycle counts take into account that the last cycle may not be doing anything besides fetching the next byte in the case that the instruction need to write/read memory (example STA $FE00 takes for cycles, but the write is committed during the third clock cycle ...

Indeed, this is what I do. The core is doing a perpetual Wishbone block mode transfer.

See my edited post. I think what you just described is a side effect of the real issue.

I'm a bit confused about the state of the RDY signal during all of this. Is it being deasserted ? And if so, can you show the timing ? (note that I have no experience/knowledge of wishbone) RDY is deasserted every other clock cycle b/c wishbone (without more control signals than I have available ...

Okay, after some timing/simulation analysis of Arlet's core, along with looking on Arlet's website I think I figured out most of the internals:

Data is fetched on cycle X posedge, Data is interpreted on cycle X + 1 posedge, as indicated on the website. This pipeline allows Arlet's 6502 core to run ...

Okay, so it's not just me... looks like you ran into the same problem I did.

This is a real pity though... the speed of the core will be no more than 2/3's full speed thanks to this; the RAM itself is synchronous. The address decoding of my design is not. So synchronous RAM accesses are delayed by ...

I've been playing with Arlet's cute 6502 Verilog core recently and trying to embed it onto an FPGA for a DAQ application to analyze bus signals (the 6502 tells an FPGA-logic analyzer to start collecting data and sends/receives data from a DUT).

To make my life easier, I've tried connecting the 6502 ...

Forgive me for the stupid question, but in your PDF schematic, why are only 2 wires connected (A8/A9) to the SIMM connector? I think I'm missing something important here.

I'm surprised nobody mentioned m4 for use as a macro processor for bare minimal assemblers, which was it's original intent I believe.

I'm also learning Scheme, and that also is a good candidate for macro generation (anyone know if a Lisp interpreter exists for a 6502 system?).

However, I would ...

Indeed, VIA is available in PLCC (and supposedly QFP). This actually should be doable in 5 chips: '816 or '02, 128kB RAM, VIA, CPLD (address decoding, control, and UART), and EEPROM (serial or otherwise). And of course, headers for I/O, clock, power, and reset, and UART :D.

There, I designed a SBC ...

5V-tolerant CPLDs are becoming hard to come by, so that would facilitate using logic shifters since at 5V the 'C02 doesn't understand that 3.3V is valid TTL :(. Not necessarily a huge deal- 4 10-input logic shifters are plenty for a 65xx bus, and don't take up much room. Yes, that is certainly a ...