Re: Memory Emulator (was ASBX code is AMXY)

[Peter Gargano <peter@ntserver.techedge.com.au>]

Hi Mike,

I still haven't machined those Alfa heads for injectors (but that's 
another story)...

mike mager wrote:
>
> [snip]
> When I saw the quotation above, I got to wondering, when emulating memory
> for changing the memory - while the engine is running - or using a
> switchable memory - is the idea to change the data (tables), but not the
> code?

Certainly! In fact, I've answered some off-list email recently
about this very same issue, and I'll described what I'm working
on...
 
The idea is that you add to your existing code's ALDL commands,
with a view to modifying the existing spark/VE/whatever tables
on-the-fly, ie. as the motor is running (otherwise you may as
well just burn another EPROM). Of course, as the tables normally 
exist in EPROM, we need some RAM that can use for the tables.
There are a few ways this can be done, either 

 1. add RAM just for the tables, and relocate these tables into 
    the RAM (this also requires that the tables are loaded into
    RAM at CPU power-up, or at least before you try and start
    the motor).

 2. Run the code AND tables from battery backed RAM - like a Dallas
    NVRAM chip that retains information after the key is switched off.
    In this case, the code is "blown" into the RAM with an EPROM
    programmer just the once, and tables can then be updated on an
    as-needed basis.

Now this "ain't rocket science", and it's certainly been done before
(c/f Kalmaker), but I'm surprised that it isn't done more often.
Perhaps it's because it requires modification to a standard EPROM's
code, rather than just tinkering with the tables?

Anyway, now that you've raised this subject, I have to say that it's
been one of my goals to get such a system up and running. I have
been almost totally distracted from this task by writing a 68HC11 
assembler and a disassembler and other distractions like earning a 
living, etc. But as I have a few other folk interested in this same 
pursuit, and as they are in a better position than me for testing, I
may be forced to actually get a prototype of this system going.

If you haven't quite followed how this works, here's another
(recycled) explanation:

The NVRAM (Non-Volatile RAM) approach works like this.

  1. Disassemble vehicle's stock EPROM and find the ALDL code.
  2. Add to this code to allow modification of the EFI tables.
  3. Assemble the "new" EPROM and produce a BIN.
  4. Replace the EPROM on the MemCal with NVRAM (Dallas chip?)
  5. "Program" the NVRAM with the new code.
  6. Plug MemCal into PCM and test that vehicle functions normally.
  7. Write a program to download the appropriately updated tables
     to the NVRAM via the ALDL data stream.
  8. Start tuning...

For me, the task has a further step - I have a 1227808 which is a
1227165 without the UART driver (U2 on the '165) - but with the
addition of a couple of wires, I can tap into the CPU's UART, and
get a "high-speed" data link to/from the CPU, and the NVRAM's contents
can be updated.

To answer your last question:

> If the program code is changed, is a reboot/reset/re-initialization the
> only way to get the 'new' prgram to run properly?

Assuming that a new program is really only a set of new tables,
as the tables are changed by the software itself, it can be 
guaranteed the tables are never changed half way through a calculation.
That is potentially a problem if an emulator changes tables, and 
certainly a problem if an emulator changes code (but this will be
a very rare event in any realistic tuning scenario). 

A hardware EPROM emulator is really a "sledge hammer" approach to 
modifying tables (IMNSHO!). 

So, that's the theory! Now I'm off to modify my ASBX/AMXY, etc. code
to add the UART code that is found (for example) in BUA, then modify
that code to allow the NVRAM to be updated. I also need a (fairly
simple) bit of code running on a laptop to let me change those tables.

Anyone interested in this?

PG.
----------------------------------------------------------------------------
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