Proper 65C02 core

[MichaelM]

I have very little information on the 65CE02. The information that I gathered on that 6502-variant from the web indicated that it was not a commercially released product, and that the information provided may not be accurate. If someone here has information regarding the instruction set differences and the behavior of the instructions, then I would consider developing a specifc variant.

[GARTHWILSON]

The data sheet in on this site at http://archive.6502.org/datasheets/mos_65ce02_mpu.pdf .

It was pretty exciting to hear of it in the late 1980's, but nothing much became of it. I have a couple here but I put one in my workbench computer's 65c02 socket and it didn't work and I never tried to find out why. The 65816 (or even 65802) is a much better path to take.

[MichaelM]

Thanks Garth. After reading through the data sheet, I think that I agree with you that a 65816/65802 may be a better follow-on project instead of the 65CE02. I had thought about asking BDD about such an endeavour, but it will have to wait for a couple of months. I have a couple of projects on my plate at work, and this is just a hobby, albeit very close to what I do at work.

[BigEd]

There's a subset of the 816 which is of interest : just emulation mode, and a subset of the new opcodes. Even sticking to 16-bit addresses gives you something useful. You can extend to 24bit addresses using some of the new addressing modes. John Kortink has a project with a variant BBC BASIC ROM which uses this approach.

I have this subset in mind should I start extending a core.

Cheers
Ed

[GARTHWILSON]

Running the '816 in native mode does not require latching, decoding, or using bits 16 to 23 of the address. You can totally ignore the high address byte and still get a ton of benefits, which is what the 65802 was about. I don't know why WDC discontinued the '802, but it seems like if we can get the '816 in PQFP again, there's quite a bit of interest in Daryl's module that puts an '816 into a 6502 DIP socket.

[MichaelM]

Need some corroboration on the Rockwell instructions. One source indicates that the RMBx/SMBx instructions do not affect the processor status word, i.e. no flags are modified. Another source indicates that these instructions affect the Z flag.

Does anyone know the scoop on these instructions?

[BigDumbDinosaur]

MichaelM wrote:

Need some corroboration on the Rockwell instructions. One source indicates that the RMBx/SMBx instructions do not affect the processor status word, i.e. no flags are modified. Another source indicates that these instructions affect the Z flag.

Does anyone know the scoop on these instructions?

According to the W65C02S datasheet, RMBx and SMBx have no effect on the status register. See page 28.

[BigDumbDinosaur]

BigEd wrote:

There's a subset of the 816 which is of interest : just emulation mode...You can extend to 24bit addresses using some of the new addressing modes. John Kortink has a project with a variant BBC BASIC ROM which uses this approach.

Technically your statement is correct. However, consider the following emulation mode behaviors:

• The '816 does not generate a bank address during Ø2 low, which means the processor is incapable of addressing memory beyond $00FFFF, regardless of the values in the data bank (DB) and program bank (PB) registers.
• As the '816 does not generate a bank address any instruction that implicitly refers to DB or PB will not work as it would in native mode. Examples include MVN and MVP, which in emulation mode can only address zero page.
• When an interrupt occurs the '816 does not push PB to the stack but does force that register to $00. Upon executing RTI at the end of the ISR PB will continue to be $00, which means the '816 will no longer be capable of executing code beyond $00FFFF.
• The REP and SEP instructions cannot modify the m and x status register bits, thus preventing the selection of 16 bit registers.
• The stack is established at $01xx and is limited to a single page.

Emulation mode was devised to satisfy an Apple requirement that the '816 be adaptable to the ][c and ][e designs. It makes no sense to use the '816 as a 65C02 in a fresh design. Also, as Garth noted, the '816 is completely functional in a system with no more than 64K of RAM—just omit the bank latching hardware.

[BigEd]

Are you quite sure that emulation mode is incapable of high addressing? That isn't my understanding.

[MichaelM]

BDD:

Thanks for your reply. Just wanted confirmation that the desired behavior is given by the W65C02S datasheet and the "Programming the 65816" manual, and not as described elsewhere on the web.

Have completed the modifications to the M65C02 core to incorporate the 4 (32 opcodes) Rockwell instructions, and WAI and STP. Just finished checking out the Rockwell instructions, and am setting up to checkout WAI; STP has already been inadvertently checked out.

