Re: 2114's ->RE: BattleZone probs....

No, they didn't (I was working for them!) They never noticed
the glitch and the old 450 nS part never saw it. The design
"worked" so they didn't worry about it.

But then, years later, there were no more 450 nS parts but
LOTS of 20 nS Cyprus parts. The pinout was the same so......

Thank goodness for digital scopes. Don't know if I would
have found it with a regular analog scope.

(The glitch was being caused where their write signals went
through some NAND gates.)

John Robertson wrote:

> I'll bet the manufacturer of that device you were troubleshooting DID
> take the 12 ns delay glitch in mind in the design, maybe the glitch
> enabled the ram to hold the data for that extra bit of time so the
> processor could read it. I suspect the old ram held the data on line for
> a period that the designers used to make the device run as fast as
> possible...
>
> John :-#)#
>
> Rodger Boots wrote:
> >
> > He was probably pretty close. The problem isn't the RAM,
> > it's in what it's connected to (in this case the processor).
> > The processor wants valid data to be present for a few
> > nanoseconds AFTER the end of a read cycle and if the
> > data goes away during that time (to to the RAM being
> > deselected) the processor ends up latching the wrong
> > data.
> >
> > At my Real Job a few years ago I had to figure out why
> > some newly built units were showing scrambled data on
> > the display. What I found out was that they had replaced
> > the original (obsolete) RAM with some new (incredibly
> > fast Cyprus) RAM. The system had a built-in 12 nS
> > glitch on the write line that the old RAM ignored. But
> > 12 nS was a perfectly valid write for the new RAM.
> > And the glitch happened when the data wasn't valid.
> >
> > jwelser@ccwf.cc.utexas.edu wrote:
> >
> > > On Mon, 18 Jan 1999, Anders Knudsen wrote:
> > >
> > > > A reason the faster 2114 may be due to faster setup/hold times of the ram.
> > > > That is, now you have a ram chip with a faster setup time, but more
> > > > importantly in this case a faster hold time. So if the hold time is too
> > > > fast, the data out may not be on the bus for a long enough time for other
> > > > devices on the data bus. I havn't looked at the schematics, but it's
> > > > conceivable that one could replace the other devices with faster ones,
> > > > along with the faster rams, to compensate for the reduced hold times. It
> > > > should be easy enought to trace the ram data path and find which device(s)
> > > > (be they tri-state buffers, or whatever) are being affected by the reduced
> > > > hold time of the faster rams.
> > > >
> > > > -----------
> > > > a n d e r s
> > > >
> > >
> > > I think you're confusing hold time with ehhhh, something else....
> > >
> > > Hold time is the time required after some edge for some signal
> > > to be stable.
> > >
> > > For example, there might be a spec on the Data input, with respect
> > > to the Write Enable input, meaning that the Data must be held, even after
> > > the write enable is de-asserted.
> > >
> > > I think you're confusing hold time with transition time, but in
> > > this context, I don't see how even that would be a problem. Shorter setup
> > > and hold times will only help things. In practice, hold times are usually
> > > very small, and often negative (for registers, for example.)
> > >
> > > Maybe I totally missed what your were getting at though....
> > >
> > > Joe
>
> --
> John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
> Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, Video Games)
> mailto:jrr_at_flippers.com, web page http://www.flippers.com
> "Old pinballers never die, they just flip out."
Received on Mon Jan 18 14:27:38 1999