NMOS 6502 Reset bug

[BigEd]

Jeff
this is an interesting thread, and your hypothesis of a bug in the stack-write suppression sounds to me the most promising one. Unfortunately that hypothesis doesn't fly for the Nintendo.

I'm wondering what other evidence we could dig up.

The very first 6502-based computer design seems to have been the TIM, by MOS themselves. A slightly later manual by Rockwell presents an example system design which only has a debouncer for reset.

6502.org wrote:

Image no longer available: http://img155.imageshack.us/img155/9822/reset3.png

It's possible that example isn't representative of the original TIM. You've already confirmed that the KIM doesn't apply a time constraint. We know that at least the TIM shipped with parts with the ROR bug, which means revision C silicon. So if there was a bug which got fixed, and which was known, the TIM might be expected to deal with it.

Quite a few unknowns in there!

Cheers
Ed

The Jolt - not much room for RST conditioning:

6502.org wrote:

Image no longer available: http://img225.imageshack.us/img225/7268/jolt.th.png

[Dr Jefyll]

Thank you, all. I suppose I should make it clear that, like Garth, I'm a strong advocate of CMOS 6502s. The new chips are superior in almost every way, and NMOS has no place in new designs. Second, I apologize if the topic of the NMOS RST bug seems irrelevant or uninteresting to anyone. I admit my own interest is a kind of perverse curiosity. The reported heating effect instantly struck me as mysterious from the first moment I heard of it, and, having come this far, I hate to leave the matter half-solved. Unravelling the puzzle will also teach us something about the industry.

BigEd, thank you for collecting together the references from previous posts, and also for your insight into the workings of NMOS internals. You narrowed the focus when you confirmed, "The only strong pullups on the chip which could cause contention are the ones which drive the databus pins." You went on to say:

Quote:

It's not impossible that the databus could be driven by the 6502 even during a read cycle, if there were a logic bug on the chip - and such a bug would need fixing!

and, in your latest post

Quote:

your hypothesis of a bug in the stack-write suppression sounds to me the most promising one. Unfortunately that hypothesis doesn't fly for the Nintendo.

Ok, now I'm having trouble; can you clarify why you feel the theory doesn't fly? You said "such a bug would need fixing," so do you feel it's implausible that MOS would release a chip exhibiting databus contention? I agree that'd usually be a thoroughly intolerable error! But this is not a usual case, for several reasons. For starters, corrupted transfers are perfectly acceptable (!), because the bus cycles in question carry data which is "Don't Care." Are we on the same page? I seem to have missed something.

