Presently I am using an RC circuit to reset the CPU. I would like to build on the simplicity of an RC circuit to make the OS run from a 32kx8 SRAM (only 8k used).

I'm also using a 20 ns 32Kx8 SRAM (lower half of memory) and a 70ns 8Kx8 EEPROM for the OS in my project. Presently, the 65C02 can run up to 7MHz using F series decoding logic (I will switch to AC series soon with supposedly no loss in speed). However I would like to run the OS from SRAM as the access time is 3x faster than the EEPROM, and hopefully I can get the 65C02 up to 12+ MHz.
I've come up with a schematic below which shows the concept of what I am trying to do. I'll try to explain it...

Whenever the EEPROM is accessed, the SRAM on the right is accessed as well. Imagine 2 identical 8Kx8 SRAM's 1 piggybacked on top of the other with all pins touching except the /OE's. When I run the OS copy program, the SRAM will be written to, the EEPROM will ignore writes.

Only the /OE's from the EEPROM and SRAM are manipulated from a signal that originates from a SPDT reset switch.

When reset is momentarily pushed, the RC cicuit holds the reset low for approx 1 sec for the CPU, and the /OE of the EEPROM is held low by the second RC circuit for approx 3 sec. This gives the software about 2 sec's to copy the OS to the SRAM, and modify the reset vector to skip over the copy portion of the OS. After the 3 sec's, the signal goes back high, U2 inverts it back to a low signal and it goes into a 50uF bipolar capacitor which is then fed back into the CPU reset thereby resetting the CPU circuit one last time to start the OS running from the SRAM with the new reset vector in place.

I have not wired this up yet and my only anticipated problem is C3, the 50uF capacitor in the upper left. I am not an analog person, and am unsure if this value is right or if the 3 second reset signal will even make it back to the RC circuit that resets the CPU.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Maybe I need a small signal diode, like a 1n914, between U2 and C3?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Without taking time to review every detail, I will comment that the OE\ input of the EPROM is not a schmitt-trigger input, and putting it on an RC circuit with the voltage slowly rising is definitely not guaranteed to work without problems. The same goes for the 74x00. I think the best related approach might be to use schmitt triggers and make sure the ROM's output is disabled at the same time that the RAM's is enabled, having given enough time to pre-load the RAM. After that pre-load time, put the program in a loop to keep alternately storing a couple of different values in the same byte of RAM so when they they read back correctly, you know you're now operating off the RAM, then proceed with the regular reset routine, without doing a double reset.

Will the LCD take the kind of speed you're looking for? The intelligent character ones I've used can't go anywhere near that fast, so I had to interface them through VIAs.


How would you ever get C3 to discharge after it's charged?

Just to adress the easier issues first, out of order...


The display is already working with a 6MHz WDC65C02, the pixel clock can go up to 300MHz, so I think it can handle a speed increase.

I will use schmitt triggers before the non-compatible inputs.

The 65C02 reset has a schmitt trigger built in? I thought I did read that somewhere...

But most importantly:
The intent of C3 was to give a "quick pulse", not a full 3 sec "charge". Like I said, I am weak in this area of design, but it is where I really need some help.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Right. That won't necessarily be true of the RST\ inputs of all the I/O ICs you might have though.

Here's the crux of what I am trying to do. I need to re-introduce a pushbutton-like momentary effect back into the 1sec RC delay circuit, after the 3sec delay is over. Wouldn't a capacitor do that? It would be discharged through R1.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Get rid of the 74LS and use 74HC or AC. The input current for LS is potentially twice as much initially as what you're shootin' for going through that 30K resistor, and changes non-linearly. It's not the way to keep control of timing. Any of the CMOS families have input impedances that are basically infinite for this application, making it easier to keep control of the charging times from the outside. Remember also that aluminum electrolytic capacitors typically have a wide tolerance, like -20% to +80%. They're not terribly good for controlling timing.

