[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Re: [Re: Using 28F256 in a 747 instead of 2732A??????????]]
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