A novel 6502 Protocol Decoder for Sigrok

[hoglet]

BigEd wrote:

Ah, yes, very good point: it does collapse down the number of things to handle. (I think BIT is the only one. It's also true that TXS doesn't set the flags, unlike the other Txx operations.)

Interesting... I didn't know that TXS doesn't set the flags.

I've had a quick go at this, and it's looking promising.

Here's a snapshot of the current code:
https://github.com/hoglet67/libsigrokde ... /tables.py

It's currently outputting all state at the end of each instruction.

Here's an example:

Code: Select all

 ????: xxx           A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=?
 ????: BBR7 7F,pc-1  A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=?
 ????: BRK #00       A=?? X=?? Y=?? SP=?? N=? V=? D=0 I=1 Z=? C=?
 D9CD: LDA #40       A=40 X=?? Y=?? SP=?? N=0 V=? D=0 I=1 Z=0 C=?
 D9CF: STA 0D00      A=40 X=?? Y=?? SP=?? N=0 V=? D=0 I=1 Z=0 C=?
 D9D2: SEI           A=40 X=?? Y=?? SP=?? N=0 V=? D=0 I=1 Z=0 C=?
 D9D3: CLD           A=40 X=?? Y=?? SP=?? N=0 V=? D=0 I=1 Z=0 C=?
 D9D4: LDX #FF       A=40 X=FF Y=?? SP=?? N=1 V=? D=0 I=1 Z=0 C=?
 D9D6: TXS           A=40 X=FF Y=?? SP=FF N=1 V=? D=0 I=1 Z=0 C=?
 D9D7: LDA FE4E      A=80 X=FF Y=?? SP=FF N=1 V=? D=0 I=1 Z=0 C=?
 D9DA: ASL A         A=00 X=FF Y=?? SP=FF N=0 V=? D=0 I=1 Z=1 C=1
 D9DB: PHA           A=00 X=FF Y=?? SP=FE N=0 V=? D=0 I=1 Z=1 C=1
 D9DC: BEQ D9E7      A=00 X=FF Y=?? SP=FE N=0 V=? D=0 I=1 Z=1 C=1
 D9E7: LDX #04       A=00 X=04 Y=?? SP=FE N=0 V=? D=0 I=1 Z=0 C=1
 D9E9: STX 01        A=00 X=04 Y=?? SP=FE N=0 V=? D=0 I=1 Z=0 C=1
 D9EB: STA 00        A=00 X=04 Y=?? SP=FE N=0 V=? D=0 I=1 Z=0 C=1
 D9ED: TAY           A=00 X=04 Y=00 SP=FE N=0 V=? D=0 I=1 Z=1 C=1
 D9EE: STA (00),Y    A=00 X=04 Y=00 SP=FE N=0 V=? D=0 I=1 Z=1 C=1
 D9F0: CMP 01        A=00 X=04 Y=00 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=00 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=01 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F5: BNE D9EE      A=00 X=04 Y=01 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9EE: STA (00),Y    A=00 X=04 Y=01 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F0: CMP 01        A=00 X=04 Y=01 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=01 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=02 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F5: BNE D9EE      A=00 X=04 Y=02 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9EE: STA (00),Y    A=00 X=04 Y=02 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F0: CMP 01        A=00 X=04 Y=02 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=02 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=03 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F5: BNE D9EE      A=00 X=04 Y=03 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9EE: STA (00),Y    A=00 X=04 Y=03 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F0: CMP 01        A=00 X=04 Y=03 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=03 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=04 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F5: BNE D9EE      A=00 X=04 Y=04 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9EE: STA (00),Y    A=00 X=04 Y=04 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F0: CMP 01        A=00 X=04 Y=04 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=04 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=05 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F5: BNE D9EE      A=00 X=04 Y=05 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9EE: STA (00),Y    A=00 X=04 Y=05 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F0: CMP 01        A=00 X=04 Y=05 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=05 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=06 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F5: BNE D9EE      A=00 X=04 Y=06 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9EE: STA (00),Y    A=00 X=04 Y=06 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
 D9F0: CMP 01        A=00 X=04 Y=06 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F2: BEQ D9FD      A=00 X=04 Y=06 SP=FE N=1 V=? D=0 I=1 Z=0 C=0
 D9F4: INY           A=00 X=04 Y=07 SP=FE N=0 V=? D=0 I=1 Z=0 C=0

