EPROM emulator

[thergen at svn.net]

If you know where in the 360ns access cycle the address is valid, the data
can be latched with a 74373 (74374, 74573, 74574) and the cycle can be cut
short.  The data lines going from the eprom (or flash) have to be
buffered anyways (like with a 74244), so using a latching buffer doesn't
increase the parts count.  Cutting short the ECM's read cycle makes more
time available for the other interface.

I like John's idea #3, interleaving access to a single ram bank.

Tom

On Fri, 12 Feb 1999, Ludis Langens wrote:

> Tom <thergen at svn.net> wrote:
> > 
> > A Cypress cy7c008 or cy7c009 might work
> > 
> > Accesses to the same address at the same time are a problem.  Since
> > there's probably no way to make the ECM cpu wait, collisions would have to
> > be avoided altogether or the ECM cpu should be able to terminate the other
> > sides memory cycle if needed.
> 
> If there are two banks, one for the ECM, and one for downloading, then
> there can't be a collision.
> 
> > The rams mentioned have access times of 20ns
> > or lower compared to the 120ns needed, which may help in the logic design
> > for the collision handling.
> 
> The P4's deselect the PROM for 120ns, but enable it for 360ns.  I don't
> how much of the 360 is lost due to data setup time.  OTOH, the C3's
> might not deselect the PROM at all between back to back accesses.  Which
> brings up the point - it might be good to prevent a bank switch between
> data read cycles of a "LDD $89AB".
>