Call for standards: EPROM/cal editing software

[Bruce Plecan]

It disappeared some time ago.
Was availabe at their site
Bruce


> TunerEditor ??
> Where ???
> Lyndon.
> -----Original Message-----
> From: timsiford at hushmail.com <timsiford at hushmail.com>
> To: gmecm at diy-efi.org <gmecm at diy-efi.org>
> Date: November 1, 2000 2:46 PM
> Subject: Re: Call for standards: EPROM/cal editing software
>
>
> >TunerCat already has a nice TDF editor called TunerEditor.  Anyone who
> hasn't
> >seen it should check it out.
> >
> >Tim
> >
> >At Wed, 01 Nov 2000 12:59:39 -0800, Ludis Langens <ludis at cruzers.com>
> wrote:
> >
> >>
> >>Dig wrote:
> >>>
> >>> What I'd like to propose is that we work to define a
> >>> standard for TDFs. This standard would have the
> >>> following requirements:
> >>>
> >>> 1)Be portable across all operating environments.
> >>> 2)Be Human Readable and easily defineable. (ie ASCII)
> >>> 3)Would allow the user to define any size table or
> >>>   single value, including the appropriate conversion
> >>>   factors/formulas to convert the hex value to
> >>> meaning-
> >>>   ful data.
> >>
> >>I've contemplated this subject in the past.  The only solution that
> >>doesn't have built in limits is to make the definition file an actual
> >>program.  What we need is the "Postscript" of chip editors.
> >>
> >>I envision the editor providing lots of standard handlers for tables
> >>and
> >>constants.  The definition file simply creates data structures that
> >>invoke these standard handlers.  If the chip has nonstandard contents
> >>(like a custom MAF table), the definition file itself provides functions
> >>to handle these.
> >>
> >>To avoid reinventing the wheel, an existing programming language should
> >>be used.  Currently, the best choice is Java.  It meets all of Dig's
> >>requirements.  The only drawback is a slight amount of bloat compared
> >>to
> >>a non-executable binary format definition file.
> >>
> >>As far as execution speed, I don't see much difference between reading
> >>a
> >>suitably complex definition file, and interpreting Java byte codes.
> >> One
> >>method is interpreting data, and the other is ... interpreting data.
> >>The difference is that one is non-extensible and the other is
extensible.
> >>
> >>--
> >>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 at lists.diy-efi.org
> >>
>
> --------------------------------------------------------------------------
--
> To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
> in the body of a message (not the subject) to majordomo at lists.diy-efi.org
>
>

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