6502.org • View topic - A taken branch delays interrupt handling by one instruction

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Hardware

All times are UTC

A taken branch delays interrupt handling by one instruction

Page 2 of 4

[ 49 posts ]

Go to page Previous 1, 2, 3, 4 Next

Previous topic | Next topic

Author

Message

BigEd

Post subject: Re: A taken branch delays interrupt handling by one instruct

Posted: Sat Sep 04, 2010 7:34 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

Hias
thanks for posting such a thorough investigation of this interesting observation. And welcome!

Dr Jefyll wrote:

I believe that the 65xx economizes on silicon by NOT providing specialized hardware to perform the interrupt sequence. Instead, the interrupt is actually an instruction.... Like other instructions, it has a unique op-code that's latched into the chip's Instruction Register when SYNC is high. On subsequent cycles the internal PLA pulls whatever strings and levers are required to get the job done. This approach avoids the cost of adding a complex sequencing mechanism solely to implement interrupts.

To add to your ideas, Jeff, I had another look at Beregnyei's giant schematic

Here's the logic which clears the IR - as you suspect, it uses SYNC as a qualifier:

(picture only shows one half of the IR but the other half is identical)

The signal D1x1 is doing all the work. It's also used to control the PC incrementer (although the circuit for that doesn't look quite right to me)

D1x1 is the output of this little collection:

and you see PLA output 83 is one of the inputs, also Clock2 which is one of the six Timing Control signals - the other important ones being IRQ with the I flag, and a composite signal labelling IRQ, NMI, Reset. (Also Rdy0 which is a combination of RnW and RDY and turns up everywhere)

Lo and behold, PLA output 83 detects the 8 branch instructions. So they are treated specially, and deliberately so. Although I still don't quite see why.

(That composite signal is certainly a function of NMI, and I see BRK detection nearby, but I don't see IRQ or RESET, so something isn't quite making sense there.)

Cheers
Ed

Top

Dr Jefyll

Post subject: Re: A taken branch delays interrupt handling by one instruct

Posted: Sun Sep 05, 2010 4:16 am

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3349
Location: Ontario, Canada

BigEd wrote:

To add to your ideas, Jeff, I had another look at Beregnyei's giant schematic
Here's the logic which clears the IR - as you suspect, it uses SYNC as a qualifier

Hi, Ed -- Glad to have your contribution. I had a feeling you might be following this! (Ed and I had a PM discussion about ABORT, which of course is another type of interrupt.)

BigEd wrote:

D1x1 is the output of this little collection:

I think "this little collection" is the Interrupt-Acceptance-Flip-Flop I suggested. Although the designers' dynamic logic techniques (using gate-capacitances to store bits) make me reluctant to unravel the flip-flop itself, I'm sure D1x1 is the "IAFF" output signal. Referring to the complete diagram and following D1x1 around I quickly found where it gets gated onto bit 4 of the data bus. This is exactly as anticipated, since, when the interrupt pushes the processor flags to the stack, it is the BRK bit, bit 4 in the flags byte, which indicates -- by being 0, actually-- that the BRK is of the hardware ("forced") variety.

Quote:

The signal D1x1 [is] used to control the PC incrementer

Again this agrees with expectations. Hardware BRK is a zero-byte instruction but software BRK is 2-byte. I expect D1x1 allows PC to be incremented (or not) in order to derive the appropriate return address.

