Skip to content

cpu: add basic support for some 65C02 opcodes #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

rjw57
Copy link

@rjw57 rjw57 commented Apr 15, 2015

This is very much a RFC rather than something which is finished and proposed for
merging. I've got my own 6502 homebrew project at https://github.com/rjw57/buri
and I make use of the 65C02 instructions such as PHX, PHY, etc.

This commit adds just enough support to boot the 65C02 ROM image I have. This is
a work-in-progress change and is not complete 65C02 support by any means.

My question is: is this worth pursuing further? Would you be interested in 65C02
support? If so, would you want some form of configuration allowing 65C02-support
to be switched on/off?

default:
panic("unhandled addressing")
panic(fmt.Sprintf("unhandled addressing: %v", in.addressing))
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is mostly for debugging. If one was going to report the addressing type properly, one would use the naming table.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep — not perfect, but more useful than it was before; thanks.

@pda
Copy link
Owner

pda commented Apr 15, 2015

is this worth pursuing further? Would you be interested in 65C02 support?

Absolutely, thanks for getting it started.

If so, would you want some form of configuration allowing 65C02-support to be switched on/off?

That would be a “nice to have” — I like the idea of a mode to verify code runs on original NMOS hardware, but not worth doing if it's going to add too much complexity.

A tangent of that question would be whether to support commonly used illegal instructions. Aiming for a “pure 6502” mode which doesn't support the original illegal instructions would feel half-done.

The main use-case of this project is software development/debugging for 65C02-based homebrew computers, so it's probably fine to unconditionally support 65C02 instructions.

@rjw57
Copy link
Author

rjw57 commented Apr 15, 2015

The main use-case of this project is software development/debugging for 65C02-based homebrew computers, so it's probably fine to unconditionally support 65C02 instructions.

It certainly makes it easier to do in that case. I'll keep the new instructions obvious in the source so if there is some configuration later it should be easy enough to add. As you say, it's mostly useful for us homebrew-ers :).

Add support for the new addressing modes and new instructions in the 65C02
family of processors. The distinction is noted in the source but is not exposed
to the programmer yet.

New instructions: BRA, PHX, PHY, PLX, PLY, STZ, TRB and TSB.

Add the (zp) addressing mode to ADC, AND, CMP, EOR, LDA, ORA, SBC and STA.

Add (abs,X) and (zp,X) addressing modes to BIT.

Add accumulator implicit target for DEC/INC.

Add (abs,X) addressing mode for JMP.
@rjw57 rjw57 force-pushed the rfc-proposed-65C02-support branch from 7b0a28c to af4d734 Compare April 16, 2015 10:10
@rjw57
Copy link
Author

rjw57 commented Apr 16, 2015

@pda OK, I've added the remaining new instructions and additional addressing modes. This is probably ready to merge.

rjw57 added 6 commits April 21, 2015 22:42
Make PL{A,X,Y} instructions set processor status flags.
The SEI and CLI instructions, counter intuitively, set interrupt disable and
clear interrupt disable. Hence to *enable* interrupts (and clear the I flag) one
issues CLI and to *disable* them (set the I flag) one issues SEI.
@rjw57
Copy link
Author

rjw57 commented Apr 21, 2015

@pda I've been moving forward with my own simulator and found a few bugs/omissions in go6502. I've added them to this PR although they're not strictly speaking 65C02 compatibility. The most serious bug is that PLA did not set the N or Z status flags which breaks Enhanced BASIC.

Fix a misunderstanding about what indirectX addressing was.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants