lefticus / 6502-cpp

The Unlicense
244 stars 43 forks source link

Feature Request: 6510 Unintended OpCodes #1

Open gitjeff2 opened 8 years ago

gitjeff2 commented 8 years ago

As time permits please add support for 'illegal opcodes.' An excellent reference exists at NMOS 6510 Unintended Opcodes: No More Secrets.

The 6510 on the C64 had these op-codes but other variants of the MOS 65xx family did not. For example, the 8-bit chip 65C02 (common in early C64 accelerators) lacked support for these op-codes. Also, the 16 bit variant WDC 65C816 found in the SuperCPU, the Apple 2GS, etc. redefined these codes to entirely different (now valid) op-codes. So, you'll probably want to use a command line switch to enable/disable this feature if you add it.

It's worth noting that modern C64 accelerators such as the Turbo Chameleon 64 do support these op-codes and even today some demo coders use them to save a few CPU cycles now and again.

lefticus commented 8 years ago

Newer version here: http://csdb.dk/release/download.php?id=178508

mattgodbolt commented 8 years ago

Did you mean to link to a file on drive C:\ :) ? On Wed, Aug 17, 2016 at 11:47 AM, Jason Turner notifications@github.com wrote:

Newer version here: file:///C:/Users/Jason/Downloads/NoMoreSecrets-NMOS6510UnintendedOpcodes-20152412.pdf

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lefticus/x86-to-6502/issues/1#issuecomment-240473288, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmsdV2AkwMOyq89YAW-vS8Sfa8FxHYHks5qgzsVgaJpZM4JK-7y .

lefticus commented 8 years ago

@mattgodbolt already fixed.

robindegen commented 7 years ago

Does anybody know how many of these opcodes are supported in the NES 6502 (Ricoh 2A03)?

BigEd commented 7 years ago

The NES uses a slightly hacked copy of the NMOS 6502, so, aside from decimal arithmetic, it's identical to that, and therefore identical to the 6510.

dr-m commented 2 years ago

As far as I understand, the core of Ricoh 2A03 is an exact copy of the NMOS 6502, only disabling a transistor to circumvent a patent. Unfortunately, http://www.visual6502.org seems to be unavailable right now.

This request is conceptually related to llvm-mos/llvm-mos#54. @llvm-mos looks very promising to me. It does not appear to support any unintentional NMOS 6502 opcodes yet. To my understanding, it should be relatively easy to implement something in the assembler, but making use of those opcodes in the backend is a different matter. Some comments to this blog post could give useful ideas.

robindegen commented 2 years ago

The BCD opcodes are missing in the 2A03 afaik to make room for sound support

dr-m commented 2 years ago

@robindegen, by BCD opcodes, do you mean sed (0xf8) and cld (0xd8)? What would the 2A03 map these opcodes to, and how would this remapping have been done? I was under the impression that everything is identical to the layer and transistor level, including the logic array for decoding instructions. I have understood that only the transistor(s) that connect the Decimal flag to the ALU (which implements the ADC and SBC instructions) has been disabled in the 2A03 die.

BigEd commented 2 years ago

For more on the decimal mode changes, see the (archived) page of the visual6502 wiki: https://web.archive.org/web/20210405071434/http://visual6502.org/wiki/index.php?title=6502DecimalMode#Decimal_mode_and_the_NES.27_RP2A03G

robindegen commented 2 years ago

@robindegen, by BCD opcodes, do you mean sed (0xf8) and cld (0xd8)? What would the 2A03 map these opcodes to, and how would this remapping have been done? I was under the impression that everything is identical to the layer and transistor level, including the logic array for decoding instructions. I have understood that only the transistor(s) that connect the Decimal flag to the ALU (which implements the ADC and SBC instructions) has been disabled in the 2A03 die.

I'm actually not sure what the behavior is when you actually call these opcodes; the cpu might just hang or have other strange side effects. There is a bcd mode flag in the status register which shouldn't be used; that I know for sure. I'm not sure about the opcodes themselves; i'm trying to figure that out.

See https://web.archive.org/web/20130406065431/https://forums.nesdev.com/viewtopic.php?f=9&t=9813

After detailed study of 2A03 circuit following results were obtained:

  • No differences were found in the instruction decoder
  • Flag D works as expected, it can be set or reset by CLD/SED instructions; it is used in the normal way during interrupt processing (saved on stack) and after execution of PHP/PLP, RTI instructions.
  • Random logic, responsible for generating the two control lines DAA (decimal addition adjust) and DSA (decimal subtraction > adjust) works normally.

The difference lies in the fact that the control lines DAA and DSA, which enable decimal correction, are disconnected from the > circuit, by cutting 5 pieces of polysilicon (see picture). Polysilicon marked as purple, missing pieces marked as cyan.

As result decimal carry circuit and decimal-correction adders do not work. Therefore, the embedded processor of 2A03 always considers add/sub operands as binary numbers, even if the D flag is set.

So indeed as you say, the sillicon is there; but you can not use the functionality. If you need BCD, you must emulate the behavior with other opcodes in software.