-
Notifications
You must be signed in to change notification settings - Fork 8
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
base: main
Are you sure you want to change the base?
Conversation
default: | ||
panic("unhandled addressing") | ||
panic(fmt.Sprintf("unhandled addressing: %v", in.addressing)) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Absolutely, thanks for getting it started.
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. |
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.
7b0a28c
to
af4d734
Compare
@pda OK, I've added the remaining new instructions and additional addressing modes. This is probably ready to merge. |
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.
@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.
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?