Talking to Claude about the 6502 Set Overflow pin

I was looking at the data sheet for the Rockwell 6502 and I noticed that there is a Set Overflow line labelled SO:

I found this discussion on retrocomputing.stackexchange.com: What happened to the SEV instruction on the 6502? which explains how some people used this:

The answer is that the 6502 has a specific input pin, SO, which can be used by external hardware to set the overflow flag. The intention is low-latency hardware interfacing — the programmer enters a spin loop like:

       CLV
.here: BVC .here

The worst-case latency there (assuming no page jump) is three cycles — after two cycles the entire BVC has been read and the decision is made to branch, the overflow flag is set but just too late, an extra cycle is spent performing the branch and then two more rereading the BVC. That's substantially faster than even the fastest IRQ, which starts at 7 cycles.

The main example of usage I'm aware of is the C1540/1541 disk drive where overflow can be enabled to be set each time the flux transition shift register is full.

These disk drives were like the PET drives, and had their own on-board 6502 CPU.

So I thought I'd test Claude on the subject:

I asked Can you tell me what the Set Overflow pin is used for on a 6502 CPU?

and the reply was

The Set Overflow (SO) pin on the 6502 CPU is used to directly set the overflow (V) flag in the processor status register. This is a somewhat unique feature of the 6502 architecture.
When a negative edge (high-to-low transition) is detected on the SO pin, the overflow flag is set to 1. This provides an external hardware method to influence the processor status, which can be useful for various purposes:

1. It allows external hardware to signal arithmetic overflow conditions to the CPU
2. It can be used to implement software interrupts when combined with branch instructions that test the overflow flag (BVC/BVS)
3. In some systems, it's connected to timers or other peripherals to signal specific conditions

This pin gave hardware designers additional flexibility when integrating the 6502 into their systems. For example, in some early home computers and game consoles, the SO pin could be connected to peripherals that needed to signal certain conditions to the CPU.
The overflow flag itself is primarily used during signed arithmetic operations to indicate when a signed overflow has occurred (when the result of an operation is too large to fit in the available bits when interpreted as a signed number).

Then I replied: I don't understand how this could be used to implement software interrupts though, because it is an external logic input. How can one use this to implement a software interrupt?

to which I got the reply:

You're absolutely right, and I should have been more precise in my explanation. You've identified an important distinction that I didn't clarify properly.

The Set Overflow pin is indeed an external hardware input, not something that can be triggered directly by software running on the 6502. It cannot be used to implement true "software interrupts" in the traditional sense (where code running on the CPU triggers an interrupt).

What I should have said is that it can be used as part of a hardware-assisted software signalling mechanism. Here's a more accurate explanation:

1. External hardware can assert the SO pin, setting the V flag
2. The program running on the CPU can then use BVS (Branch on oVerflow Set) instructions to check if this flag was set
3. This creates a polling mechanism where software can respond to external events

Unlike true interrupts (like IRQ or NMI on the 6502), this doesn't automatically change the program counter or push state onto the stack. The program must explicitly check the V flag with conditional branches.

In modern terminology, this would be considered a form of polling rather than a true interrupt mechanism. The software must explicitly check the status rather than being automatically redirected to an interrupt handler.

Thank you for the correction and for giving me the opportunity to provide a more accurate explanation.

Thinking about it, one could use the SYNC output to identify an opcode fetch and watch the data bus for one of the illegal JAM opcodes then trigger an NMI with the Overflow flag set, and have the interrupt routine check the overflow flag in the ISR and vector through another table according to whatever is in, say, the X register. If you also implemented some paged RAM addressing you could extend this to allow user programs to jump into protected memory and execute in a kind of Ring0 privilege level. Whilst digging around I came across this: Writing an Operating System for the 6502 and another interesting post on someone's Multiprocessor idea based on Ben Eater's breadboard design: Multiprocessor 6502 schematic almost complete!.

 Should I carry on talking to Claude about this? Will he learn anything new?