And the complete trace:

beeb_trace.zip

(814.83 KiB) Downloaded 210 times

I'm sure there are lots of bugs. The don't care handling is sufficiently special that I didn't bother trying to leverage any existing emulator code. If you do spot anything that looks incorrect, please let me know.

I think it would be possible to add sanity checking like we did with the PC. For example, on STA the current value of A is visible on the bus, and can be checked against the predicted value.

Here's the current TODO list:

Code: Select all

# Emulation TODO list
# - Seperate 6502/65C02 modes
# - Decimal mode
# - Overflow flag in ADC/SBC
# - Reduce uncertainty where possible (e.g. where just one of A and C is undefined)
# - implement RTI
# - check push/pull behaviour
# - sanity checking (e.g. on STA, STX, STY, PHA, PHX, PHY, PHP, etc)

Dave

[BigEd]

Very nice! I had to check, but of course it's true, that CMP is unlike SBC in not affecting V. Consistency checks are a good idea - branches can tell you about flag values too.

What's the clever trick you have in mind behind this:

Quote:

# - Reduce uncertainty where possible (e.g. where just one of A and C is undefined)

?

[hoglet]

BigEd wrote:

What's the clever trick you have in mind behind this:

Quote:

# - Reduce uncertainty where possible (e.g. where just one of A and C is undefined)

?

It may not be worth the added complexity, but in come cases we are being overly pessimistic with don't cares and flags in instructions that use C and A. Consider:

Code: Select all

    def op_ROLA(self, operand):
        if self.A >= 0 and self.C >= 0:
            tmp = (self.A << 1) + self.C
            self.C = (tmp >> 8) & 1
            self.A = tmp & 255
            self.set_NZ(self.A)
        else:
            self.A = -1
            self.set_NZC_unknown()

If A is known but C is unknown, then we end up setting the flags to unknown. Whereas it is still the case that:
C = A(7)
N = A(6)
Z = 0 if A(6:0) > 0, -1 otherwise

i.e. most of the time the flags don't actually depend on C.

Is it worth it? I would say probably not.

Dave

[BigEd]

Ah, good example!

[hoglet]

BigEd wrote:

Consistency checks are a good idea - branches can tell you about flag values too.

I've now implemented consistency checking on the following instructions:
- STA (check A)
- STX (check X)
- STY (check Y)
- PHA (check A)
- PHX (check X)
- PHY (check Y)
- PHP (check all flags)
- BRK (check all flags)
- interrupt (check all flags)
- BPL/BMI (check N)
- BVC/BVS (check V)
- BNE/BEQ (check Z)
- BCC/BCS (check C)

Can you think of any other places where the value of an internal register is written out on the data bus during an instruction?

Doing this has helped identify a few silly mistakes which are now fixed.

I've got quite a thorough test cycle now, running the protocol decoder over:
- 1 second of the Beeb booting sampled @ 12MHz (x2 independent captures)
- 1 second of the Beeb booting sampled @ 8MHz (x2 independent captures)
- 1 second of the Master booting sampled @ 12MHz (x2 independent captures)
- 1 second of the Master 128 booting sampled @ 8MHz (x2 independent captures)

On the beeb (in all 4 captures), I'm seeing just one consistency check failure, trace is below.

This is actually very peculiar. It's the DFS code testing whether a particular ROM (Basic II in this case) is writable. It's read/inverting/writing/testing the byte at &8008 which is 01. The consistency check failure is when the STA tried to store &FE, what is actually seen in the write cycle on the bus is &01. All I can think of is there is a bus conflict happening here (maybe a bug in my modern sideways ROM board).

Here's the actual waveform of that STA:

And here's the preceding LDA:

Just to double check, I set a breakpoint use ICE-T65 and verified that A=&FE at this point (so it's just the store that is seemingly incorrect).

The other interesting thing is that sampling the Master at 8MHz is not 100% reliable, and you see good number of consistency check errors.

All these changes are in git:
https://github.com/hoglet67/libsigrokde ... 6502_state

Dave

Code: Select all

 DC0B: LDX F4        A=80 X=03 Y=0F SP=F1 N=0 V=0 D=0 I=1 Z=0 C=1
 DC0D: STY F4        A=80 X=03 Y=0F SP=F1 N=0 V=0 D=0 I=1 Z=0 C=1
 DC0F: STY FE30      A=80 X=03 Y=0F SP=F1 N=0 V=0 D=0 I=1 Z=0 C=1
 DC12: LDY #00       A=80 X=03 Y=00 SP=F1 N=0 V=0 D=0 I=1 Z=1 C=1
 DC14: LDA (F6),Y    A=01 X=03 Y=00 SP=F1 N=0 V=0 D=0 I=1 Z=0 C=1
 DC16: STX F4        A=01 X=03 Y=00 SP=F1 N=0 V=0 D=0 I=1 Z=0 C=1
 DC18: STX FE30      A=01 X=03 Y=00 SP=F1 N=0 V=0 D=0 I=1 Z=0 C=1
 DC1B: RTS           A=01 X=03 Y=00 SP=F3 N=0 V=0 D=0 I=1 Z=0 C=1
 B8AE: STA BD        A=01 X=03 Y=00 SP=F3 N=0 V=0 D=0 I=1 Z=0 C=1
 B8B0: PLA           A=0F X=03 Y=00 SP=F4 N=0 V=0 D=0 I=1 Z=0 C=1
 B8B1: PHA           A=0F X=03 Y=00 SP=F3 N=0 V=0 D=0 I=1 Z=0 C=1
 B8B2: TAY           A=0F X=03 Y=0F SP=F3 N=0 V=0 D=0 I=1 Z=0 C=1
 B8B3: LDA BD        A=01 X=03 Y=0F SP=F3 N=0 V=0 D=0 I=1 Z=0 C=1
 B8B5: EOR #FF       A=FE X=03 Y=0F SP=F3 N=1 V=0 D=0 I=1 Z=0 C=1
 B8B7: JSR B745      A=FE X=03 Y=0F SP=F1 N=1 V=0 D=0 I=1 Z=0 C=1
 B745: STA BF        A=FE X=03 Y=0F SP=F1 N=1 V=0 D=0 I=1 Z=0 C=1
...
irrelevant stuff deleted
...
 B765: LDA BF        A=FE X=03 Y=0F SP=EF N=1 V=0 D=0 I=1 Z=0 C=1
 B767: JSR B771      A=FE X=03 Y=0F SP=ED N=1 V=0 D=0 I=1 Z=0 C=1
 B771: JMP (00B0)    A=FE X=03 Y=0F SP=ED N=1 V=0 D=0 I=1 Z=0 C=1
 2000: STY F4        A=FE X=03 Y=0F SP=ED N=1 V=0 D=0 I=1 Z=0 C=1
 2002: STY FE30      A=FE X=03 Y=0F SP=ED N=1 V=0 D=0 I=1 Z=0 C=1
 2005: LDY #00       A=FE X=03 Y=00 SP=ED N=0 V=0 D=0 I=1 Z=1 C=1
 2007: STA (BA),Y    A=01 X=03 Y=00 SP=ED N=0 V=0 D=0 I=1 Z=1 C=1 prediction failed

[BigEd]

Hmm - interesting! If you try to write to a ROM, is the ROM also driving the bus?

[hoglet]

BigEd wrote:

Hmm - interesting! If you try to write to a ROM, is the ROM also driving the bus?

I've just had a quick look at the Model B schematic and I don't see R/W being used in the generation of the ROM nOE or nCS signals. Oops....

[BigEd]

Well, it's too late to change it now...!

[hoglet]

Dominic (dp11 on stardot, and one of our PiTubeDirect co-conspirators) has suggested it would be advantageous for the connection sync to be optional. That would, for example, allow the decoder to connect to the Tube connector on a BBC model B, which is much easier to connect to, as it doesn't require a 40-pin DIP IC test clip.

The Tube has the following signals:
- Phi2
- RnW
- nRST
- nIRQ
- nTUBE
- D[7:0]
- A[6:0]

Initially I thought this would be quite easy - after all, disassemblers soon sync onto a 6502 instruction stream.

But on reflection, it's a little more difficult because we are talking about bus cycles, not opcodes in memory. Some of the 6502 addressing modes have a variable number of bus cycles when page crossing is involved, specifically:
- absolute, X
- absolute, Y
- (indirect zp),Y
- branches

So somehow we have to be able to predict these extra cycles caused by page crossings.

This might just be possible, because once in sync we are able to track the values of the registers and flags, and we can observe the address in the above cases on the data bus.

But I'm wondering if there is an easier way?

We do have enough spare inputs on a 16-bit wide logic analyzer to monitor A[5:0].

[dp11]

If we take a simple case to start with.

From reset we can track the address bus and X and Y so we can predict when extra cycles are added for :

- absolute, X
- absolute, Y
- (indirect zp),Y
- branches

So the difficult case is from starting at a random position in a data stream. Once we have locked on to the address bus and have X and Y it should be easy

[BigEd]

Those extra cycles have characteristic traffic on the data bus, I think. Which is relatively unlikely to be the same value as the next opcode fetch. So usually it will be possible to guess whether the extra cycle is there. It feels to me you'd ideally have some short list of hypotheses and choose the most likely one. And maybe sometimes need to backtrack. But this is a bit beyond my programming experience.

[Dr Jefyll]

Hi, guys, and welcome, Dominic. I like Ed's idea of a short list of hypotheses. Here's my (half-baked) notion of how that'd work.

Starting at a random position in a data stream we know nothing... except that no instruction exceeds 7 cycles, and therefore a Sync cycle is guaranteed to appear within that amount of time or less. That means as many as 7 hypotheses might conceivably come under consideration simultaneously.

So, when we capture the first frame of data (the address, data & control bits Dave listed) we launch a hypothesis that this cycle (call it Cycle A) is an opcode fetch. This becomes a thread (so to speak) that persists. On all subsequent cycles our software attempts to DIS-prove the notion that Cycle A was an opcode fetch. If it does get disproven then the thread dies; otherwise it continues to exist (albeit in limbo, as it hasn't been proven, either). On the next cycle we capture another frame of data and launch a hypothesis that this cycle is an opcode fetch. We also examine all other surviving threads/hypotheses and attempt to disprove them, based on the new data just input.

And so it goes. It'll initially be the case that several hypotheses are viable -- and that'll be the best we can do until more data arrives. But with luck we'll eventually have only one surviving hypothesis, and of course that's the goal.

Assuming I haven't missed anything, the challenge reduces to finding all the ways that a hypothesis can be disproven. For example, 65xx behavior dictates that if indexing causes a page crossing then the extra cycle will re-use the previous cycle's address except with $100 added (the high byte is incremented). We only have access to A[6:0], but if any of those are seen to change then whatever just happened wasn't a page crossing, and any hypothesis expecting a page crossing on that cycle has been disproven. That's just one example. Hopefully we'll find a LOT of ways to disprove hypotheses.

So, yes, I'm suggesting an exhaustive simulation of all the hypotheses -- which is hardly impossible, but it's something you'd want to plan carefully before you start. As an aside, performance needn't be badly impacted overall since most of the simulations will soon be deleted when their hypotheses are disproven.

Regarding interrupts, that's an aspect that launches an extra hypothesis for every cycle that might be a sync cycle. Luckily these extra hypotheses will tend to be short-lived. As I mentioned in my previous post, the address bus will NOT increment on the 2nd cycle of interrupt recognition; thus if address line A0 (or any other address line) is seen to change, or if the byte on the data bus changes, then it kills the idea that we're in the 2nd cycle of interrupt recognition.

Anyone see a flaw with the details I've laid out? Or maybe the whole approach can be replaced with something better. Anyway, I've said my bit so I'll sign off for now

-- Jeff

ETA: An indexed data fetch might or might not have a page crossing. And a conditional branch has three possible outcomes (no branch, branch, and branch with page crossing). So, should these opcodes launch more than one hypothesis? That's the most logical solution. But it pushes up the maximum number of hypotheses that might simultaneously in flight. Maybe that's acceptable.

[BigEd]

That makes sense to me! It gets no worse than 100 hypotheses in flight and that's a relatively short list for a program to chew on. And perhaps usually no more than half a dozen. (Made up numbers.)

[dp11]

Obviously with more information the quicker false threads can be eliminated

Let's take some extremes

1) databus, clock and rnw : I think very soon it will be apparent if the real 6502 and the LA model disagree over the state of rnw.

2) databus, clock and A0: again I suspect it won't be long before a disagreement is detected.

I'm sure you could craft code that would take a long time to lock on to the sequence but in a typical program I'm guessing it would be be very quick.

So I think 10bits of LA is all that is needed for a sensible, giving spare bits for capturing other signals.

Disassemblers lock very quickly with effectively just the databus so maybe just the databus is needed.

I do think you need to know what is at the NMI and IRQ vectors to tell the difference.

[hoglet]

Two new things to report on the 6502 Protocol Decoder...

First, I've re-written this in C, because I was getting frustrated at waiting minutes for the python/sigrok version to run. The C version is ~200x faster, and I'm also much faster at working in C than Python! The code is in it's own github repository now:
https://github.com/hoglet67/6502Decoder

Second, I've started work on sync-less decoding.

I've refactored the code to seperate the three main processing stages:
- A: merging multiple samples into a single bus cycle (i.e. looking for falling edge of Phi2)
- B: merging multiple bus cycles into an single instruction
- C: disassembling the instruction and updating the 6502 register/flag state

It's stage B that needs to change radically if sync is missing, you can see the current code here:
https://github.com/hoglet67/6502Decoder ... ain.c#L300

Without sync you need to:
- lookup the minimum number of cycles for each instruction
- predict taken branches (+1 cycle)
- predict page crossings (+1 cycle)

You also need a 3 cycle look-ahead to reliably detect interrupts.

I've tried to keep things simple, i.e. I've not yet persued the multiple hypothesis idea. So it can produce incorrect results until it has locked on to the instructuon stream:

Code: Select all

$ dd if=12MHz_beeb/test2.bin bs=1000 skip=20000 | decode6502 -s --sync= | head -20
 ????: CPX 08        A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=?
 ????: ???           A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=?
 ????: SEI           A=?? X=?? Y=?? SP=?? N=? V=? D=? I=1 Z=? C=?
 ????: LDA 02D8,X    A=E0 X=?? Y=?? SP=?? N=1 V=? D=? I=1 Z=0 C=?
 ????: CMP 02E1,X    A=E0 X=?? Y=?? SP=?? N=0 V=? D=? I=1 Z=1 C=1
 ????: BEQ pc-114    A=E0 X=?? Y=?? SP=?? N=0 V=? D=? I=1 Z=1 C=1
 ????: PLP           A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 ????: SEC           A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 ????: RTS           A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 E53C: BCS E593      A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 E593: RTS           A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEF0: BCC DF03      A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEF2: BIT E6        A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEF4: BVC DEE6      A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEE6: BIT FF        A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEE8: BMI DF00      A=E0 X=?? Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEEA: LDX 0241      A=E0 X=00 Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 DEED: JSR E577      A=E0 X=00 Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 E577: BIT 025F      A=E0 X=00 Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1
 E57A: BPL E581      A=E0 X=00 Y=?? SP=?? N=0 V=0 D=0 I=0 Z=1 C=1

I'm fairly happy with that.

Here's the full help for the 6502decoder command:

Code: Select all

$ decode6502 --help
Usage: decode6502 [OPTION...] [FILENAME]

Decoder for 6502/65C02 logic analyzer capture files.

FILENAME must be a binary capture file with 16 bit samples.

If FILENAME is omitted, stdin is read instead.

The default bit assignments for the input signals is:
 - data: bit  0 (assumes 8 consecutive bits)
 -  rnw: bit  8
 - sync: bit  9
 -  rdy: bit 10
 - phi2: bit 11

To specify that an input is unconnected, include the option with an empty
BITNUM. e.g. --sync=

If phi2 is not connected the capture file should contain one sample per
falling edge of phi2.

If rdy is not connected a value of '1' is assumed.

If sync is not connected a heuristic based decoder is used. This works well,
but can take several instructions to lock onto the instruction stream.
Use of sync, is preferred.

  -c, --c02                  Enable 65C02 mode.
      --data=BITNUM          The start bit number for data
  -d, --debug=LEVEL          Sets debug level (0 1 or 2)
      --phi2[=BITNUM]        The bit number for phi2, blank if unconnected
      --rdy[=BITNUM]         The bit number for rdy, blank if unconnected
      --rnw=BITNUM           The bit number for rnw
      --sync[=BITNUM]        The bit number for sync, blank if unconnected
  -s, --state                Show register/flag state.
  -u, --undocumented         Enable undocumented 6502 opcodes (currently
                             incomplete)
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Dave