Add support for NMOS quirks and CMOS extensions

[breqdev]

Previously, we effectively implemented a hybrid chip with the features (and some undocumented opcodes, per #17) of the original NMOS 6502 but without some of the quirks. While most machines of the era used the NMOS chip, later models of the Apple II lineup used the 65C02 (as did other later machines) for its compatibility and increased featureset.

This PR adds a flag to the Mos6502 implementation to allow it to only run NMOS quirks (including undocumented opcodes and unintended reads) when set to behave as an NMOS chip and to enable the extra CMOS instructions if selected.

The new quirks are tested using the Klaus Dormann test suite for 65C02.

[ava-silver]

This PR adds a flag to the Mos6502 implementation to allow it to only run NMOS quirks (including undocumented opcodes and unintended reads) when set to behave as an NMOS chip and to enable the extra CMOS instructions if selected.

omg two chips for the price of one (feature flag) :3 😱

[ava-silver]

do we wanna add unit tests for this? i trust youve tested it manually but could also be neat :3

[ava-silver]

does it make sense to make this a march statement instead? in case there are other variants we wanna add in the future 👀 :3

[ava-silver]

or maybe thats premature optimization? 🍃

[ava-silver]

wait thoughts on matches!(thing, pattern) instead of the if let? probably just a stylistic thing, especially since you dont need to match on any parameters if that makes sense

[breqdev]

wasn't aware of matches!() but seems like exactly what i want! i alternated between if let and == in this and wasn't rly happy with it

im a bit against a full match statement bc that would kind of imply that quirks are likely to have varying behaviors for every version, where these quirks are more just special cases for one version at a time -- e.g. if NMOS has a quirk and it was fixed in CMOS, it's unlikely to show again up in e.g. the 65816 or something later

[breqdev]

e.g. you'd never really have a situation like this

match version {
  NMOS => do one thing
  CMOS => do another thing
  65816 => do a secret third thing
}

its more like, the little if statements sprinkled throughout account for each chip's separate set of errata, so something special-cased in for an NMOS quirk but skipped on CMOS wouldn't really be applicable if we added in a third generation

[ava-silver]

yeep, my 🍃 ass only realized that after i left the comment, makes total sense :3

[ava-silver]

nmos just got a lil quirky with it 🤪

[breqdev]

do we wanna add unit tests for this? i trust youve tested it manually but could also be neat :3

codecov looks like it lost the PR somehow :( will investigate

[breqdev]

fine, i'll do it myself 😼
codecov link: https://app.codecov.io/github/breqdev/noentiendo/commit/ad5810e09c9874d63843189014c2f5d4dbb1d4b6/blob/src/cpu/execute.rs

so the 65C02 extensions are tested as part of an existing test suite that gets loaded in and ran here:

noentiendo/src/systems/klaus.rs

Lines 93 to 113 in ad5810e

	#[test]
	fn test_klaus_65c02() {
	let roms = RomFile::from_file("bin/klaus_65C02.bin");
	let platform = TextPlatform::new();
	let pc = Rc::new(Cell::new(0));
	let mut system = KlausSystemBuilder::build(
	roms,
	KlausSystemConfig {
	pc_report: Some(pc.clone()),
	variant: Mos6502Variant::CMOS,
	},
	platform.provider(),
	);
	for _ in 0..=100000000 {
	system.tick();
	}
	assert_eq!(pc.get(), 0x24f1);
	}

the main limitations of using someone else's test suite like this is that it doesn't cover the undocumented/illegal opcodes for the NMOS version (which has been a limitation since #17) and we can't really poke at it to see what's going on as well. but from what i can tell it's a pretty standard correctness test, and verifies that status flags etc all work fine in addition to the core instruction behavior

not opposed to writing our own unit tests for opcode implementations but IMO that engineering time could probably be better spent elsewhere on e.g. memory banking logic, which in many cases is completely untested rn -- systems module sitting at <15% coverage rn 🤪

[ava-silver]

makes sense! good to hear it has some tests already, the tradeoff makes total sense :3

gonna approve now!

[ava-silver]

meow meow oomfie