I think the "interrupt as an instruction" theory is amply established. (BTW my insight owes a lot to page A-11, Table A. 5.4 of the MOS Hardware Manual, where they pretty much spill the beans if you're paying attention.) Understanding the interrupt as an instruction shows us its limitations -- why, for example, the Conditional Branch logic might need to take heed. More on that topic some other time, maybe. I don't expect that the '02, the 'C02 and the '816 deal with the matter in exactly the same fashion. And the '816's ABORT introduces yet another flavor! (along with NMI, IRQ, RST and software BRK). Finally:

Quote:

Lo and behold, PLA output 83 detects the 8 branch instructions. So they are treated specially, and deliberately so.

Yes, and 76 is another that activates for the 8 branch instructions. As for timing, my take is that 83 is high for all branch-instruction states except T3, and 76 for all except T1 -- do have that right? Not sure. Also pertinent are PLA outputs 105, 80 & 25 (BRK), 92 & 99 (BRK,RTI) and 40 (BRK,JSR abs) -- in case anyone has the patience to track them all down!

-- Jeff

Top

BigEd

Post subject: Re: A taken branch delays interrupt handling by one instruct

Posted: Sun Sep 05, 2010 9:48 am

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

Dr Jefyll wrote:

BigEd wrote:

D1x1 is the output of this little collection:

I think "this little collection" is the Interrupt-Acceptance-Flip-Flop I suggested.

Agreed - I hadn't quite spotted that this is a flop, I was only seeing significant input signals. It's a bit of a strain to make sense of this stuff.

Dr Jefyll wrote:

Quote:

Lo and behold, PLA output 83 detects the 8 branch instructions. So they are treated specially, and deliberately so.

I'm not sure - 83 and 76 are sensitive to 2 signals from Timing Control in that way but I'm not certain of the T states.

Timing Control looks like it has 5 bits of state(#). There's Clock1 as a signal related to Sync(*), and Clock2 is 1 cycle delayed version, subject to RDY.

And then there's a 4-bit shift register starting at SYNC and subject to RDY. The two Clock signals and the 4 shift register signals go into the PLA. The block diagram would have these signals as T0, T1X, T2, T3, T4, T5. (It has T1 as Sync but T1X to the PLA.) I think there's a subtlety here.

(#) Hmm, but the hardware ref manual mentions 7 states, T0 to T6, for instructions such as ABS,X and BRK.

(*) actually Sync0 which is perhaps an early version of Sync? Is this perhaps valid in the cycle before Sync??

Top

BigEd

Post subject:

Posted: Tue Sep 07, 2010 9:43 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

Now, if only we had something more accurate and interactive than the giant schematic (wonderfully useful and interesting though it is)

Top

BigEd

Post subject:

Posted: Fri Sep 10, 2010 6:24 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

Eureka! With a transistor-level simulation of the 6502 in hand, we can see exactly what's going on cycle by cycle. (Or even phase by phase.) Huge thanks to Greg James, Barry Silverman and Brian Silverman for their Visual6502 project (website under construction - see other thread) which provided the simulator and the netlist.

Here's a late interrupt into a taken branch, should be timed the same as the example above:

Code:

testNMI(28)
 cyc:10 cp1:1 cp2:0 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:0 clearIR:1 D1x1:1
 cyc:10 cp1:0 cp2:1 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:1 clearIR:0 D1x1:1
 cyc:11 cp1:1 cp2:0 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:1 clearIR:0 D1x1:1
 cyc:11 cp1:0 cp2:1 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:0 clearIR:1 D1x1:1
 cyc:12 cp1:1 cp2:0 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:12 cp1:0 cp2:1 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:13 cp1:1 cp2:0 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:0 clearIR:1 D1x1:1
 cyc:13 cp1:0 cp2:1 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:1 clearIR:0 D1x1:1
 cyc:14 cp1:1 cp2:0 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:1 clearIR:0 D1x1:1
 cyc:14 cp1:1 cp2:0 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:110111  fetch:1 clearIR:0 D1x1:1
 cyc:14 cp1:0 cp2:1 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:110111  fetch:0 clearIR:1 D1x1:1
 cyc:15 cp1:1 cp2:0 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:15 cp1:0 cp2:1 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:16 cp1:1 cp2:0 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:0  IR:b0 TCstate:111111  fetch:0 clearIR:1 D1x1:1
 cyc:16 cp1:0 cp2:1 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:0  IR:b0 TCstate:111111  fetch:1 clearIR:0 D1x1:1
 cyc:17 cp1:1 cp2:0 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:110111  fetch:1 clearIR:0 D1x1:1
 cyc:17 cp1:0 cp2:1 Add:2305 D:fe RnW:1  PC:2305 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:110111  fetch:0 clearIR:1 D1x1:0
 cyc:18 cp1:1 cp2:0 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:0  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:0
 cyc:18 cp1:1 cp2:0 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:0
 cyc:18 cp1:0 cp2:1 Add:2306 D:00 RnW:1  PC:2306 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:0
 cyc:19 cp1:1 cp2:0 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:0 clearIR:1 D1x1:0
 cyc:19 cp1:0 cp2:1 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:1 clearIR:1 D1x1:0
 cyc:20 cp1:1 cp2:0 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:0 NMI:1  IR:00 TCstate:110111  fetch:1 clearIR:1 D1x1:0
 cyc:20 cp1:0 cp2:1 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:0 NMI:1  IR:00 TCstate:110111  fetch:0 clearIR:1 D1x1:0
 cyc:21 cp1:1 cp2:0 Add:01fd D:b0 RnW:0  PC:2304 SP:fd  Sync:0 NMI:1  IR:00 TCstate:111011  fetch:0 clearIR:1 D1x1:0
 cyc:21 cp1:0 cp2:1 Add:01fd D:23 RnW:0  PC:2304 SP:fd  Sync:0 NMI:1  IR:00 TCstate:111011  fetch:0 clearIR:1 D1x1:0

Here's a trace of the simulator's test program:

Code:

 cyc:2 cp1:1 cp2:0 Add:0000 D:a9 RnW:1  PC:0000 SP:fd  Sync:1 NMI:1  IR:00 TCstate:011111  fetch:0 clearIR:1 D1x1:1
 cyc:2 cp1:0 cp2:1 Add:0000 D:a9 RnW:1  PC:0000 SP:fd  Sync:1 NMI:1  IR:00 TCstate:011111  fetch:1 clearIR:0 D1x1:1
 cyc:3 cp1:1 cp2:0 Add:0001 D:00 RnW:1  PC:0001 SP:fd  Sync:0 NMI:1  IR:a9 TCstate:100111  fetch:1 clearIR:0 D1x1:1
 cyc:3 cp1:0 cp2:1 Add:0001 D:00 RnW:1  PC:0001 SP:fd  Sync:0 NMI:1  IR:a9 TCstate:100111  fetch:0 clearIR:1 D1x1:1
 cyc:4 cp1:1 cp2:0 Add:0002 D:20 RnW:1  PC:0002 SP:fd  Sync:1 NMI:1  IR:a9 TCstate:011111  fetch:0 clearIR:1 D1x1:1
 cyc:4 cp1:0 cp2:1 Add:0002 D:20 RnW:1  PC:0002 SP:fd  Sync:1 NMI:1  IR:a9 TCstate:011111  fetch:1 clearIR:0 D1x1:1
 cyc:5 cp1:1 cp2:0 Add:0003 D:10 RnW:1  PC:0003 SP:fd  Sync:0 NMI:1  IR:20 TCstate:110111  fetch:1 clearIR:0 D1x1:1
 cyc:5 cp1:0 cp2:1 Add:0003 D:10 RnW:1  PC:0003 SP:fd  Sync:0 NMI:1  IR:20 TCstate:110111  fetch:0 clearIR:1 D1x1:1
 cyc:6 cp1:1 cp2:0 Add:01fd D:00 RnW:1  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:6 cp1:0 cp2:1 Add:01fd D:00 RnW:1  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:7 cp1:1 cp2:0 Add:01fd D:00 RnW:0  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:111101  fetch:0 clearIR:1 D1x1:1
 cyc:7 cp1:0 cp2:1 Add:01fd D:00 RnW:0  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:111101  fetch:0 clearIR:1 D1x1:1
 cyc:8 cp1:1 cp2:0 Add:01fc D:00 RnW:0  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:111110  fetch:0 clearIR:1 D1x1:1
 cyc:8 cp1:0 cp2:1 Add:01fc D:04 RnW:0  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:111110  fetch:0 clearIR:1 D1x1:1
 cyc:9 cp1:1 cp2:0 Add:0004 D:00 RnW:1  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:101111  fetch:0 clearIR:1 D1x1:1
 cyc:9 cp1:0 cp2:1 Add:0004 D:00 RnW:1  PC:0004 SP:10  Sync:0 NMI:1  IR:20 TCstate:101111  fetch:0 clearIR:1 D1x1:1

Now we know exactly what happens, we just need to figure out why! And we can trace any signal on the chip, so long as we can find it. (We can also add and remove transistors if that seems appealling. There are only 3510 transistors there - all the pullups are modelled separately.)

My current thinking is that the succession of Tstates for a normal instruction stream visits 101111 in the last cycle of an instruction, and this is when the interrupt handler kicks off. Taken branches never visit 101111 - they sort of interrupt themselves - and so they wouldn't be interruptible if it weren't for the special handling.

We can see that an interrupt acts differently by watching the Tstates as an interrupt is taken - we don't visit 011111

Code:

  cyc:7 cp1:1 cp2:0 Add:2306 D:b0 RnW:1  PC:2306 SP:fd  Sync:1 NMI:1  IR:4c TCstate:011111  fetch:0 clearIR:1 D1x1:1
  cyc:7 cp1:0 cp2:1 Add:2306 D:b0 RnW:1  PC:2306 SP:fd  Sync:1 NMI:1  IR:4c TCstate:011111  fetch:1 clearIR:0 D1x1:1
  cyc:8 cp1:1 cp2:0 Add:2307 D:01 RnW:1  PC:2307 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:1 clearIR:0 D1x1:1
  cyc:8 cp1:0 cp2:1 Add:2307 D:01 RnW:1  PC:2307 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:0 clearIR:1 D1x1:1
  cyc:9 cp1:1 cp2:0 Add:2308 D:00 RnW:1  PC:2308 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
  cyc:9 cp1:0 cp2:1 Add:2308 D:00 RnW:1  PC:2308 SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:10 cp1:1 cp2:0 Add:2309 D:a9 RnW:1  PC:2309 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:0 clearIR:1 D1x1:1
 cyc:10 cp1:0 cp2:1 Add:2309 D:a9 RnW:1  PC:2309 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:1 clearIR:0 D1x1:1
 cyc:11 cp1:1 cp2:0 Add:230a D:de RnW:1  PC:230a SP:fd  Sync:0 NMI:1  IR:a9 TCstate:100111  fetch:1 clearIR:0 D1x1:1
 cyc:11 cp1:0 cp2:1 Add:230a D:de RnW:1  PC:230a SP:fd  Sync:0 NMI:1  IR:a9 TCstate:100111  fetch:0 clearIR:1 D1x1:1

followed here by another which crosses a page boundary:

Code:

 cyc:12 cp1:1 cp2:0 Add:230b D:b0 RnW:1  PC:230b SP:fd  Sync:1 NMI:1  IR:a9 TCstate:011111  fetch:0 clearIR:1 D1x1:1
 cyc:12 cp1:0 cp2:1 Add:230b D:b0 RnW:1  PC:230b SP:fd  Sync:1 NMI:1  IR:a9 TCstate:011111  fetch:1 clearIR:0 D1x1:1
 cyc:13 cp1:1 cp2:0 Add:230c D:f2 RnW:1  PC:230c SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:1 clearIR:0 D1x1:1
 cyc:13 cp1:0 cp2:1 Add:230c D:f2 RnW:1  PC:230c SP:fd  Sync:0 NMI:1  IR:b0 TCstate:110111  fetch:0 clearIR:1 D1x1:1
 cyc:14 cp1:1 cp2:0 Add:230d D:00 RnW:1  PC:230d SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:14 cp1:0 cp2:1 Add:230d D:00 RnW:1  PC:230d SP:fd  Sync:0 NMI:1  IR:b0 TCstate:111011  fetch:0 clearIR:1 D1x1:1
 cyc:15 cp1:1 cp2:0 Add:23ff D:00 RnW:1  PC:23ff SP:fd  Sync:0 NMI:1  IR:b0 TCstate:101111  fetch:0 clearIR:1 D1x1:1
 cyc:15 cp1:0 cp2:1 Add:23ff D:00 RnW:1  PC:23ff SP:fd  Sync:0 NMI:1  IR:b0 TCstate:101111  fetch:0 clearIR:1 D1x1:1
 cyc:16 cp1:1 cp2:0 Add:22ff D:38 RnW:1  PC:22ff SP:fd  Sync:1 NMI:1  IR:b0 TCstate:011111  fetch:0 clearIR:1 D1x1:1
 cyc:16 cp1:0 cp2:1 Add:22ff D:38 RnW:1  PC:22ff SP:fd  Sync:1 NMI:1  IR:b0 TCstate:011111  fetch:1 clearIR:0 D1x1:1

in which case the branch does visit the final state 101111 and the next instruction does start with a 011111 as usual.

A branch may be a case a bit like an indexed write where the final instruction state must be reserved in case a page is crossed. In the case of a branch, the next instruction isn't known to have started until it's known that there's no page crossing. The following instruction after a taken branch doesn't have a normal first cycle. And so a taken branch doesn't have a 'final' state, and so it wouldn't be interruptible. Instead it begins the interrupt handler during T2, which means the NMI needs to enter the chip a bit earlier than the usual case in order to catch the window. We see that the other way around: the interrupt appears to have been deferred.

Hope this makes some degree of sense!

Cheers
Ed

Top

HiassofT

Post subject: Re: A taken branch delays interrupt handling by one instruct

Posted: Mon Sep 13, 2010 8:54 pm

Joined: Thu Sep 02, 2010 12:34 am
Posts: 36
Location: Salzburg, Austria

HiassofT wrote:

BigDumbDinosaur wrote:

After reading your analysis and looking at the logic graphs, I have to wonder if this characteristic was carried over the the 65C02 and 65816. As you say, it appears to be harmless, but does have some perceptible effect on interrupt latency.

I had another idea: I have an Atari 800 (which uses the original 6502) at my parent's home, and just remembered that I bought a 65(C?)02 some 20 years ago for a SBC I wanted to create (but never finished it). I'll be visiting my parents next weekend, so I can check if this really is a 2MHz 65C02 and if yes take it all home, put the 65C02 into the Atari and run some tests.

These test have to wait a little bit. I opened my Atari 800 and realized it was one of the (later) models which had a CPU board with Atari's "6502C Sally" CPU - the same as in my 800XL.

So I need to build an adapter board for my 800XL first...

But, good news is: a friend is sending me some other CPUs to test with, a Rockwell 65C02, a CMD 65SC02 and a 65816. My 2 MHz 65C02 seems to have gone missing during the years, but I pulled a Rockwell 65C02 4 MHz from another board I had completely forgotten about :-)

so long,

Hias

Top

HiassofT

Post subject:

Posted: Mon Sep 13, 2010 9:01 pm

Joined: Thu Sep 02, 2010 12:34 am
Posts: 36
Location: Salzburg, Austria

Hi Ed!

BigEd wrote:

Wow, this is really awesome!

Did you get a pre-release of their software? I checked visual6502.org but couldn't find anything except for the static pic yet.

Quote:

And so a taken branch doesn't have a 'final' state, and so it wouldn't be interruptible. Instead it begins the interrupt handler during T2, which means the NMI needs to enter the chip a bit earlier than the usual case in order to catch the window. We see that the other way around: the interrupt appears to have been deferred.

Hope this makes some degree of sense!

Thanks a lot for the tests and for your analysis! And, at least to me, this makes some sense :-)

so long,

Hias

Top

BigEd

Post subject:

Posted: Mon Sep 13, 2010 9:38 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

HiassofT wrote:

Did you get a pre-release of their software? I checked visual6502.org but couldn't find anything except for the static pic yet.

Yes, but I think it'll be released soon. (I haven't seen the python version yet.)

