Whether software written to run on the Commodore 64 will work on a 2MHz 6502 (Which 2 MHz 6502 system?) or not would have nothing to do with the code itself and everything to do with the host machine. The C-64 is a special case 6502 (specifically, 6510) system, due to its dual processor design, the second processor being the VIC. Since the 6510 and VIC have to share the same buses and address space, unavoidable timing constraints get into the picture, which would affect the C-64, not the 2 MHz unnamed 6502 system.

As Windfall is intimating, your design is not a 6502 unless it can execute the 6502 instruction set in its entirety, as well as correctly condition the flags in the status register according to the result of the most recent instruction. That isn't being a purist; it's merely stating an immutable fact.


One doesn't "compile" code with an assembler.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Another immutable fact is that kakemoms didn't call it a 6502, he called it a cut-down 6502. If I cut a tree down and haul away everything that falls, I am left with a tree stump, not a box of kittens. Whether or not the tree stump is as useful as the complete tree is subjective ... maybe I really wanted a solid picnic table base with no shade!




Mike B.

This certainly is an eye-rolling discussion, and not in an ideal thread for the purpose.

Can we perhaps leave kakemoms alone, until such time as the design surfaces in public? Or start a new thread to discuss this cut-down 6502, or any other cut-down 6502, or 6502 variations in general.

As far as I'm aware, we were only discussing what deserves the name '6502'. But maybe that's me.

As for the 2MHz 6502, I was thinking of my B600. But as it contains a 6509 that would strictly not be a 6502 under you definition either.

We can put it in another tread, but the whole discussion boils down to personal preferences. Generally it would be more interesting to see an overview of all the versions of the 6502-like hardcores and softcores, cut-down, different, overblown or just plain. So I will start a new tread for that.

In this case, I don't think so. A core is either a 6502, or 6502-like. Because the first has a well documented instruction set. The second requires it to be described.

Also, the discussion is not that interesting to start with ...


Now that would be interesting.

Elsewhere, kakemoms notes that the official supported WDC core runs a lot faster on a particular Lattice FPGA than this extended Arlet core:

I thought that was worth recording! (Arlet's core uses a register file for AXYS, which on Xilinx FPGAs results in a very small and efficient implementation. I don't know if X03 parts have the same trick. It's possible WDC have done some work to make an implementation which is a good fit to this FPGA's internal organisation.)

Well, WDC is a official supplier of IP cores for Lattice, so they probably have some tools that is not part of the freely available Diamond package for MachXO3. There is some information here if you want to explore the W65C832PXB (which I probably have to at some point).

I have been trying to get my head around this core in order to get it faster. Its fairly easy reading (thank you Arlet!), and at first sight I couldn't see wether there was anything to improve.

I do have a couple of questions though:

Why do you use so many case statements?

Why do you use blocking assignments as part of some case statements?

From my experience with XO3, blocking assignments is usually a bad idea for speed. Maybe other tools/pld´s get around it in a better way than XO3.

I can't comment on the XO3 experience regarding blocking and non-blocking assignments. Within the ISE Verilog compiler/synthesizer, blocking and non-blocking assignments produce different behavioral results in simulation, but are equivalent in synthesis. In the synthesizer, non-blocking assignments are required when assignments are made to "reg" variables, regardless of whether the "reg" variables are synchronous or asynchronous elements. Since synthesizable case <> end case statements require assignment to a "reg" variable, the assignment must be made using a non-blocking assignment: "<=".

Although it is possible to write simple case <> end case blocks using blocking assignments, in my opinion, it requires more effort on the part of the designer that the synthesizer is better able to do automatically.

In general, I use blocking statements only for logic that is simply and will always be implemented as asynchronous logic. I use case <> end case with non-blocking assignments in synthesizable code that may be implemented as either synchronous logic or asynchronous logic. I like to use case <> end case to let the tool solve the equations for me.

_________________
Michael A.

The problem may be related to the Lattice Diamond. It tend to underestimate the speed one can get from a core. Your core is somewhat ok (around 14MHz) while the tc_65c02 core by Jens Gutschmidt is reported to only run at 2MHz...

Since Lattice also includes the Synplify Pro as an alternate compiler, I have been able to also check how that implements the source. Your core is reported to run around 18-20MHz, while Gutschmidt's core fail to compile there.

In real life I had your core run up to around 25-28MHz, but that was the limit. Anything above and it would be unstable.

This is probably what I would call flavor differences. Still, it remains to be seen whether I can get your core faster IRL without thinking too hard about the reported values.

Thanks for the feedback. I was unaware that my core had been loaded into an FPGA from a vendor other than Xilinx or Altera. When targeted to a Spartan-3A XC3S200-5 FPGA, the predicted maximum operating speed is 28.796 MHz, and after PAR the reported operating speed is 29.622 MHz using a constraint of 29.49152 MHz. The difference between the predicted operating frequency and the constraint is approximately 2.5%. I have found that this relative difference between synthesis and MAP/PAR is a reasonable amount with which to push the MAP/PAR functions.

In the past, when timing various cores outside of a SoC configuration like the M65C02A, I found that the predicted and reported speeds were frequently quite different which corresponds to your reported experience. To make the comparisons more reasonable and consistent, I wrapped the various cores I was comparing to in a frame work which placed registers on the outputs and the inputs. I think that this approach provides a more consistent view of how the core will perform in a SoC configuration. IOW, it allows the synthesizer and MAP/PAR to correctly measure/estimate the path delays that determine the maximum operating frequency. The operating frequency reported by ISE at the completion of MAP/PAR is a value corresponding to the guaranteed performance of the FPGA vendor. To do so, they calculate these values using worst case values at the minimum operating voltages and maximum operating temperatures.

It is not all that surprising that you can push the FPGA operating frequency when operating at nominal voltages and temperatures. I do think that the wide variation you are reporting is probably associated with RTL/implementation differences between the cores than with the FPGA's performance variations due to changes in operating parameters such as temperature and voltage. The real world value your tool is reporting for my core also appears to be quite reasonable. In a -4 version of the XC3S200A FPGA, the core is reported to operate at 25 MHz. A 20% improvement or loss in performance is not unreasonable for the -4 and -5 speed grades.

_________________
Michael A.

Lattice´s site now has published values of the WDC65c02 core (on EP and EP2) of 42MHz. This is probably the frequency at which you can run the WDC core stable (at any temperature, weather and moon phase).

Anyone has a link to software that stresses the 65c02 core in different ways?

Good question - I've asked it on a new thread over here.

Hi

I am trying to use this core for a project I have, but I have a problem with it. I don't think its in my testbench, but I can't be 100% sure. I am testing it under Lattice Diamond and Active-HDL simulation.

The thing is that the core starts as it should. Goes on to read reset vector and jumps to that position in memory. All is fine except that the stack pointer is undefined. It shows as 8'hxx.

So I tried to set the stack to $fd which is what the 6502.org visual simulator shows the stack to be once it resets and starts running (well, it doesn't really show the whole reset since it starts at memory location $0000 and not at $fffc, so maybe the stack pointer is different).

The thing is that the stack pointer should not be undefined, but trying to set it to some value ends with the core crashing. I don't know what happens, but something seems to become confused.. Well, at least me.

Anyway, is the stack pointer left non-initialized for a reason?