6502.org Forum Projects Code Documents Tools Forum
It is currently Thu Nov 21, 2024 10:10 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 2 of 3
  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
  Previous topic | Next topic 
Author Message
BigDumbDinosaur
PostPosted: Mon May 30, 2022 6:39 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
Kaldek wrote:
Problem solved folks. It was the fact that I had removed the power rail filter capacitors.

As I’ve often opined, bypass capacitors are like money. You’ll never have enough. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Kaldek
PostPosted: Tue May 31, 2022 12:37 am 
Offline

Joined: Sun May 29, 2022 1:10 pm
Posts: 7
John West wrote:
Ben uses 74LS chips. They have a fairly high constant current draw, with relatively low peaks when switching. They don't need a lot of decoupling. CMOS is different - it needs very little current while nothing is happening, but suddenly needs a lot when switching. Power distribution becomes a lot more important with CMOS.

The 74LS is also how he gets away with leaving unused inputs floating. TTL inputs will safely float high if you don't connect them. CMOS gets unhappy and can oscillate.

He cuts a lot of corners that I wouldn't, but those details would get in the way of the main point of the videos. And his designs do work.


Thanks for that extra info, it's really educational and essentially the reason I'm doing this.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue May 31, 2022 12:57 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
Kaldek wrote:
Thanks for that extra info, it's really educational and essentially the reason I'm doing this.

For what it’s worth, Ben Eater’s videos have sent quite a few people here trying to get their systems running. You might say Mr. Eater is inadvertently increasing the 6502.org membership. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
tmr4
PostPosted: Wed Jun 01, 2022 7:03 pm 
Offline

Joined: Sat Feb 19, 2022 10:14 pm
Posts: 147
John West wrote:
CMOS is different - it needs very little current while nothing is happening, but suddenly needs a lot when switching. Power distribution becomes a lot more important with CMOS.

This helps shed some light on the problem. The address decoding in Ben's 6502 breadboard build uses a 74HC00 which is probably why this one in particular becomes an issue for many builders.
Top
 Profile  
Reply with quote  
ytropek
PostPosted: Tue Dec 12, 2023 7:35 pm 
Offline
User avatar

Joined: Tue Dec 12, 2023 7:00 pm
Posts: 25
Location: London, UK
Nearly 1.5 years after @Kaldek created his original post, I faced exactly the same issue - FFFE/F on start instead of FFFC/D. In my case adding bypass capacitor didn't solve the problem, although I made an interesting observation: I installed a push button on my breadboard to manually control reset pin on W65C02 and after pressing the button I can observe the correct reset sequence (FFFC/D). However on power up, the CPU consequently acts like IRQ.

Here is what I see on the address bus:
Power up sequence:
Code:
FF00, 0000, 0001, 0100, 01FF, FFFE ,FFFF

Reset sequence:
Code:
FFFF, 0002, 0100, 01FF, 01FE, FFFC, FFFD


