Where to buy 27C128 EPROMS?

[GARTHWILSON]

I suppose if you had corrupted non-I/O pointers and you hoped that in their corrupted state they pointed to an unused place in the memory map so you can keep going (if that's possible), then it might make sense. I think usually a corrupted pointer will be accompanied by other problems anyway, and will mean it's time to re-start the program. If my adderss-decoding scheme didn't take up a whole 16K for I/O, I'd take advantage and use most of that space for more RAM, which means an errant pointer could still write trouble into something I'm using-- it'll just be corrupting data or a program in RAM instead of I/O. I see what you're saying, but it just has not been a problem in the 15 years I've been doing it this way.

I was trying to imagine a situation where you might have I/O pointers like to say, "Set these VIA registers up this way" and not assign which VIA it is until later; but my VIAs and ACIAs are connected to different things, so the hardware dictates that you have to know in advance which VIA or ACIA you'll be using, which means you won't really have any indirects there, only absolute addresses.

[kc5tja]

GARTHWILSON wrote:

I suppose if you had corrupted non-I/O pointers and you hoped that in their corrupted state they pointed to an unused place in the memory map so you can keep going (if that's possible), then it might make sense. I think usually a corrupted pointer will be accompanied by other problems anyway, and will mean it's time to re-start the program.

Yes. More often than not, those "other problems" you speak of are caused by memory writes that go to wrong addresses (things not appearing on the screen, state variables not being updated, etc.; instead, the desired values COULD end up on the VIA ports).

While RAM is often at least 16x as large as I/O spaces, at least, and thus memory corruption is far more prevalent than I/O corruption, the chances of it occuring still isn't zero.

Quote:

If my adderss-decoding scheme didn't take up a whole 16K for I/O, I'd take advantage and use most of that space for more RAM, which means an errant pointer could still write trouble into something I'm using

OK, before I get taken to the burning post again for commandeering another thread, I want to make this clear:

I only said that there is a tradeoff between really fast, relatively fragile address decoding, and slower, more robust address decoding. Yes, a stray pointer can, and by Murphy's law will, potentially affect I/O in a perfect address decoding system too. But the odds of it happening are that much more narrow.

Corrupting RAM is far more preferable than I/O corruption, particularly when you're potentially corrupting disk I/O registers, or nuclear reactor controls, or, ...

Quote:

it'll just be corrupting data or a program in RAM instead of I/O. I see what you're saying, but it just has not been a problem in the 15 years I've been doing it this way.

I'm just saying, to the reader, be careful.

Because you haven't had the experience doesn't mean others won't either. I, for example, have had this experience, and continue to do so to this day, despite being a professional coder for the last 10 years, and coding in an amateur capacity for the last 20.

Quote:

I was trying to imagine a situation where you might have I/O pointers like to say, "Set these VIA registers up this way" and not assign which VIA it is until later; but my VIAs and ACIAs are connected to different things, so the hardware dictates that you have to know in advance which VIA or ACIA you'll be using, which means you won't really have any indirects there, only absolute addresses.

OK, but now you're forgetting about a hhuuggee class of errors all deriving from, e.g., off-by-one errors, and more.

Consider the following chunk of Forth code:

Code: Select all

create ringBuffer
  4 cells allot

variable nextPointer

: placeItem
  ringBuffer nextPointer @ + !
  1 cells nextPointer @ + -4 cells and nextPointer ! ;

As long as nextPointer remains properly aligned, nothing bad will ever happen. But, what happens if someone accidentally forgets a @ or something while debugging interactively? As in, xyz /something $DD fill or whatever. Doing this has a high likeliness of corrupting nextPointer so that it has, e.g., an odd value. Worst, it's value plus the address of ringBuffer could very well point into I/O space, where the item stored could corrupt an I/O register.

Never underestimate the power of human error, particularly with powerful programming systems like assemblers or Forth.

I've run into this problem constantly. Even on GForth under Linux, where it exploits memory protection hardware to guard itself as much as it can, I still manage to crash GForth utterly such that I need to physically kill the process and restart it from the shell. In embedded systems terms, this is equivalent to physically cutting power and rebooting it.

To re-iterate: yes, you can use an amazingly small amount of logic to decode your addresses for I/O. Doing so necessarily makes the "I/O space" larger in proportion to memory spaces, and thus, makes sensitivity to stray, errant pointers that much greater. If you do this, be aware, and take particular care to minimize pointer corruption.

[Icy]

I hate to interrupt this thread,
but my situation is frustrating.

When I use old 6116 SRAM,
the program starts and works flawlessly no matter what EPROM or PROM I use.

When I use NVRAM (Dallas), 150ns or 200ns,
program runs flawlessly with Microchip OTP PROM, 150ns.
It will not run or will work peculiarly when I use EPROM, 120ns, 150ns, 200ns.
It will work fine with 250ns EPROM, though.

I used to burn Microchip OTP’s, so did not have this problem. I am out of these.
Now, I have ordered 100ns NVRAMS (that is as fast as they come) and I am trying to order Microchip OTP.
In any case, I have some design changes ahead.
Frustrating!

[GARTHWILSON]

Quote:

In any case, I have some design changes ahead.

I guess so! It sounds like the design is so borderline that small changes in bus-loading capacitance or in setup or hold times on the memory are determining whether it will work or not. The only difference between windowed and OTP EPROM is the package. I'm trying to think of what mistake might have been made to cause this. A common one is to not gate the writes to RAM with phase 2, but it doesn't really sound like that's the cause of your problem.

Is the board sprawled out over a large area with long wires and lacking a good central grounding scheme? The inductance of the ground connections and the resulting gound bounce could cause what you're getting, especially because the faster EPROM may not just have faster internal access times, but because its output rise times at the data pins could be faster. Do you have an oscilloscope of at least 20 or 50 MHz with the x10 probes, and if so, how do the waveforms look? Is the ringing bad, or do they look more-or-less square? If this is the problem, you might be able to fix it without major re-work, just by adding ground and power wires from each IC to a central point in a star configuration. Have some capacitance there at the center of the star, from power to ground, maybe a couple of .1 and .01uF's. Keep these wires and leads as short as possible. To see the reasons for this stuff, see my post at viewtopic.php?p=945#945, my two posts at viewtopic.php?p=800 .

The clock circuit might have problems too. Dr. Howard Johnson, an industry guru in matters of high-speed digital design, says in one of his many articles in EDN magazine that he's seen engineers trying to figure out why their new design wasn't working, barking up all the wrong trees when the real problem turned out to be that the clock signal was not clean enough. The "clock circuit" involves the clock signal distribution, not just the oscillator. He's always talking about factors affecting multi-GHz digital designs; but most of the same things can bite at a few MHz with wire-wrap if the layout and construction are not good and the parts are too fast for it.

[Icy]

The board is fairly large, 11" by 9", but the "computer part" occupies only 4.5" by 3". There are lots of other circuits, RF, analog, digital. Also, I have there 500 V p-p transmit signal needed to drive ultrasonic transducer. This transmit signal generates lot of spikes and takes lot of power, but this does not really mess up the "computer", most of time. I have the program starting problem before the transmit is generated.

I do have RAM Enable and Write Enable OR'd with Phase2 (74HC32).

I do not have there ground plane, no space for it. So, I have thick power and GND tracks. I could not have 'starred' it unfortunately, also no space. But, I've managed to minimize daisy-chaining. I have lots of 0.1uF caps scattered all over the place.
I will try jumpers on power and GND, starred. I do have high hopes about this.

But, that darn ringing! Address lines and clock ringing is about 2 V p-p and decays fast.
The address lines are horrible, ringing is more than 3 V p-p. I am surprised it works at all. Even though EPROM and NVRAM is smack next to 65C02. Two VIAs are further away. But, all of that was there for more than 20 years and it always worked reliably. So, I have to contribute sudden problems to EPROMs and NVRAMS interaction. The EPROMS I have are all old mares. OTP PROMS are relatively new, made by Microchip. Maybe they did some improvements to their OTPs.
I have to go to work on it.
Thanks for the suggestions!

[GARTHWILSON]

Quote:

But, all of that was there for more than 20 years and it always worked reliably. So, I have to contribute sudden problems to EPROMs and NVRAMS interaction. The EPROMS I have are all old mares. OTP PROMS are relatively new, made by Microchip. Maybe they did some improvements to their OTPs.

I designed a particular IC into one of our products in 1994 and had no problems initially. Some time later, the supplier changed the wafer-fab process to get a smaller, more economical die. The oscillator frequency was the same, but they sped up the rise times. Suddenly we had a lot of trouble with electrical noise getting into everything, including the aircraft radios. We had a lot of PC boards already made, and could not afford to just throw them away, so manual labor went into every one of them to improve the immunity by putting bypass capacitors in strategic places where we didn't need them before, and ferrite beads on some wires. What a pain. And try explaining to production people the need to keep leads absolutely as short as possible on the capacitors added in rework! They have trouble believing it's so critical, so a bunch of the units still had problems and had to be re-worked again. I designed the same part into other models later, but improved the design so we wouldn't have the same problem again.

[Icy]

Well, I took a good look at my power and ground distribution, and it is not too bad. I am very cautions about this and avoid at all cost daisy-chaining. These existing track are pretty much “star” type, each major component has its own wide power and ground track. They originate about in the same place. Power supply is not far from chips.
Anyhow, I did install some power and ground jumpers, added capacitors, small or large, up to 470 uF. There was no improvement visible on the scope. Data lines glitches are up to 4 V p-p, but very narrow pulse. The glitches coincide with phase2. Since Phase2 has ringing 2V pp, I tried to minimize that by installing capacitor between Ph2 and ground. Even with minimal Ph2 ringing, there was no change of data lines glitches of 65c02. So, my conclusion has to be that these glitches are generated by 65C02, and are unavoidable. So much for that.

Then, I inserted an old 1 MHz CMD65C02 instead of W65C02. The glitches were the same.
However, with CMD65C02, I can use any combination of EPROM, PROM, NVRAM, any speed, slow or fast. It will work flawlessly, at all time!
So, with heavy heart, I have to conclude that the culprit is W65C02, it is unforgiving!

But, I should mention that my circuit has two CMD 65C22. I didn’t want to bother with installing all those pull up resistors and 2 diodes (IRQ) to use W65C22. I found a box of CMD’s VIA, so trying to use up these.
When I have some time, I will install two W65C22, with all of those pull ups and diodes, to see if that solves the problem.

[GARTHWILSON]

Putting a capacitor from phase 2 to ground can only worsen the problem, even if you put it at the source which is the phase-2 output pin of the processor. The reason: With that extra capacitive load, when the processor's phase-2 output transistors switch, now the sudden current surges must go through the processor's power and ground connections and their inductance; and that current times the inductive reactance results in a voltage, and the outcome is that what the processor sees internally (at the die, not the pin) as ground may be swinging even a couple of volts or more above and below what the other ICs see as ground. An output that is supposed to be at ground doesn't even need to get to 2V above ground before some other parts on the board will start interpreting that as changing from 0 to 1. Outputs that are supposed to be at the high logic level may drop enough for other parts on the board to interpret them as logic low.

BTW, make sure you use the oscilloscope probe in the x10 mode. Otherwise the probe itself adds a ton of capacitive loading and can't respond as quickly either. The frequency rating of the probe (whether 20MHz, 100MHz, or whatever) is always specified for the x10 mode. In x1, it may only be good to a couple of MHz, and you need far more than that anyway.

The capacitors across each IC should be no more than .1uF. .01uF is usually better. .1's with leads (IOW, not SMT) may turn into inductors at only 10 or 15MHz, which is definitely not high enough for the job. These capacitors make the power and ground connections outside the IC share the load of the current spikes that occur in the fast switching so that neither one of them gets kicked around so much, and the ground and Vcc that the IC sees become closer to what the other ICs see. In many cases there will need to be bigger capacitors like your 470uF, but put the .01's as close to the ICs' power and ground pins as you can. The bigger capacitors (1uF, 10uF, 100uF, etc., in that order) will be farther out, so the .01's can have the spot closest to each IC.

The center of your star distribution does not need to be particularly close to the power supply if the other requirements are met. The star's center becomes the real reference, the best you can accomplish without ground and power planes. One of the two primary functions of the planes is to eliminate the inductance in the power and ground connections.

I cannot stress enough how important this matter is, particularly now as run-of-the-mill parts are commonly achieving switching speeds that are almost too fast for casual hobby work. It's not a defect in the parts at all. There's a lot more in the ap. notes I referenced, but I know it will take longer to wade through all that.

[Nightmaretony]

chip pulls, try out www.eldoradogames.com, tell 'em Tony sent ya.