Re: [Re: [Re: Using 28F256 in a 747 instead of 2732A??????????]]

[Ludis Langens <ludis@cruzers.com>]

Dig wrote:
> 
> The big catch here is that you don't know when the MPU is going to want
> the EPROM again. You might be in the middle of a series of instruction
> fetches, or waiting a while, while it reads an A/D. You really don't need
> much time for a single byte, 100 nS or so should be enough.

Well, the E clock is only at 2 MHz which results in a 500 ns cycle. 
That's long enough to grab the memory for 250 ns, and then give it to
the ECM for 250 ns.

> Might be a Good Thing to go with the address decode logic anyway... a
> 16L8 would be plenty big, and wouldn't take up that much extra board
> real estate. You'd know that if the MPU was busy at addresses lower
> than $8000, you'd have a little time to play with.

What do you intend to decode?  In a P4, the CPU never executes code from
below $8000.  You'd have to track instruction fetches and decode the
fetched opcodes to predict when the CPU will be busy elsewhere.

The EPROM ~OE generated by the MPU is for all reads from $8000 through
$FFFF.  Writes to that range don't assert the signal.  It is also
conditioned by an (internal) VMA signal.  Thus, idle bus cycles don't
enable the EPROM.


Check the gm_ecm archives.  Toward the beginning there was quite a bit
of discussion about EPROM emulators.  Two basic ideas emerged: SRAM that
the ECM itself can write into and switch in place of the EPROM, and a
battery backed up dual port SRAM which is written into by a seperate microcontroller.

-- 
Ludis Langens                               ludis (at) cruzers (dot) com
Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/

----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo@lists.diy-efi.org