[GARTHWILSON]

Quote:

Emulation mode was devised to satisfy an Apple requirement that the '816 be adaptable to the ][c and ][e designs. It makes no sense to use the '816 as a 65C02 in a fresh design.

Yes, they had to keep full backwards compatibility with earlier Apple II models, something that's irrelevant if you're building your own non-Apple-II computer. One might want to initially leave the '816 in emulation mode to test out part of his board with what acts like the familiar 65c02, and in fact I'm still running older 65c02 Forth software on my '802 too. But when the builder/programmer who does a lot of assembly language sees the advantages of the extra instructions and addressing modes, switchable 8/16-bit registers, reduction in the number of instructions needed to do a lot of things, relocatable zero page, unlimited stack for local environments, etc., he'll be hooked. Address bits 16 to 23 are not needed to gain these advantages.

BigEd wrote:

Are you quite sure that emulation mode is incapable of high addressing? That isn't my understanding.

There's too much to write here, but the differences are found in the programming manual starting on page 58. Many of the '816-only instructions can be used in emulation mode too, but if you take advantage of them, the code won't run on a 6502 anyway; so you might as well go into native mode and enjoy the '816 as an '816.

[BigEd]

No, it makes complete sense to use an 816 in emulation mode and use far addressing to make use of high memory.

[BigDumbDinosaur]

BigEd wrote:

No, it makes complete sense to use an 816 in emulation mode and use far addressing to make use of high memory.

Ed, you can't access RAM beyond 64K when the '816 is in emulation mode, as it does not generate the A16-A23 address bits. In other words, the '816 cannot "see" anything beyond $00FFFF in emulation mode. Even if you code something like:

Code: Select all

         lda $123456,x

the MPU will not do anything with the $12 part of the address. That is, the instruction will effectively be:

Code: Select all

         lda $3456,x

In emulation mode, the '816's addressing is exactly the same as the 65C02's, a characteristic unambiguously stated on page 53 of the data sheet:

• 7.7.2 The following instructions may be used with the emulation mode even though a Bank Address is not multiplexed on the Data Bus: PHK, PHB and PLB

Emphasis added. PHK pushes the program bank (PB) register (there's no corresponding pull instruction), and PHB and PLB respectively push and pull the data bank (DB) register. It doesn't matter what you do with these instructions in emulation mode: A16-A23 will not be MUXed on D0-D7 when in emulation mode.

As I earlier opined, running the '816 in emulation mode in a new design makes no sense except in the narrow context of initial hardware testing (as Garth noted).

Incidentally, it is somewhat misleading to refer to emulation mode as "65C02 compatibility mode." While the '816's behavior in emulation mode is very similar to that of the 65C02, it is not an exact duplicate. All 256 opcodes in the '816 are defined instructions, whereas some of those opcodes are NOPs of various sizes and cycle lengths, or are different instructions, in the 65C02. For example, the '816 does not have the RMBx and SMBx instructions found in the 'C02. Putting an '816 into a 65C02 system is electrically possible but may not produce the expected operation if the 65C02 system uses the RMBx or SMBx instructions.

[BigDumbDinosaur]

GARTHWILSON wrote:

There's too much to write here, but the differences are found in the programming manual starting on page 58.

One area where the programming manual is incorrect is in stating that the '816 can address 16MB while in emulation mode (page 59). As the '816 doesn't generate the bank address in emulation mode, that statement is wrong.

[MichaelM]

For those interested, I have posted Release 2.4 of the M65C02 core to its GitHUB repository. The core now incorporates all of the W65C02S instruction set. It now performs indirect jumps through the appropriate vector: NMI, RST, IRQ/BRK. Further, the core does not push any registers onto the stack when performing a RST operation.

A memory interface and an interrupt handler are required to be wrapped around the core to form a functioning processor. The core provides sufficient status signals such that most 65C02 bus interface signals can be easily derived.

Before wrapping up this project, I will put together a suitable wrapper for a processor module with a 65C02-compatible external bus architecture. Hope to have that completed before Christmas. I will also try to wrap up any outstanding documentation before the new year.

Thanks for everyone's comments, critiques, and encouragement. This project and the interactions with everyone on the forum has been a great experience for me.