prom dump program (and emulator editor)

[Marc Randolph]

On Tue, Apr 06, 1999 at 10:51:31PM +0100, steve ravet wrote:
> I wrote a little program that dumps prom images to the screen in sort of
> a text format.  It's called tuna.  It's like promedit in that it's
> driven by a text file that describes the location and size of tables,
> but the .ecm files are easier to read and create (IMO).  I eventually
> want to make this an editor but I'm uploading it now for 2 reasons:
> 
> 1)  I'd like to get comments on the .ecm format.  It's a little verbose
> but I think it works well.

I agree it is a little verbose, but it sure does make it nice not
to have to refer to a description file to find out which column does
what, only to find out later you counted the number of commas 
incorrectly and you put the data in the wrong column!

> 2)  Other people are working on other editors, and I hope that they'll
> be able to incorporate this code into their programs to make them
> extendable to other ECMs.
[...]
> If you are working on a PROM editor, please feel free to incorporate my
> stuff into your program.  Also, send me any
> changes/suggestions/additions.

[... and David Cooley wrote on a different thread:]

> That would be great... the more "intelligent" we make the emulator, the
> simpler and dumber the software on the laptop/pc can be...
> The other idea for software is there are several people working on chip
> editors... when we decide on what to use for an emulator, they may be able
> to include the software into their editor package, allowing the software to
> update only the changed bytes.

The software on the laptop can't be too dumb...
I'm here to tell you, having the editor present the data in table
form for editing is almost a must.  I was tuning on a car last
night on the dyno using a generic emulator in place of the prom.
Since the software for this emulator was generic, it didn't present
anything in table form, it was just a raw sea of bytes that I could
change (with hex addresses for the beginning of each line).

Needless to say, it took me a LONG TIME to make changes because
I'd have to go to the approximate address I want to edit and then
do a visual search for the byte I wanted to change, go there, make
sure I was on the correct byte by doing a visual comparison with the
printed copy I have (which IS in table form) to make sure I was
at the right place, and change that byte.  Then I'd have to do
the same thing again for any other byte I wanted to change.

It was a pretty slow process, and ends up costing money because
time is money when the car is sitting on the dyno waiting for 
me to make these changes to the prom.  If it was in table form,
I could instantly go to what I wanted to change and I would know
it was the correct byte.

In summary, I hope Steve's suggestion is followed and the editors
are designed to present data based on an .ecu or .ecm file.

   Marc

-- 
  Marc Randolph     -    mrand at pobox.com    -     PGP keyID: 0x4C95994D