The inverter for the RST to the µP makes the polarity backwards. When you push the button, you get a low to the inverter's input so the output gives a high to the RST\ input. When C1 charges up sufficiently, the inverter's input will go high enough to make the output low. If you want to ground the button, you'll need an extra inverter stage there.

Next, when you push the RST button, U2-3 will be low, meaning pin 4 is high, and the EEPROM is disabled. Also, the RAM output is enabled when there's nothing of value in it yet. That's backwards from what you want, so you need to swap those two. I also don't think a second reset of the µP is really what you want. Why not leave an open circuit where the question mark is, use a single-pole pushbutton (which is far more common anyway), and put a diode from the RST\ output to your second RC, with the anode toward the RC. (Especially with that diode in there, I think you'll want 74HC or AC, not HCT or ACT.)

You can probably shorten the delays a lot too, and reduce the capacitor size. With CMOS inputs, you could further reduce the capacitor sizes my making the resistor values higher. Your first RC only needs to be long enough to debounce the switch, and 50-100ms is plenty for that. You'll probably push the button for at least a quarter of a second to start, and RST\ only needs to be down for a few full valid clock cycles. I'm sure it won't take anywhere near 3 seconds to copy enough EERPOM to RAM either.

In timing-critical applications that require integral microfarad values, I tend to gravitate toward tantalums. More cost, but generally better tolerances and less leakage.

Regardless of what you use, that cap on the EPROM's /OE line is not going to work for you. EPROM manufacturers do not guarantee proper operation if the rise and fall times on control inputs are not met. The /OE line will be seeing a very lazy rise in voltage, and it's a certainty that the EPROM will get confused as the voltage (lazily) crosses through the logic threshold.

One possibility if you want to delay the release of the EPROM's /OE line is to use a comparator as a timer. Output transition speed on an LM393 should be sufficiently fast to assure the EPROM knows when the state of /OE changes. That said, I think I'd investigate a different way to map the EPROM out after the code has been downloaded.


74AC or 74ABT is best. As Garth pointed out, you get the speed of 74F logic but with much lower input drive requirements and better noise immunity.


If the MPU starts out by copying the EPROM to RAM, add code at the end to map out the EPROM and expose the RAM, at which point code in the ROM that had already been copied to RAM would redirect the MPU to wherever you want it to go. All that's needed is a little planning.

BTW, all control of your SRAM should be initiated with /CE, and /OE should be separately controlled according to the current MPU operation. /CE should be asserted/de-asserted according to the state of A0-A15, but the state of /OE should be qualified by R/W. Although the truth tables for a lot of SRAMs say /OE is a "don't care" when writing to the SRAM, prudence says do not assert /OE on a write cycle. I used that logic model in my POC and it works like a charm.

Further to controlling your SRAM, you should to qualify the SRAM's /WE with Ø2. Your circuit shows /WE being directly driven by the MPU's R/W line. The problem with doing so is R/W changes state while the address bus is in transition. This could cause a wild write to SRAM, corrupting data. You need to insert logic to assert /WE only when R/W is low and Ø2 is high.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The SRAM's data pins are always in input mode if R/W\ is low though.


He has φ2 brought into the RAM selects, so he's in good shape there.

Thank you guys for rubbing your brain cells together on my account. I really appreciate the help. I tend to agree with Garth in using the schmitt-triggers to make the RC delays compatible with CMOS TTL logic. The delays work OK in my simulation software, but I am still working on the 2nd feedback /res signal for the 65C02.

I have the next 2 days off from work, so I intend to wirewrap the OS SRAM tomorrow morning, even before figuring out the rest of the logic. I know it's not that difficult. I've just been looking into alot of other stuff... I'm real close to a production CPU board however. There will be at least one more interface board before I hook it up to the fuel injectors. The CPU board I plan to use in future projects with other TFT displays, so this part of the project has to be generic AND high speed, which is why I am spending alot of time on this.

...Been thinking about using FRAM. It keeps it's memory after power down and is more like SRAM than EEPROM...

