17

The Wikipedia page on the MOS 6502 mentions a hardware device called the Trap65 which apparently sat between the 6502 and its socket to trap any undocumented opcodes. The wiki page has the usual citation needed so I suppose it could be a lie.

Assuming such a device existed, how did that work? Does the 6502 have a split I/D memory? How else could the Trap65 detect if the byte being read was an instruction or something else?

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274

2 Answers2

20

This is explained in “Add a trap vector for unimplemented 6502 opcodes” by Carl W. Moser, published in Dr. Dobb’s Journal volume 4, page 32 (page 42 in the PDF; this is linked from the Wikipedia article on the 6502). The 6502 outputs a sync pulse on pin 7 whenever it reads an opcode, but not when it’s reading anything else (the second or third bytes of an instruction, or memory reads done during the instruction’s execution). See also page 7 of the 6500 family datasheet, and BYTE volume 5 issue 10 pages 282 and onwards, which has an extensive bibliography.

The article has a detailed circuit diagram showing how a Trap65-style device could be implemented. That doesn’t prove that the Trap65 did exist, just that it would be possible!

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
  • 1
    Is this what the designers of the 6502 intended that sync pulse to be used for? – Omar and Lorraine Apr 06 '17 at 13:39
  • 3
    No, AFAICT the sync pulse was intended for single-stepping: with the ready signal you can stop the CPU while it’s reading an opcode. (That’s what the datasheet mentions.) – Stephen Kitt Apr 06 '17 at 13:46
  • 1
    It's also used on other hardware for paging — e.g. on the Acorn Electron's Slogger Master RAM Board to give the code in one segment of the ROM visibility of one bank of RAM while everything else sees a different bank. That arrangement is probably partly to do with retrofitting a new paging scheme over a largely unmodified version of the OS, but it does raise an interesting observation: the 6502 could be used in a Harvard architecture machine, as long as your SYNC watcher had a lookup table for opcode lengths. – Tommy Apr 06 '17 at 14:56
  • Yes, and it can also be used to add new opcodes (as demonstrated in the BYTE article). It opens up a host of possibilities... The 6502 is very versatile. – Stephen Kitt Apr 06 '17 at 15:02
  • I would think a more useful purpose for that approach would be to add I/O "instructions". For example, make any instruction 0nnn1d11 strobe an 8-bit addressable latch with address n and data d while putting 0xEA on the bus, and make 0nnn0d11 output either $50 or 0x70 depending upon the xor of a value from a one-of-eight mux [the eight inputs to the mux should be synchronized to avoid weirdness]. – supercat Apr 06 '17 at 18:53
  • Adding hardware like that to a 6502 system would provide eight output ports that could be set or cleared in a one-byte two-cycle instruction, and eight input ports which, if the state of the V flag was know, could generate conditional branches as a two-byte instruction that would take only two cycles when not taken and three when taken. – supercat Apr 06 '17 at 18:55
  • Note: the data sheet PDF appears to be scanned from a paper copy; there are lots and lots of transcription errors. – Nisse Engström Apr 11 '17 at 20:32
4

"a hardware device ... which apparently sat between the 6502 and its socket to trap any undocumented opcodes. ... Assuming such a device existed, how did that work?"

That sounds a lot like "the KK Computer: a Radical 6502 Redesign".

The 6502 was designed to have a unified Princeton architecture, not a split I/D memory. However, the 6502 has a "SYNC" pin that pulses when an opcode is fetched, which is how the KimKlone "detect if the byte being read was an instruction or something else". (I would be surprised if the Trap65 used any other method of detecting which memory reads were instructions).

In the KimKlone ("KK"), the SYNC output pin of the 6502 (op-code fetch) and the phase 2 output pin of the 6502, and the memory data bus, are the only inputs to a few standard logic chips that track exactly what instruction is executing and how many cycles it has gone into that instruction -- including the "new" instructions that the KimKlone substitutes for many previously Undefined instructions -- as documented in "KimKlone: Processor Partnership".

The KimKlone splits the data bus into the "memory data bus" and the "CPU data bus". During an instruction fetch (i.e., when the 6502 pulses the SYNC pin), the data from the memory bus goes into 4 chips:

  • the KK latches the actual data from memory into the KK's instruction register (a 74x273 chip).
  • Meanwhile, all 8 bits go into a 74xx245 bus transceiver.
  • Meanwhile, the high 5 bits (xxxx_x) drive a 74S288 EPROM, which selects a substitute opcode.
  • Meanwhile, the low 3 bits go into a small decoder that tests that instruction on the memory data bus for xxxx_x011 patterns, which are all single-cycle NOPs on the 65C02.

If the decoder detects a xxxx_x011 pattern during the op-code fetch, that pattern never reaches the CPU bus -- the KK disables the transceiver and enables the EPROM to drive a substitute 65C02 op-code into the CPU on the CPU data bus. During all other times (the decoder detects a "normal" 65C02 instruction being fetched, or the decoder sees a normal data LOAD or STORE where the SYNC pin doesn't pulse) -- that decoder enables the transceiver that connects the memory data bus and the CPU data bus normally. (Apparently Laughton considered the possibility that the decoder + EPROM might not be fast enough to do this before the 6502 latched the instruction, and the backup plan was to allow that single-cycle NOP to execute normally, and then substitute a "normal" 65C02 instruction on the following cycle).

Because the KK latches the original instruction from RAM (not the possibly-substituted instruction going to the 65C02), it can continue doing the "extra stuff" necessary to implement that specific new instruction. The hardware schematic in the Carl W. Moser article unconditionally substitutes a NOP instruction, but the KK sometimes substitutes some other instruction, so some of the new instructions of the KK can re-use the 6502 address generation unit rather than requiring extra external hardware to do that work.

Jeff Laughton has documented all the details on how the KimKlone works and how to re-implement it, starting at "KimKlone: Introduction & Table of Contents".

David Cary
  • 216
  • 2
  • 7