Not using a Wishbone-compliant bus prevents you from directly connecting Wishbone peripherals (e.g., vga controllers, various UARTs or other communications products), which is the OpenCores.org standard.

But, since Wishbone and 65xx buses are very nearly identical, making a bridge shouldn't be too hard. And, by nearly identical, I mean they're almost isomorphic:

* CYC_O corresponds with (VPA | VDA), where | represents binary-OR.
* STB_O is, because the bus is only 8 bits wide, the same as CYC_O.
* OE_O is R/W inverted.
* CLK_I is phase-1 (or phase-2 inverted)
* ACK_I is RDY

All that stuff about tags, multiple byte lanes, etc. you needn't concern yourself over, since you're not making a wider bus with error correction.

Overall bus timings are a little bit different, but I seem to recall only few cases where they're at all incompatible (e.g., handling of ABORT, if you support that at all, maps to Wishbone's ERR_I, yet isn't compatible with Wishbone because it's sampled on the wrong clock edge).

re: 65816 -- EF is the external emulation flag -- it's set when running in 6502 mode, and cleared otherwise. If you have external hardware that provides interrupt vectors dynamically (e.g., as the Apple IIgs does), this signal is used to determine whether to intercept $00FFEx vs. $00FFFx.

MF and XF are the M and X status indicators, indicating accumulator and index register widths. This is required knowledge if you're attempting to use external hardware to intercept opcode fetches and you need to determine how big the operand is going to be.

Thank you for clarifying this, I completely forgot about that.

_________________

Rewritten cores II

I updated RB65, found two bugs:
http://www.baltissen.org/vhdl/RB65.vhd

I also uploaded:
http://www.baltissen.org/vhdl/RB65-ISE.vhd
It simplifies testing RB65 with ISE.

http://www.baltissen.org/vhdl/RB65_ISE.syr
Here you can see the output of ISE. If somebody can explain it a bit to me, that would be great! I am mainly interested in those things that I can connect directly to my design.

_________________

Hi Ruud
thanks for sharing your synthesis report file.

You should always check the warnings, and ideally get rid of them. Otherwise the tool might misbehave, or the synthesis might not match the simulation.

The first resource tabulation is

and it's worth checking that against your expectations and perhaps against other implementations - or your previous revisions.

And then the same again, for the next tabulation ("Advanced HDL Synthesis Report")

You might ask yourself, in this case, why you have 5 16-bit adders. You'll need to review your HDL and maybe do some research, but this is an example of a question worth answering.

Finally, it can be interesting to look at the timing report, to see how complex the logic trees are:

It might be worth trying to see where those 16 levels of logic come from, if the timing isn't as good as you expect, or maybe as a way to understand the area usage. Maybe the pipelining hasn't come out as you expect.

Essentially, you're looking for reasons why things have turned out more complex than you expected.

Hope this helps
Ed

Hallo allemaal,


I just found two HUGE bugs in RB65 :( I found them while testing RB65816. PLx and RTI are concerned. By coincidence, when placed in the right order, they eliminate each other. And that's just what happened in the test ASM for RB65. The combination still produces other errors but my test isn't that lowlevel anymore at that stage.

I cannot upload the improved version until tomorrow, maybe this afternoon.

_________________

I updated RB65 as promised:
http://www.baltissen.org/vhdl/RB65.vhd

I also updated:
http://www.baltissen.org/vhdl/RB65816.vhd

_________________