If the contention occurs as I suspect, the opposing forces will be the 6502 databus buffers versus the buffers returning data from memory in page $01 (stack). Both sets of buffers will experience overheating, to some extent sharing and lessening the destructive effect. Notably, an exception would be ioncannon's experiment. In his case the databus was hardwired highs & lows, and the power dissipated in the 6502 buffers would skyrocket!! I'm not surprised he observed heating; the conditions were ideal! On the other hand, if he were to remove all connections to the databus (or assert his highs & lows using 10K resistors, say), would the chip stay cool? I think it would! (I'd do the experiment myself, except all my 6502s are CMOS!)

-- Jeff

[BigEd]

Jeff,

Quote:

can you clarify why you feel the theory doesn't fly

Ah, yes, your clarity has shown me to be confused. I was concentrating (at one point) on on-chip contention, which to be significant would have to be the databus drivers. In the case of the Nintendo's 2A03 chip, the 6502's databus drivers are reduced to remnants which drive an internal bus, eventually driving some logic which in turn drives the real databus drivers. It seemed very unlikely to me that any logic error which allowed the 6502 to have internal contention would cause the 2A03 to do the same.

But you rightly point out that for external contention, all we need is for RnW to signal a read but for the databus to be driven as if for a write. If the 6502 had such a problem, the 2A03 might have inherited it or replicated it.

Looking at the revD in visual6502, I notice that when reset is held asserted, the machine quickly converges to a fixed control state (T0+T1). In the simulation, the databus and address bus are constant, or alternate between two values on alternate clocks, depending on the instruction interrupted. As it happens, the state machine doesn't visit the stack-push states. Hmm.

Quote:

You said "such a bug would need fixing," so do you feel it's implausible that MOS would release a chip exhibiting databus contention?

Yes, that was my reaction. On reflection: if we're thinking of a broken read cycle, then no data will be corrupted, no I/O device erroneously accessed, so any problem would be device damage of some sort. Perhaps it is possible that this would be a bug not worth fixing - my reaction was hasty - but this is not really my area of expertise.

I like your idea of rerunning ioncannon's experiment without drivers, or with high-impedance drivers.

As it happens, the visual6502 project community now has sight of revision C schematics - earlier this week Donald Hanson kindly made available(*) scans of blueprints he got from MOS back in 1979. I'm sure we'll write up any interesting finds that crop up in comparing this revision C with the revision D that's represented in visual6502. As revision C has the ROR bug, and D doesn't, and one of the blueprints is dated Nov 74, and our example D revision dates from 1983, I believe there was only one bug-fix revision that saw the light of day. (I'm assuming that our revD is in the same series as the original revC.)

It may be that logic fixes will be unearthed by the comparison, in due course.

Cheers
Ed
(*) sorry, not for redistribution.

[Dr Jefyll]

BigEd wrote:

In the case of the Nintendo's 2A03 chip, the 6502's databus drivers are reduced to remnants which drive an internal bus, eventually driving some logic which in turn drives the real databus drivers.

I knew I was missing something! Thanks.

Quote:

for external contention, all we need is for RnW to signal a read but for the databus to be driven as if for a write. If the 6502 had such a problem, the 2A03 might have inherited it or replicated it.

It does certainly seem possible. I need to think about this more.

Quote:

Looking at the revD in visual6502, I notice that when reset is held asserted, the machine quickly converges to a fixed control state (T0+T1). In the simulation, the databus and address bus are constant, or alternate between two values on alternate clocks, depending on the instruction interrupted. As it happens, the state machine doesn't visit the stack-push states. Hmm.

Uh-oh! This does NOT fit in with what I predicted! And yet, if it isn't bus contention that causes the heating of the chip, then what is the cause?

Hmmm, indeed. If I can get my hands on a 2A03 (or other suitable guinea pig) maybe I'll do a followup experiment.

In the simulation, where do the data bus and address bus end up -- at the interrupted instruction? Is it fairly easy to verify whether RnW and the bus buffers are both set for a read?

-- Jeff

[BigEd]

Hi Jeff
A simulation like this shows the machine sitting in the BRK instruction:

Code: Select all

cycle  res  ab    db  rw  Fetch    Execute  State  pc    ir
0      1    0000  a9  1   LDA #    BRK      T1     0000  00
0      1    0000  a9  1   LDA #    BRK      T1     0000  00
1      1    0001  00  1            LDA #    T0+T2  0001  a9
1      1    0001  00  1            LDA #    T0+T2  0001  a9
2      1    0002  20  1   JSR Abs  LDA #    T1     0002  a9
2      1    0002  20  1   JSR Abs  LDA #    T1     0002  a9
3      1    0003  10  1            JSR Abs  T2     0003  20
3      1    0003  10  1            JSR Abs  T2     0003  20
4      1    01fd  00  1            JSR Abs  T3     0004  20
4      1    01fd  00  1            JSR Abs  T3     0004  20
5      1    01fd  00  0            JSR Abs  T4     0004  20
5      1    01fd  00  0            JSR Abs  T4     0004  20
6      1    01fc  00  0            JSR Abs  T5     0004  20
6      1    01fc  04  0            JSR Abs  T5     0004  20
7      1    0004  00  1            JSR Abs  T0     0004  20
7      0    0004  00  1            JSR Abs  T0     0004  20
8      0    0010  e8  1   INX      JSR Abs  T1     0010  20
8      0    0010  e8  1   INX      JSR Abs  T1     0010  20
9      0    0011  88  1            BRK      T0     0011  00
9      0    0011  88  1            BRK      T0     0011  00
10     0    8800  00  1            BRK      T0+T1  8800  00
10     0    8800  00  1            BRK      T0+T1  8800  00
11     0    0087  00  1            BRK      T0+T1  0087  00
11     0    0087  00  1            BRK      T0+T1  0087  00
12     0    00ff  00  1            BRK      T0+T1  00ff  00
12     0    00ff  00  1            BRK      T0+T1  00ff  00
13     0    00ff  00  1            BRK      T0+T1  00ff  00
13     0    00ff  00  1            BRK      T0+T1  00ff  00
14     0    00ff  00  1            BRK      T0+T1  00ff  00
14     0    00ff  00  1            BRK      T0+T1  00ff  00

The 'rw' is the RnW pin, whereas the internal signal 'RnWstretched' (not shown above, but easily traced) is a not-DataBusEnable. It's forced high by the reset pin relatively directly, and Segher tells us that the logic to do this is the same on the RevC blueprint as it is on the RevD chip.

So far, this isn't looking like confirmation. (Note that the actual bus values during these cycles might be artefacts of the simulation, if the internal datapath controls go through unusual states. But I don't think that's important.)

Cheers
Ed

[Dr Jefyll]

BigEd wrote:

Note that the actual bus values during these cycles might be artefacts of the simulation, if the internal datapath controls go through unusual states.

The simulator is amazing, and I have just begun to really play with it for the first time. Thanks, BigEd, for setting up that example. As for artifacts, it's only reasonable to expect there'll be some sort of limitations.

(Excerpt from previous post:)

Code: Select all

cycle  res  ab    db  rw  Fetch    Execute  State  pc    ir 
  ...
8      0    0010  e8  1   INX      JSR Abs  T1     0010  20
8      0    0010  e8  1   INX      JSR Abs  T1     0010  20
9      0    0011  88  1            BRK      T0     0011  00
9      0    0011  88  1            BRK      T0     0011  00

Might this reveal a simulation glitch? What jumps out at me here is that the PC is shown as having incremented, just as a RST interrupt is recognized and BRK has replaced the previous contents of ir. That's unexpected, since the MOS Hardware Manual indicates no increment (section A. 5.4. pg A-11), and even the simulator itself shows no increment if I replace the RST interrupt with an NMI interrupt. (I wasn't able to try an IRQ interrupt since I don't know how to CLI, either by direct flag manipulation or by adding a CLI instruction to the program.) I wonder, is this an artifact, or is it reliable info hinting at special-case circuitry pertaining to RST (and possibly to bus contention)?

-- Jeff

[BigEd]

Hi Jeff
I think there's a complicated set of questions raised there!

First point, the nomenclature in the MOS appendix doesn't quite match that of the simulator. They have the stack writes in T2/3/4 and we have them in T3/4/5.

I don't expect any interesting difference between NMI and IRQ, except possibly latency near the pin due to input conditioning/edge detection. We can patch in a CLI and NOP at the start of the program. Then we can compare

• BRK instruction
  IRQ
  NMI
  Reset

and what we see is that PC is not incremented for NMI and IRQ - which makes sense, because the pushed value must point to the instruction we intend to return to. The BRK does increment PC, as it must, because it is a two-byte instruction. The reset's action doesn't really matter.

I wrote up some info on the circuit which controls the increment of PC - it's quite complex and quite critical, because incrementing a 16-bit value is difficult and it has to happen in a single cycle, but the decision has to be made quickly. In fact I think the low cost of branches on 6502 has something to do with this circuit.

We could trace all the signals I mention, and then trace back a bit further, to see where these four different case diverge. I think in fact it'll be D1x1 which is the interrupt-pending latch.

(The document you cite isn't going to be definitive, compared to the circuit itself. One can say that an interrupt is rather like a forced BRK, but it isn't precisely like one.)

Cheers
Ed

[Dajgoro]

Well, i don't understand this anymore, you said that if the reset line is hold too long the chip will overheat and burn up? Did i get it right?
Well i didn't know about that, i usually reset my 6502 sbc by shorting jumpers with a screwdriver, since i didn't finish the reset circuit yet.
And by doing that i held the reset line for a second(or more) at least, and the cpu is still working... I use a CM630P(Bulgarian clone) for testing and i tried the UM6502 also, and they still work, so i didn't read something in the topic right or what?

[BigEd]

Hi Dajgoro
only two people say there might be a problem- and even then, the problem probably only exists with certain parts. I tried to reproduce the problem, and nothing happened, so I'm not really convinced. It sounds like you too have seen no evidence. All the early computers seemed happy to tie reset directly to a button with no restriction on how long it's asserted.

Garth is remembering something about early NMOS devices - I wonder if he is mis-remembering. That's why I'd prefer to find some document or experimental supporting evidence, or another supporting opinion.

ioncannon had a heating problem, but he was in the early stages of bringing up his design, and he uses a 2A03 which is something different from a 6502, so I'm not sure that would be the same problem anyway.

So, I think there may be no bug - I'd be happy to see more evidence.

Cheers
Ed

[Dajgoro]

Well i just tested my brand new Rockwell R6502AP, never used before, and i held the reset for 3 seconds, still works...

[BigEd]

Thanks for the experiment - no heating up?

One idea is that only the very earliest 6502s would have been affected - the ones with the ROR bug. That idea will be difficult to test.

Cheers
Ed

[GARTHWILSON]

Quote:

Garth is remembering something about early NMOS devices - I wonder if he is mis-remembering. That's why I'd prefer to find some document or experimental supporting evidence, or another supporting opinion.

I have an excellent memory, but I don't always remember where I read something so I can go back 25 years later and verify the accuracy of what was reported or look further into the details of the conditions. I probably wasn't very interested though since by the time I read it, I had started using CMOS ones and wasn't going back.

[BigEd]

Ah, perhaps you picked up the info from an unreliable source - I hadn't thought of that. Or perhaps it related to one batch, or one source, or some other small subset. It certainly doesn't seem to apply very widely.

Cheers
Ed

[Dr Jefyll]

Dajgoro wrote:

Well, i don't understand this anymore, you said that if the reset line is hold too long the chip will overheat and burn up? Did i get it right?

Yes, but "burn up" may be putting it much too strongly. It's true we're talking about excess power dissipation -- and engineers get very uncomfortable about that sort of thing! Still, paranoia aside, my own experience suggests that these chips aren't so easy to kill, and I suspect that RST would have to be held true for, say, nearly a minute or more before a probable threat of permanent damage arises.

BigEd wrote:

I don't expect any interesting difference between NMI and IRQ, except possibly latency near the pin due to input conditioning/edge detection. We can patch in a CLI and NOP at the start of the program. Then we can compare

BRK instruction
IRQ
NMI
Reset

Thank you for that, Ed. I didn't mean for you to go to so much effort (with variations on the simulation). I am willing to do that work myself, but the Visual6502 User Guide seems to lack some of the necessary information (eg: how to modify the program). What's the best way to raise an issue about the User Guide?

Quote:

One can say that an interrupt is rather like a forced BRK, but it isn't precisely like one.

I agree with this and with your other observations. And I've strayed slightly from the focus of this thread, which is the reported RST bug and heating effect.

I hope to get my hands on a 2A03 cpu, and then it ought to be fairly easy to duplicate (and elaborate on) ioncannon's observation about heat and Reset.

-- Jeff

[Dajgoro]

Dr Jefyll wrote:

Dajgoro wrote:

Well, i don't understand this anymore, you said that if the reset line is hold too long the chip will overheat and burn up? Did i get it right?

Yes, but "burn up" may be putting it much too strongly. It's true we're talking about excess power dissipation -- and engineers get very uncomfortable about that sort of thing! Still, paranoia aside, my own experience suggests that these chips aren't so easy to kill, and I suspect that RST would have to be held true for, say, nearly a minute or more before a probable threat of permanent damage arises.

Well i didn't mean it would catch fire or something like that, i only meant that the chip would not work anymore, since someone said recommended time is 50-100ms, 3 second it at least 30x more. It will be more likely that the chip might get damaged if the reset line is held down for a minute like you said...