Quote:

Thanks a lot for the tests and for your analysis! And, at least to me, this makes some sense :-)

Great!

Top

Dr Jefyll

Post subject:

Posted: Tue Sep 14, 2010 2:46 pm

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3349
Location: Ontario, Canada

BigEd wrote:

Eureka! With a transistor-level simulation of the 6502 in hand, we can see exactly what's going on cycle by cycle. (Or even phase by phase.)

Code:

cyc:10 cp1:1 cp2:0 Add:2304 D:b0 RnW:1  PC:2304 SP:fd  Sync:1 NMI:1  IR:b0 TCstate:111111  fetch:0 clearIR:1 D1x1:1

Wow. This is exciting material, but a little tough to comb through. The first thing I did was to reformat the simulation output text (by copy-and-pasting into a text editor). It's much more readable when partially double-spaced; also the original Forum view may (depending on screen resolution) cause the browser to wrap each line, which is very unhelpful. But I'm still not at a point where I can share your speculations, Ed. I'm not disagreeing; I'm just in the dark still! A few questions, if you don't mind:

TCstate

fetch

clearIR

D1x1

Unfortunately I haven't had time to fully scrutinize what you posted. But I noticed there's a lot of activity on clearIR, yet the Instruction Register rarely clears. Puzzling -- to me, at least!

