tag
text ' the supervixen has started! '
start
LDX #42
loop
LDA tag,X ; Copy text buffer
STA $2000,X
DEX
BNE loop
end
NOP
JMP end
It happends every time with both the extended 65C02 and Arlets original. Can you check if this is generally true or if its only in the Active-HDL simulator?
I also had problems with stopping the core with RDY, so used the workaround with extending the Clock cycle that seems to work fine (same as used by the SuperCPU of C64).
I've checked on FPGA, and the core is working as expected - I put an INC $3000 in the JMP loop so I could see if it had gone around. (I needed that because I have to reset the 6502 to get out of the JMP loop.)
(Might be worth noting: you're not copying the zeroth element of the string, so need to tweak your loop a bit.)
(Might be worth starting a new thread for a support problem or bug report, rather than using an announcement thread. I read all new posts in every part of this forum, as I think do many others here, so don't worry about not being seen.)
I've checked on FPGA, and the core is working as expected - I put an INC $3000 in the JMP loop so I could see if it had gone around. (I needed that because I have to reset the 6502 to get out of the JMP loop.)
(Might be worth noting: you're not copying the zeroth element of the string, so need to tweak your loop a bit.)
(Might be worth starting a new thread for a support problem or bug report, rather than using an announcement thread. I read all new posts in every part of this forum, as I think do many others here, so don't worry about not being seen.)
Ok, sorry I will make it a new tread.
Edit: I made the 65C02 run in the Lattice MachXO3. It seems to be able to run above 33MHz, but currently I have limited it to 22MHz. Note that you can get the MachXO3 for around 2-4$/pc.
Last edited by kakemoms on Mon May 15, 2017 8:44 pm, edited 1 time in total.
Today I finally got a Xilinx installation working under Linux (actually, under two Linuxes - Ubuntu 16.04 and Centos 6.10 running in a Docker container... the setup is frankly bizarre, but it should be possible to make it somewhat less so).
I then took enso's build setup for CHOCHI (45_004) and modified it to use the 65c02 core; I also reduced the clock frequency to 40MHz, as I had some problems that I thought might be caused by running at too high frequency.
I'm a complete beginner at this, so even these small steps have been quite rewarding
Thanks for posting! It's useful to have these data points.
Windfall wrote:
(apparently the microcode is hurting performance in this context).
Hmm.. a slightly hasty choice of words, perhaps. It's fair to say clock speed was affected. But performance is more complex to evaluate. The M65C02 has a far more powerful instruction set than the 65C02, and (except in simple, 8-bit applications) its performance may exceed that of the 'C02, clock rates notwithstanding.
Edit: oops, the link and the comment aren't directly pertinent. It's the M65C02A I was thinking of.
Last edited by Dr Jefyll on Fri Sep 15, 2017 12:28 am, edited 1 time in total.
The M65C02 has a far more powerful instruction set than the 65C02, and (except in simple, 8-bit applications) its performance may exceed that of the 'C02, clock rates notwithstanding.
I'm not sure what you're talking about here. Arlet's (the 65C02 version) and MichaelM's cores have the same instruction set. Former uses the same number of cycles as the original, latter uses a few less here and there. Otherwise, there are no differences.
My second goal was to reduce the size of the core's logic so that I could include support for additional addressing modes, 16-bit operations, and make the architecture more compatible with high level languages such as C and Pascal. A sub-goal was to maintain seamless compatibility with the W65C02S in order to execute 6502/65C02 code at any time. This goal has been met by a redesign of the ALU and address generation logic of the M65C02 core. Additional controls and multiplexers were provided in both of these components so that several new addressing modes could be added in a backwardly-compatible manner with the 6502/65C02. The redesign of the ALU allowed the M65C02A ALU to be enhanced to support single cycle 16-bit logic, shift/rotate, and arithmetic operations in virtually the same footprint as the ALU for the 8-bit M65C02 ALU with the limitation that BCD addition/subtraction operations are limited to 8 bits.
My third goal was to provide instructions to directly support a DTC/ITC FORTH VM. The M65C02A provides a number of instructions that allow the implementation of both DTC and ITC versions of the FORTH VM. The instructions are supported by the addition of a module in the M65C02A core that provides the Interpretive Pointer (IP) and the Working (W) register. It also supports the 16-bit operations on these registers which are needed to use them effectively. A new IP-relative addressing mode was added and supported by three instructions: LDA, ADC, and STA. These instructions allow speedier access to literals, constants, and variables. In addition, the IP-relative ADC instruction can be used to implement efficiently relative branches.
Mike B.
[Edit: Oh, wait ... that's the M65C02A ... nevermind!]
