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.

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:

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: and, in your latest post
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

Jeff,
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.

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.

I knew I was missing something! Thanks.

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

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

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

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

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:)

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

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

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?

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

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

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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

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.


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?


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

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...