-- Jeff

Top

BigEd

Post subject:

Posted: Tue Sep 14, 2010 4:52 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

Hi Jeff
yes, the forum's line-wrapping is a bit of a hindrance.

yes, the three signals at the end are all from Balazs' schematic. I think clearIR has no effect unless fetch is active.

The 6 TCState lines are indeed the PLA 'timing' inputs - the last four are conventionally labelled T2-T5 I think, and the first two are sync-related. The first would conventionally be called T0 but doesn't precisely correspond to Sync because of the taken-branch effect. Even if it did correspond to Sync, I think T0 is a misnomer because the active instruction in the IR is still the previous one. The second signal is normally active in the cycle before Sync - not sure what that should be called!

Notice in the traces that these signals aren't quite one-cold: sometimes we visit 111111 and sometimes 100111.

I completely agree that this is going to take a bit of digesting!

It would be good to run a set of LDA and STA in all addressing modes, and with page crossings where applicable. But even then, interactions with the previous instruction could be interesting.

(I don't think I've yet traced an indirect or indexed addressing mode - there's no disassembly so I'm not sure.)

It would be interesting to see if this specific chip - a revision D - has the famous ROR bug.

Cheers
Ed

Top

BigEd

Post subject:

Posted: Wed Sep 15, 2010 5:07 am

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