According to the well know Pagetable article (https://www.pagetable.com/?p=410) the sequence, at least on 6510, should be
Code:
00FF, 0100, 01FF, 01FE, FFFC, FFFD

So there are still some differences.

I can fix the problem by programatically keeping the reset pin low for two cycles on start, but it feels like a workaround. I'm curios whether you have some ideas or suggestions how to fix the problem or how I could investigate it further. The correct reset sequence indicates that this is not a software issue.
Top
 Profile  
Reply with quote  
gfoot
PostPosted: Tue Dec 12, 2023 7:37 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
The datasheets explicitly say that you should keep RESB low for a certain period of time after the power comes up - otherwise you'll see odd behaviours like this as different bits of the CPU start in different, random states.

Typically you'd use an RC delay circuit wired through a Schmitt trigger to ensure all ICs in the circuit see the reset pulse end at the same time - or a DS1813 or similar which does a lot of that for you.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Dec 12, 2023 8:19 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
Reset must be held low for a minimum of two clock cycles.  I can confirm from testing with the 65C816 that anything less will result in a failed reset and unpredictable behavior.  As gfoot says, dampen the reset push button with a Schmitt circuit or use a Maxim DS1813 reset generator—I use the latter, since it takes up almost no space on the board.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
ytropek
PostPosted: Tue Dec 12, 2023 9:31 pm 
Offline
User avatar

Joined: Tue Dec 12, 2023 7:00 pm
Posts: 25
Location: London, UK
Indeed that single sentence from the datasheet (" The RESB signal must be held low for at least two clock cycles after VDD reaches operating voltage") is a key here. Thank you so much for the prompt replies to, as it appeared, my very noob question. I've already ordered DS1813.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Wed Dec 13, 2023 12:16 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
ytropek wrote:
Indeed that single sentence from the datasheet (" The RESB signal must be held low for at least two clock cycles after VDD reaches operating voltage") is a key here.

Yep!  Oscillators, whether of the “can” type, or a roll-your-own circuit using a crystal, take a not-insignificant amount of time to commence oscillation after power has been applied.  Observation of the oscillators I use in my POC units shows that anywhere from 10 to 50 milliseconds is required for output to stabilize.  Hence it’s important to keep reset low long enough to assure the oscillator is awake and the MPU is seeing a strong signal.  The DS1813 easily accommodates that, as it times out after about 150 milliseconds.  If your oscillator isn’t stable by then, you need a different oscillator.

Also, note that the DS1813 comes in several flavors, in that the percentage of VCC that must be seen before the device starts its timing cycle varies by part number.  Your choice would depend on how confident you are of your power supply’s regulation.

As far as use of the DS1813 goes, I recommend you pull the reset line up to VCC through a 3.3K resistor.  The DS1813’s internal pullup is weak—omitting the external pullup may make reset noise-sensitive.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
sburrow
PostPosted: Thu Dec 14, 2023 1:59 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
BigDumbDinosaur wrote:
Also, note that the DS1813 comes in several flavors, in that the percentage of VCC that must be seen before the device starts its timing cycle varies by part number.  Your choice would depend on how confident you are of your power supply’s regulation.

As far as use of the DS1813 goes, I recommend you pull the reset line up to VCC through a 3.3K resistor.  The DS1813’s internal pullup is weak—omitting the external pullup may make reset noise-sensitive.


Like BDD, I also use a pull-up resistor with my reset supervisors. I have used the DS1813 in a few designs of mine and it worked great, but I can also recommend the MCP130. There are a few flavors of that as well, but if you want a compatible pinout to the DS1813 use the MCP130xxD ( I remember this by saying the 'D' stands for "DS1813 compatible" ). The two devices operate a bit differently, but I've found no difference in normal operation by using either one. The reason I bring this up is because the MCP130 is cheaper than the DS1813.

Thanks!

Chad

EDIT: Read to the bottom where BDD clarifies my mistake!


Last edited by sburrow on Thu Dec 14, 2023 10:32 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Dec 14, 2023 8:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
sburrow wrote:
Like BDD, I also use a pull-up resistor with my reset supervisors. I have used the DS1813 in a few designs of mine and it worked great, but I can also recommend the MCP130...The reason I bring this up is because the MCP130 is cheaper than the DS1813.

Note, however, that that lower cost comes at a cost.

Unlike the DS1813, the MPC130 doesn’t respond to a push button on the reset line.  You have to insert the push button in series with the device’s VDD input to trigger a timed reset sequence.  This necessity complicates using the MPC130 in conjunction with a watchdog timer to restart a system that has crashed.  The DS1813, on the other hand, monitors the reset line and if anything pulls it low, will automatically start a timed reset sequence.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
sburrow
PostPosted: Thu Dec 14, 2023 9:11 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
BigDumbDinosaur wrote:
sburrow wrote:
Like BDD, I also use a pull-up resistor with my reset supervisors. I have used the DS1813 in a few designs of mine and it worked great, but I can also recommend the MCP130...The reason I bring this up is because the MCP130 is cheaper than the DS1813.

Note, however, that that lower cost comes at a cost.

Unlike the DS1813, the MPC130 doesn’t respond to a push button on the reset line.  You have to insert the push button in series with the device’s VDD input to trigger a timed reset sequence.  This necessity complicates using the MPC130 in conjunction with a watchdog timer to restart a system that has crashed.  The DS1813, on the other hand, monitors the reset line and if anything pulls it low, will automatically start a timed reset sequence.


You know, that makes so much sense BDD! I understand completely what you are saying. Yet, for some reason, every time I use it just like a DS1813 it works just fine. Maybe my reset isn't properly debounced and my code has been doing screwy things in the background that I just never detected. Hm!

Surely if I put an <insert integer> millisecond delay upon reset in software, it would prevent anything screwy happening even without proper hardware debouncing?

Chad
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Dec 14, 2023 9:54 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
sburrow wrote:
Yet, for some reason, every time I use it just like a DS1813 it works just fine.  Maybe my reset isn't properly debounced and my code has been doing screwy things in the background that I just never detected.  Hm!

Unless your push button drives reset through a Schmitt trigger of some sort, you are not debouncing reset and meeting the MPU's requirements for a proper reset.

Quote:
Surely if I put an <insert integer> millisecond delay upon reset in software, it would prevent anything screwy happening even without proper hardware debouncing?

That won't help.  What matters is the MPU's reset input (RESB) must see a clean transition from high to low after the clock has stabilized, reset must stay down for at least two Ø2 cycles and then the MPU must see a clean transition from low to high on the reset line.  Achieving that is a hardware function.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
sburrow
PostPosted: Thu Dec 14, 2023 10:32 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
BigDumbDinosaur wrote:
sburrow wrote:
Yet, for some reason, every time I use it just like a DS1813 it works just fine.  Maybe my reset isn't properly debounced and my code has been doing screwy things in the background that I just never detected.  Hm!

Unless your push button drives reset through a Schmitt trigger of some sort, you are not debouncing reset and meeting the MPU's requirements for a proper reset.

Quote:
Surely if I put an <insert integer> millisecond delay upon reset in software, it would prevent anything screwy happening even without proper hardware debouncing?

That won't help.  What matters is the MPU's reset input (RESB) must see a clean transition from high to low after the clock has stabilized, reset must stay down for at least two Ø2 cycles and then the MPU must see a clean transition from low to high on the reset line.  Achieving that is a hardware function.


Whelp, I suppose I have now seen a near-fatal flaw in my previous designs. Oof! I'm glad it is still working, but I won't do this in the future. Thank you BDD, good call, this helped the future me a lot!

I'm going to put an 'edit' in my first statement saying "read to the bottom!"

Chad
Top
 Profile  
Reply with quote  
drogon
PostPosted: Thu Dec 14, 2023 10:42 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
sburrow wrote:
Whelp, I suppose I have now seen a near-fatal flaw in my previous designs. Oof! I'm glad it is still working, but I won't do this in the future. Thank you BDD, good call, this helped the future me a lot!

I'm going to put an 'edit' in my first statement saying "read to the bottom!"

Chad


30 million Atari 2600s had a resistor, small capacitor and a push button.. so that's what I have in my latest minimal system. Working fine so-far.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 3
  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 30 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

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.