Ben Eater's Reset Circuit

[sburrow]

Hello everyone, this is a newbie question.

I was watching Ben Eater's 6502 series - Part 1, and specifically at 6:07 into the video he talks about his reset circuit for about 30 seconds. Cued up:

https://www.youtube.com/watch?v=LnzuMJLZRdU&t=367s

He ties RESB high through a 1K ohm resistor. Then he puts in a push button that goes to ground. That's it. No DS1813's, no MCP130's, nothing else. And, well, it seems to work.

I had talked to Garth about this a while ago, and he mentioned that the W65C02S probably has a schmitt-trigger built into the RESB line. Does anyone have confirmation on this? Or perhaps some other reason why this type of reset circuit is ok?

I figured this would have been discussed before somewhere on the forum, but I couldn't find it while searching. I'm probably not a good searcher.

Thanks everyone!

Chad

EDIT: Would higher resistor values work? 5K? 10K? 100K? If indeed it has a schmitt-trigger built in, ultimately it doesn't matter what resistor is used, correct?

[BigEd]

For a hobby system with a manual reset, it might not matter too much if it doesn't always work - a person would just push the button again. Nor would it matter too much if the system were double-reset within some milliseconds - it's not likely to be used to trigger anything dramatic.

I think the whole idea of a reset controller chip is a much better fit for an engineering or manufacturing environment.

I think Ben's approach knowingly takes a number of compromises which are all about making computer construction accessible and simple. Some people miss the point of that!

[sburrow]

BigEd wrote:

I think Ben's approach knowingly takes a number of compromises which are all about making computer construction accessible and simple. Some people miss the point of that!

Excellent point Ed, thank you.

While pondering this over, I feel like I asked this question once before. So I tried some experiments on my own Acolyte board just now.

1) MCP130 (or DS1813), has internal 5K pull-up. Works upon power up and reset.

2) MCP130 + 10K pull-up = 3.3K pull-up total. Works upon power up and reset.

3) Only 10K pull-up. Power up freaks out the system, but reset works as expected.

4) MCP130 + 1K pull-up = 830 ohm pull-up total. Works upon power up and reset.

5) Only 1K pull-up. Power up freaks out the system, but reset works as expected.

Perhaps if you have sensitive data, or ways that would actually erase data and/or damage the computer if the wrong subroutine was run, then use a supervisory circuit such as the MCP130 or DS1813. If it's just for 'hobby', as you said Ed, then a simple pull-up would probably be fine as long as you are also expected to press the reset button AFTER powering up.

Any other info on this RESB line is welcome, thank you!

Chad

[Paganini]

One thing about Ben's methods is that they're incremental. What you see in any particular video is almost never the "final" step. Also, he doesn't always circle back and spell things out for you. When he says "read the data sheets," he means read the data sheets! He gets into button debouncing and pulse generation in other videos, but it's kind of up to you to notice that the reset line needs to be debounced and held low for a certain duration, either because you're paying attention, or because someone else points it out to you.

[barrym95838]

About 30-something years ago, I used an early 65c802 with a PIA, a little EPROM and SRAM on a breadboard project with a simple RC reset and no button, and it powered up clean, but I would have to dig up the corpse from somewhere to find the R and C values.

[BigEd]

It might be interesting to look up how the Apple 1, the PET, the Superboard, the Atom managed their reset lines - I expect they were pretty minimal about the arrangement. Even moving forward, to the Apple II, the C64, the Beeb, I wouldn't expect to see a reset controller - maybe a monostable.

[Martin A]

BigEd wrote:

It might be interesting to look up how the Apple 1, the PET, the Superboard, the Atom managed their reset lines - I expect they were pretty minimal about the arrangement. Even moving forward, to the Apple II, the C64, the Beeb, I wouldn't expect to see a reset controller - maybe a monostable.

I have a few schematics to hand, looks like the PET, Vic20 and BBC used a 555 timer

An Apple 1 used just a 3k resistor the JPG I have is pretty bad, but I can't see anything other than the resistor

The Atom had an RC (1k/10uf) delay feeding an couple of LS04 inverters

[BigDumbDinosaur]

BigEd wrote:

It might be interesting to look up how the Apple 1, the PET, the Superboard, the Atom managed their reset lines - I expect they were pretty minimal about the arrangement. Even moving forward, to the Apple II, the C64, the Beeb, I wouldn't expect to see a reset controller - maybe a monostable.

Both the Commodore 64 and 128 used a 555 timer to control reset. I don't recall what was used in the earlier Commodore machines.

Garth has noted several times that it was possible to damage the NMOS 6502 if reset was held low too long. That would explain the use of the timer, especially in the C-128, which had a built-in reset button.

[BigEd]

Thanks for looking those up Martin!

BDD, see here for some commentary on the "long reset" idea - it seems to me very much a myth being propagated. I would still say we need some evidence. Which is to say, I take the position it's a myth, but would welcome evidence to the contrary. (That link refers back to this earlier discussion.)

[BigDumbDinosaur]

sburrow wrote:

I was watching Ben Eater's 6502 series - Part 1, and specifically at 6:07 into the video he talks about his reset circuit for about 30 seconds. Cued up...He ties RESB high through a 1K ohm resistor. Then he puts in a push button that goes to ground. That's it. No DS1813's, no MCP130's, nothing else. And, well, it seems to work.

You sure there isn't a capacitor somewhere in that circuit? At least with the WDC MPU’s, reset must stay low for a minimum of two Ø2 cycles. Pressing a push button would easily meet that requirement, but what about at power on?

According to Bill Mensch in E-mail conversation (which I can’t seem to find at the moment), reset has Schmitt action. So it should be possible to get away with a simple R-C setup on the reset line. A push button alone on reset will likely result in several reset transitions due to contact bounce—Schmitt action will not compensate for that, which might violate the timing requirements. As Ed says, if that happens, the MPU will not start and you will need to push the button again.

If you don't want to use the DS1813, you can use the R-C method and work out a time-constant that is a minimum of 0.1 seconds. The reason I suggest that interval is at power-on, your Ø2 oscillator may take several 10s of milliseconds to start and stabilize (the one in POC V1.3 takes roughly 30 milliseconds to start and lock on frequency, observed with the ’scope). Reset should be held down during that time to assure a clean start.

Incidentally, be careful about directly shunting the reset timing capacitor with a push button. The instantaneous current that flows as the capacitor is abruptly discharged when you push the button might be enough to damage the contacts. In circuits of this type, I connect a 22 ohm resistor in series with the push button to limit the peak current flow to about 250 mA.

[BigDumbDinosaur]

BigEd wrote:

Thanks for looking those up Martin!

BDD, see here for some commentary on the "long reset" idea - it seems to me very much a myth being propagated. I would still say we need some evidence. Which is to say, I take the position it's a myth, but would welcome evidence to the contrary. (That link refers back to this earlier discussion.)

I don't personally know if it’s fact or fiction. I do wonder, though, how it got started.

[BigEd]

I think we'd do well not to keep repeating the idea. I see I did a finger test, reported in the linked thread:

Quote:

I have a BBC micro here, with a Rockwell NMOS 6502 with datecode 8402. I held RST for well over ten seconds, with no heating problem and no evidence of ill effect.

Pretty much anyone could re-do that test.

[sburrow]

BigDumbDinosaur wrote:

You sure there isn't a capacitor somewhere in that circuit? At least with the WDC MPU’s, reset must stay low for a minimum of two Ø2 cycles. Pressing a push button would easily meet that requirement, but what about at power on?

So, I noticed how Ben Eater would reset his circuit every time. He was doing it because he was single stepping and wanted to show every part of the reset process, but that also eliminated the need for a power-up reset. Hm.

Quote:

Incidentally, be careful about directly shunting the reset timing capacitor with a push button. The instantaneous current that flows as the capacitor is abruptly discharged when you push the button might be enough to damage the contacts. In circuits of this type, I connect a 22 ohm resistor in series with the push button to limit the peak current flow to about 250 mA.

Wow never thought of that, thank you for the insight. I notice that on your POC schematics that you use the DS1813.

Well, thank you everyone. I'm pretty set on using the MCP130 or DS1813 still, but it is nice to know what alternatives are out there. Any extra comments are appreciated!

Chad

[Dr Jefyll]

sburrow wrote:

Does anyone have confirmation on this? Or perhaps some other reason why this type of reset circuit is ok?

A few years ago I happened to discover that a WDC '816 or a WDC 'C02 can usually be reset by a reset pulse lasting less than one-half a clock cycle . I say "usually" but in my limited testing I've never seen it fail. This tends to belie the datasheet, which states that a multi-cycle reset pulse is required. But akohlbecker had the same result that I did, although again the testing was limited (and he only tested an '816, not a 'C02).

The fact that a reset pulse lasting less than one-half a clock cycle usually works is sufficient to explain Ben Eater's use of the controversial technique. Probably his pushbutton to ground causes multiple reset pulses (due to contact bounce) but that's of no consequence.

Going slightly OT, I'm prepared to question anything I read in a WDC datasheet, and consider it plausible (although of course unproven) that a reset pulse lasting less than one-half a clock cycle is effective not just usually but always. It's not a matter that can easily be proven, but there's some discussion of it in one of adreien's threads, starting with the latter portion of this post.

-- Jeff

[Michael]

I noticed one anomaly (or feature?) while manually clocking a 6502 through the reset sequence using a microcontroller with a "blind interface" to the 6502. When I accidentally started the reset sequence with CLK lo instead of hi, effectively issuing 1½ clocks instead of 2 full clocks while RESET was lo, I needed 8 clocks instead of 7 clocks to load the reset vector after setting the RESET pin hi. Knowing exactly how many clocks is important for synchronizing the uC "blind interface" functions to the CPU.

Code: Select all

  /******************************************************************************
   *  uC 'blind interface' core routines                                        *
   *                                                                            */
   void uReset()                      // ****************************************
   { clk(1);                          // clock = 1                              *
     res(0);                          // reset = 0  ~~~~~~~~~~~~~~~~~~~~~~~~~~  *
     uPull(ram);                      //                                   (1)  *
     uPull(ram);                      //                                   (2)  *
     res(1);                          // reset = 1  ~~~~~~~~~~~~~~~~~~~~~~~~~~  *
     uPull(ram);                      //                                   (1)  *
     uPull(ram);                      //                                   (2)  *
     uPull(ram);                      //                                   (3)  *
     uPull(ram);                      //                                   (4)  *
     uPull(ram);                      //                                   (5)  *
     uPush(lo(0x8000));               // address $FFFC (reset vector lo)   (6)  *
     uPush(hi(0x8000));               // address $FFFD (reset vector hi)   (7)  *
   }                                  // ****************************************

   void wrROM(u16 address,byte data)  // ****************************************
   { uPush(0xA9);                     //  lda <imm>                             *
     uPush(data);                     //   "                                    *
     uPush(0x8D);                     //  sta <abs>                             *
     uPush(lo(address));              //   "         address lo                 *
     uPush(hi(address));              //   "         address hi                 *
     uPull(rom);                      //   "         6502 write op'             *
   }                                  // ****************************************

   void wrRAM(byte data)              // ****************************************
   { uPush(0xA9);                     //  lda <imm>                             *
     uPush(data);                     //   "                                    *
     uPush(0x8D);                     //  sta <abs>                             *
     uPush(lo(addr));                 //   "         abs address lo             *
     uPush(hi(addr));                 //   "         abs address hi             *
     uPull(ram);                      //   "         6502 write op'             *
   }                                  // ****************************************

   byte rdMEM(byte mem)               // ****************************************
   { uPush(0x4C);                     //  jmp $8000  reset PC (avoid I/O area)  *
     uPush(lo(0x8000));               //   "         abs address lo             *
     uPush(hi(0x8000));               //   "         abs address hi             *
     uPush(0xAD);                     //  lda <abs>                             *
     uPush(lo(addr));                 //   "         abs address lo             *
     uPush(hi(addr));                 //   "         abs address hi             *
     return uPull(mem);               //   "         6502 read op'              *
   }                                  // ****************************************

  /******************************************************************************
   *  load 64K RAM from 64K 'A' or 'B' half of ROM at 'power-up' or 'reset' at  *
   *  a nice liesurely 1-MHz rate.                                              *
   *                                                                            */
   void loader()                      // ****************************************
   { addr = 0x0000; x15(0);           // start address $0000, ROM A15 = 0       *
     uReset();                        // reset CPU (synchronize micro to cpu)   *
     do                               // copy 64K ROM minus 8K I/O area to RAM  *
     { wrRAM(rdMEM(rom));             // ROM -> RAM (0000..5FFF & 8000..FFFF)   *
       if(++addr == 0x6000)           // if I/O area ($6000..$7FFF)             *
       { addr = 0x8000; x15(1);       //   skip, ROM A15 = 1 ($8000..$FFFF)     *
       }                              //                                        *
     } while(addr);                   // until roll-over to 0 (full 64K image)  *
   }                                  // ****************************************

  /******************************************************************************
   *  6502 "RUN" mode (disconnect uC, reset 6502, start CPU clock, select RAM)  *
   *                                                                            */
   void runMode()                     // **** switch over to 6502 'RUN' mode ****
   { res(0);                          // reset = 0                              *
     beginClock();                    // start 1, 2, 4, or 8 MHz CPU clock      *
     busInp();                        // disconnect Nano from data bus (hi-z)   *
  // pullUp();                        // enable Nano data bus weak pull-ups     *
  // endSerial();                     // disconnect Nano from usb adapter       *
     PORTC = ram;                     // enable RAM                             *
     res(1);                          // reset = 1 -> 6502 'run'                *
   }                                  // ****************************************