HiassofT wrote:

Hi Ed!

BigEd wrote:

... With a transistor-level simulation of the 6502 in hand, we can see exactly what's going on cycle by cycle. (Or even phase by phase.) Huge thanks to Greg James, Barry Silverman and Brian Silverman for their Visual6502 project...

Wow, this is really awesome!
...
I checked visual6502.org but couldn't find anything except for the static pic yet.

Hi Hias!
Greg has just published the visual6502 website - the simulator, presentation and some nice 6502 images are all available now.

I've updated the Visualizing the 6502 thread accordingly (and Greg has made the same announcement over there)

Cheers
Ed

Top

visual6502

Post subject:

Posted: Wed Sep 15, 2010 1:54 pm

Joined: Mon Sep 13, 2010 8:27 pm
Posts: 3
Location: San Francisco, CA

Hi everyone!
Enjoy the gate-level sim! We're all really excited to see what it leads to and especially how it compares to the real thing. We've done a lot of testing, but only against what we *think* the chip ought to do.
Hias - discovering your waves and that you've got such a setup was a real treat! It'd be pretty amazing for us to work together to track different behavior across different revs of the chip.
Our work is based on a 6502D 1683 stamped 'MOS' in a plain font, not the fancy MOS logo stamp. Over the next days, I'll try to link together more info on our site to make things clearer and easier.
Great thanks are due to Ed for a ton of help these last few days getting our site off the ground and starting to enhance the JavaScript version. Thanks BigEd!
Exciting times are in store!
-Greg, on behalf of the visual6502.org team

Top

HiassofT

Post subject:

Posted: Wed Sep 15, 2010 6:16 pm

Joined: Thu Sep 02, 2010 12:34 am
Posts: 36
Location: Salzburg, Austria

Hi Greg (and of course also Brian and Barry)!

visual6502 wrote:

Enjoy the gate-level sim! We're all really excited to see what it leads to and especially how it compares to the real thing. We've done a lot of testing, but only against what we *think* the chip ought to do.

Wow, this is absolutely wonderful! I just had a quick look at it, Firefox 3.5 on Debian Lenny (64bit) worked great (as a side note: Firefox 3.0 doesn't support "children", changing "table.children[r].children[c+1]" to "table.childNodes[r].childNodes[c+1]" at the end of memtable.js seems to work fine - although the performance with FF 3.5 seems to be a lot better).

Thanks a lot for your really amazing work!

Quote:

Hias - discovering your waves and that you've got such a setup was a real treat! It'd be pretty amazing for us to work together to track different behavior across different revs of the chip.

Sure, I'd be glad to help you! Just drop me a line what you need and I'll see what I can do.

So far I only have Atari "6502C Sally" CPUs running here but as soon as I have built an adapter board I should be able to test other 6502s in my Atari, too.

BTW: If you get to doing POKEY I might have some interesting testcases for the serial I/O part (the real fun starts at posting #22):
http://www.atariage.com/forums/topic/168218-pokey-serial-and-irq-timing-details/

Last week I had a quick look at GTIA, too (checked the timing of CSYNC and LUMA outputs), maybe I can help there too :-)

so long,

Hias

PS: this is all really, really exciting and interesting!

Top

debounce

Post subject:

Posted: Sat Nov 27, 2010 7:16 pm

Joined: Tue Nov 23, 2004 2:11 pm
Posts: 25
Location: London, UK

What a fascinating thread! I had to re-check my HD floppy disc service routines for worst case timing, thankfully they're ok.

However I'm not sure of some of the analyses suggested: as this screenshot by Hias proves, the 6502 is perfectly able to follow T2 of a branch with an interrupt sequence, the interrupt signal just won't have started on that same T2. So the problem isn't that it's impossible to determine that T2 is the last cycle until it's finished. The other screenshots show that the PC not being final isn't the issue either, as the CPU either starts the sequence or continues to T3 of the branch as necessary.

I'm guessing, if the behaviour is deliberate, that it was done to make the branch and its target instruction an atomic pair, though no practical applications come to mind.

Top

RichTW

Post subject:

Posted: Tue Sep 20, 2011 9:58 pm

Joined: Wed Oct 06, 2010 9:05 am
Posts: 95
Location: Palma, Spain

Did anyone ever figure out any plausible reason why the 6502 was designed with this behaviour? If it was, as it appears, a very deliberate design decision, I'm still curious to know why it was deemed necessary.

Top

Page 2 of 4

[ 49 posts ]

Go to page Previous 1, 2, 3, 4 Next

Board index » 6502.org Users Forum » Hardware

All times are UTC

Who is online

Users browsing this forum: No registered users and 36 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum