Support for 65SC02

[42Bastian]

Support for 65SC02 (a 65C02 without the bit-branch instructions) would be great. This would help to add Atari Lynx support.

Anyway, great work!

[oziphantom]

To be clear a 65SC02 is a R65C02 without the extra Rockwell or the W65C02 instructions, and is basically a Pure 65C02.

[42Bastian]

65SC02 != 65CS02

[oziphantom]

Thanks fixed.

[fadden]

There are two levels of support:

1. Adding it to the CpuType enum and related functions. This makes it a thing you can use in the system definitions file, but doesn't really do much else.
2. Adding an actual definition for it, with all 256 opcodes declared to do something. It appears in the project properties as an option.

My approach so far has been to identify the broad archetypes (6502, 65C02, 65816, R65C02) and just implement those. (No R65C02 support at present because I haven't found code from anything that used one of those.)

If 65SC02 can, for disassembly purposes, be represented by the 65C02, then I'm tempted to go with (1) just to keep things simple. This wouldn't be correct for an assembler (which would generate bad code) or emulator (which would execute things it shouldn't), but the only down side for a disassembler is that it might not immediately detect when code runs into data.

The blurry data sheet I found for the G65SC02 makes it look a lot like the 65C02, for instruction set, bug fixes, and cycle counts. I don't see any additional instructions. I don't know if that's the same as the WDC version (I don't see a data sheet at http://6502.org/documents/datasheets/wdc/).

Do you see a reason why the 65SC02 needs a full definition, or can we get away with mapping it to the 65C02?

On a related note, the HuC6280 is listed as a 65SC02 derivative, and added a bunch of stuff; it would need its own full definition.

[oziphantom]

There is the R65C02 which adds the BBR/BBS type instructions and some others, the W65C02 add STP and WAI in top of the R65C02. The Huc6280 is a fork on the 65SC02 and has its own instruction some of which are 4 letter opcodes, which can be a hassle when things assume everything is 3 letters.

For all the models bar the SC and HuC6280 see the end of this document http://tass64.sourceforge.net/ it covers the N6502, Illegals, 65DTV02, 65C02, R65C02, W65C02, W65816, 65EL02, 65CE02, 4510

the only datasheet I was able to find for the 65CS02 is the GTE/California MD version here http://archive.6502.org/datasheets/cmd_g65sc02_mpu_mar2000.pdf

[fadden]

@oziphantom yeah, that's the blurry data sheet I found.

The Tass docs are a good reference. They seem pretty thorough in their support of 65xx CPUs, so I'm assuming the absence of a 65SC02 means there's no difference to an assembler.

My current plan is to add the 65SC02 as an alias of 65C02, and add an Atari Lynx stub to the platform definitions section with a reference to it.

[fadden]

https://github.com/fadden/6502bench/commit/99a77c0341ac7897b6b0c825a635097e78ed490f

[42Bastian]

Wow, too quick. I just wanted to suggest to add support for a configuration file instead of hard-coding the different 65xx derivates. A simple ASCII file might be sufficient: opcode,size,cycles,type,modifier,name This way one can even add SWEET16 or Z80 ;-)

[fadden]

If you poke around in OpDef.cs you can see some what's involved in defining CPU instructions. Besides the basic stuff like opcode mnemonic and address modes, we need to know how to determine what flags each instruction affects, how it impacts the flow of execution, which modifiers to apply when computing cycle counts, if it has special width-disambiguation behavior, etc. Then there's special-cases like BIT immediate, handling of 65816 wide registers, dealing with the fact that MVN/MVP have two operands instead of one, etc.

It's probably not all that hard to add SWEET16 and Z80, but it's way easier (for me) if the "configuration file" you open has a name ending in ".cs" and is part of the project. :-) Since this is an open-source project that can be built with free-to-download tools, the ability to define CPUs without modifying code is less important than it would be for a closed-source product.

[oziphantom]

I mean to make 65SC02 I could even set TASS to 65816 and just not use any of the address modes, or extra opcodes. As far as I can tell the 65C02 == 65SC02 just that since Rockwell made if first, normally when somebody says 65C02 is means the Rockwell one and the SC explicitly points out that it is NOT a Rockwell one, or the WDC version.

[42Bastian]

It's probably not all that hard to add SWEET16 and Z80, but it's way easier (for me) if the "configuration file" you open has a name ending in ".cs" and is part of the project. :-) Since this is an open-source project that can be built with free-to-download tools, the ability to define CPUs without modifying code is less important than it would be for a closed-source product.

Agree. But a config file is easier for those who cannot re-compile the tool (because they do not know or use Linux). But I see the complexity of designing the config file's syntax and parsing.

[fadden]

Marking this one as done. There's a general "make it easier to add assemblers" item in the "to do" list now.