EPROM Emulator Proposal

[Terry/Carol Kelley]

If the emulator is powered externally (many are powered by the ECM), then
the ECM is irrelevant. I think bank switching is likely the easiest to
implement. Writing the routines to get into a memory location during an off
memory cycle sounds easy until you start soldering parts together.

Unless someone want to spend tons of time on this and not get much back,
KISS. Bank switch, and toggle OE and CS. To keep the load time down, write
to the off bank (one or many bytes) and then switch it in.

The problem is the off bank with be behind one edit, so it will need to be
updated right after a toggle with the new bytes.

So on the first load of the emulator, load the binary and make that bank
active. Then use the editor to change the code in the off bank. Switch the
banks, update the new off bank and allow editing on it.

Terry Kelley

1986 Olds Ciera GT 3800 Supercharged

-----Original Message-----
From: thergen at svn.net <thergen at svn.net>
To: gmecm at esl.eng.ohio-state.edu <gmecm at esl.eng.ohio-state.edu>
Date: Wednesday, April 07, 1999 3:27 PM
Subject: Re: EPROM Emulator Proposal


>Battery backed rams I've used have usually been very picky about the
>states of chip selects during power-up/power-down/power-off.  It's very
>easy to do an accidental write to an arbitrary location.  Often, chip
>selects and write enables are active low.  Low is where all the signals go
>during power-down (hence the need for the special handling of chip
>select).  Chip select level(s) during power off may also determine whether
>or not the lowest power state is entered which can severly affect backup
>battery life.
>
>Tom
>
>On Wed, 7 Apr 1999, Squash wrote:
>
>> But if dpram is battery backed, there should be no
>> need for a weird circuit on power-up, right?  It would
>> act just like an eeprom?
>>
>> Andy
>>
>> --- thergen at svn.net wrote:
>> > I think it's a good proposal.  I'd like to suggest
>> > that a pushbutton
>> > switch be part of the design that can be used to
>> > reload the default dpram
>> > bank from the eprom (assuming it's present) so that
>> > you can recover from a
>> > corrupted ram image without using a laptop computer.
>> >  Power-up/power-down
>> > need special attention (as you already know) to
>> > avoid corrupting the ram.
>> > Maxim (www.maxim-ic.com) and others make parts with
>> > voltage supervisors
>> > specifically for memory protection (let me know if
>> > you want specifics).
>> >
>> > Tom
>> >
>> > On Wed, 7 Apr 1999, Ludis Langens wrote:
>> >
>> > > The EPROM emulator debate on this list seems to be
>> > going in circles.
>> > > Either people have short memories, or there are a
>> > lot of new members who
>> > > missed the discussion and decisions made in the
>> > first few weeks of
>> > > gmecm.  Either way, please read through the
>> > archives.
>> > >
>> > > Anyway, here is an emulator proposal based on the
>> > prior discussion.  I
>> > > did some ruthless cutting of features and
>> > expandability (indicated with
>> > > a *).  I propose the use of a single dual-port
>> > SRAM (from Cypress or
>> > > IDT) and a 40/44 pin PIC microcontroller to load
>> > this RAM.  A battery
>> > > back up will keep the SRAM alive.  This allows an
>> > ECM to boot from the
>> > > DPRAM immediately upon power-up.  The whole
>> > emulator circuit board
>> > > should be small enough to fit inside a
>> > '165/'727/'730/'749/'808 ECM.
>> > ....
>> >
>> >
>> >
>> >
>>
>> _________________________________________________________
>> Do You Yahoo!?
>> Get your free @yahoo.com address at http://mail.yahoo.com
>>
>
>