I think I may need a third RC circuit AND'd or OR'd with the EEPROM/SRAM signals to generate the "momentary effect". Will think about this tomorrow as well. I WILL have a 12+Mhz 65C02 tomorrow.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

In theory. However, different manufacturers may implement their control logic in subtly different ways. I prefer to assume the worse in that regard.


As far as avoiding inadvertent writes, that would be correct. However, doing so has the effect of delaying the RAM select until Ø2 goes high, which would limit the maximum speed at which the circuit would run.

He has two gate delays in the path to /CS and /OE. U1's output won't go low until Ø2 is high, so that's 6-10 NS right there into the time when D0-D7 is valid. Plus there's the 6-10 NS of U4 following A15 changing state. I'd scrap the Ø2 qualification of the SRAM select, instead use Ø2 to qualify R/W and hook A15 directly to the SRAM's /CS. SRAM is going to be in anytime the address is less than $8000, so no need for any additional logic in that department. With A15 directly driving /CS, he'd have almost all of Ø2 low to get the address setup done. As soon as Ø2 went high, the SRAM would be ready for read/write. Just an opinion, of course.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I see a few other problems lurking with your push button circuits. Pressing S1 has the effect of shorting both C1 and C2 to ground, producing a high momentary current flow that will eventually cause the push button's contacts to stick together. Also, the values for R1 and R2 are much too high. I know you are trying to avoid the use of large capacitors to achieve a desired time-constant. The problem with doing so is the effects of capacitor leakage on the final voltage once they've charged. An ideal cap has infinite DC resistance. However, integral microfarad caps aren't at all ideal in that regard. I would consider multiplying your cap sizes by 100- to 300-fold so a corresponding reduction in the values of R1 and R2 can be used. Tantalums are probably your best bet in this case. A quick check shows that 100 to 300 uf tantalums (+/- 10%) are readily available in leaded or SMD form. Only problem will be cost.

However...I'd do it with a timer circuit that immediately resets the MPU and then delays the release of the EPROM's /OE input. It's easy to get predictable delays that way and you don't need to go off the deep end with passive component values. A timer circuit based upon a comparator is stable, repeatable and works with RC values that aren't out in space.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The things you guys pointed out, got me thinking I was on the wrong track, plus I couldn't figure it out. I was never good at analog...

This morning after scrambling my brain cells, I came up with a new approach that I think will work. I started out simple, with a truth table. Should have started there in the first place. From there I was able to come up with what you see below using a 4 bit counter.



After thinking about it further, now I can do the EEPROM to SRAM copy once on startup, and then reset the cpu alone, using the counter enable/disable functions, whereas before on each reset it would have to do the copy.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Oooooh! That sounds painful. Did you have scrambled brains with toast and coffee? I prefer scrambled eggs.


It seems as though it should work. I'd use a 74AC163 instead of the 'HC173. That said, why not arrange your address decoder to simply map out the EPROM after transferring it to SRAM instead of reseting the circuit twice?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Heh, it was sorta painful, and I wish I had some scrambled eggs. But I know when my brain is hurting, it's firing on all cylinders... I wish I could go back to Drexel and relearn matrices. I didn't last but 4 terms there. The knowledge was too concentrated. But thinking though this felt like I was doing the same sort of mental excercises.

Anyway, I decided to put an order in to Digikey for the AC TTL IC's I need to replace the F series with. I went out of my budget to order some other IC's too like some 10ns 32Kx8, and 10ns 8Kx8 SRAMs, even though they're SOJ packages. Had to spend an extra $40 to get the 28pin SOJ to 28pin 300mil PDIP @ $7 a pop, but hey, for 10ns, holy crap, that is some serious speed for static ram, so I ordered some extra like I always do. Building up the inventory...

Now we're talking 7x the speed access times of what I have now, i.e., 20ns SRAM and 70ns EEPROM.

(The links for all kinds of adapter sites are in Garth's thread here: viewtopic.php?t=1492 )

BTW. the 163 won't work. Had to use a 161 with asynchronous /reset.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502