On a little further reflection, I can't see that the plain ordinary 65Org16 will be socket-compatible with existing 6502 software. It might be socket-compatible with a 6502 system, if you wrote software very carefully.

A better bet would be to make a fork of 65Org16 which added a mode for an 8-bit bus, or even a full 6502 mode, and then try to figure out how to get the benefits of 16 bit operation with 32 bit addresses at the same time.

Backward compatibility is always going to mean extra work!

Cheers
Ed

I can at least confirm that this idea can work!

Cheers
Ed

Thanks, yes, I know :-) Ruud has already (also) done this and I have his core (VHDL) and his pinout, so I have a good starting point. I was just wondering if other cores would work the same way.

André

I feel a divergence in the 6502 HDL force...


You mean to say, you were wondering what the "competition" is doing?

Hi André
Thinking more about this, I've come to this summary:

On the plus side, 65Org16

- gets us a 32-bit address space
- low effort for the core design and spec (all the heavy work from an existing core)
- is easy and familiar to the 6502 assembly language programmer
- gives us some memory bandwidth and performance advantage
- gives us opcode space and a starting point for architectural exploration
- perhaps a step towards a 65Org32 which has some more of the same advantages (and disadvantages)
- some chance of porting existing assembly sources(?)

On the minus side

- it turns out that porting an assembler isn't trivial, because 16-bit bytes are a strange idea
- does demand new system designs, not socket compatible
- any further architectural developments might go off in several directions at once

I think it's good that we(*) have something working on FPGA, and sources available on github. It's implementation first, of a trivial (or pre-existing) specification, which is the opposite of the other two active projects. I'm supportive of those efforts too - I don't see this as a competitive situation, more an exploration of different approaches.

Cheers
Ed

(*) so far only me, I think.

Thanks for that comparison of advantages and disadvantages.

My approach is different, in that of course the heavy work still has to be done (the core), but on the other hand it is (will be I hope, with adapter) plug-in-compatible to a 6502, running original 6502 software, which keeps the effort on this side much lower, at least for the start...

Btw, when I have done some initial core that shows some kind of life and can run _some_ (for some definition "some" ;-) ) 6502 software (even if only in simulation), I plan to publish it as well under an open source license.

As you say, I also don't see it as competition, I am always interesting to learn about other approaches, maybe you even find something interesting in my approach too...

André

With a very quick mental "walk around the block" of thinking about it, I immediately anticipate a lot of problems. If a higher-powered, backward-compatible, 40-pin drop-in replacement for the '02 is desired, I think trying to accomplish that with the 65Org16 would complicate the design an awful lot and negatively impact its performance for the intended purpose.

I'm glad we have multiple members here who are getting into processor design in FPGAs, and I'm glad to see so much interest spring up in the last year. Much will be learned in the process of extending the '02 design to wider buses and registers, and I suspect that it would be more beneficial to apply this learning to a separate version for dropping into already-existing boards with 8-bit data buses. I can imagine three major processors coming out of this effort: a higher-powered 8-bit processor (65Org2?), a 65Org16 with 64K pages and no bank boundaries, and the 65Org32.

With the exception of any program using BCD mode, since it is specific to 8 bits right now, I think it would work...
I was working in porting over an assembler/disassembler made for the C-64 to my 6502SoC, both 8-bit machines. I was actually very close until, you BigEd, opened pandora's box. My interest in the 65Org16 was immediate, because I knew and understood what you had done, and it wasn't too complicated when one compares your creation to the original code... Not putting you down here, especially since you had the foresight!

Now, at this gentle period of 65Org16 growth, I am planning to go back to the 6502SoC and make this Micromon program work for the 8-bit core, then try to port it over for the 65Org16 core. I just checked and Micromon does not use BCD mode, so it should be fairly easy...

BTW, as far as my comments on competition: I only meant competition in the way that Andre and RUUD seem to be using VHDL, so implementation of ideas as far as code is concerned will be foreign and not easily compared until the end product. Even if their code was posted somewhere.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I am interested in using the 65Org16 core and got the Verilog source from Big Ed's GitHub page. I have compiled it for an Altera EP2C20F484C7 FPGA and the flow summary shows that only 690 cells and 2304 bits of ram have been used. This seems VERY light to me. Have I got the correct files?

Welcome, and very nice to see you picked up the core! There's a good chance you do have it right, as the core is a simple extension of Arlet's very compact core. I've never run the Altera tools, but on Xilinx I see 360 slices mentioned here:
viewtopic.php?p=17522#p17522
(A Xilinx slice, in their older tech, give 2 LUTs and 2 flops, so probably 360 slices is close to 720 cells and that fits well with your 690.)

(There might be a better tabulation or analysis somewhere, but that's the one I found first.)

(For finding 65Org16 threads, there's a summary at
viewtopic.php?t=1982
)

Ed,
Thanks. I am somewhat flabbergasted the core is so small. I downloaded a cycle accurate 65c02 and the thing takes about 4500 LEs on the Altera device. I guess one doesn't need many resources if total compatibility is not required.

Also, what is the status of the full 32 bit version (65Org32 or other) of the 6502? It would be the bee's knees for making an up-to-date 6502-ish computer.

My core uses the same cycle count per instruction as the 6502. It does however not attempt to replicate the exact bus accesses in each cycle, so that the core design would fit better with modern FPGA design flow, rather than the original 6502 design based on latches and 2-phase clocks.

I figured that a complete system would also put the peripherals inside the FPGA, so they could also be 'upgraded' to match the core. For instance, the core works really well with on-chip synchronous memories. Also, I assumed the number of cases where someone would actually care about sub-instruction cycle behavior would be very limited.

I do wonder where the 2304 bits of RAM come from. Can you see what they are used for ?

Arlet,
Thanks for the clarification. Does your core output the same type of address nonsense that the 6502 did during internal cycles?


I have examined the RTL and the detailed fitter report and it appears that the optimizer elected to make a wide "or" gate component into a ROM lookup table instead of random logic.

I have not attempted timing closure, but the fitter says this thing will run at 65MHz. This is likely over optimistic, but surely fast enough for what I was thinking.

Yes, the core does have similar internal cycles, and outputs similar type of address nonsense. I haven't studied it for all cases, but most likely you'll see the address on the wrong page (in case of page boundary crossing), or from PC, not something totally random.

It could be avoided by removing those cycles, but then the timing wouldn't be compatible anymore, and it would require a bit of extra logic, such as 16 bit address calculator. Another option would be to add an 'output enable' signal to the core, to signal if a read cycle is valid.

I had the (8 bit) core running at 100 MHz on a Spartan 6, but obviously the 16/32 bit variants are going to be slower.

Arlet,

100MHz is surely flying. I am going to get started on hooking this up to some of Grant Searle's Multicomp peripherals on my Terasic DE1 board and see what happens. I figure I will start out with a cpu clock of 5MHz or so just to get things working and see where it can go from there.