NO WARRANTY. THIS SOFTWARE IS PROVIDED "AS IS". THE AUTHOR DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

NO LIABILITY. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF THE AUTHOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

I HEREBY ABSOLVE THE AUTHOR OF ALL RESPONSIBILITY CONCERNING THE USE AND FITNESS OF THIS SOFTWARE AND TAKE FULL RESPONSIBILITY FOR ALL CONSEQUENCES THEREOF.

USE OF THIS APPLICATION CONSTITUTES ACCEPTANCE OF THE ABOVE CONDITIONS.

Introduction

In the early eighties various car manufacturers around the world began implementing electronic engine control systems in their platforms as part of the quest for better fuel economy and lower emissions. One of the earliest adopters of this new technology was the Chrysler Corporation. Isn't it ironic that if you look around the market today you can find tuning software for almost every make and model of electronically fuel injected car on the market, except the generation of Chrysler cars from 1984-1993?

In previous years, if you made a change to the car that required more fuel, you re-jetted your carbs and moved on. Now fuel delivery is being controlled by a small computer that tells a set of injectors when to open and close in relation to the crank position. How the hell do you add more fuel? Sure, you can put bigger injectors in but then your emissions and fuel economy suffer because the fuel is added across the board not just at WOT where you need it. .

Mopar came out in support of making big horsepower numbers with the "Super 60" kit that featured a specially calibrated computer which controlled 40% bigger injectors. The spec also called for a larger turbo, big-valve head, and high-lift cam (that apparently has durability issues). There are several problems with the kit from the point of view of a street-driven vehicle:

1) Requires 89-compatible electronics or a conversion

2) Requires the complete package to be installed for the calibration to work correctly

3) Does not use oxygen sensor feedback to control fuel at idle, greatly increasing emissions and decreasing fuel economy

4) Requires race gas on the high boost setting

There are a few others, but those are the main points. The complete kit is very expensive and not everyone can afford to drop that kind of coin in one shot. Even if you did, the end result wouldn't be a "well behaved" street vehicle, and driving it there would definitely violate the emissions laws of most states and provinces. On the kind of budgets a lot of us run we can only afford incremental changes every so often and the S60 kit just doesn't work that way.

Some clever racers came up with a better solution: install bigger injectors, turn down the base fuel pressure using an adjustable regulator and alter the fuel curve from a linear one to one with a boost-referenced curve that would increase fuel pressure as needed. This worked very well, and some remarkable times were run at various tracks using this setup.

There are still problems with this setup however. The Adjustable Fuel Pressure Regulator (AFPR) and Rising Rate Regulator (RRR) combination does nothing to address the issue of spark advance. On a low compression motor you might want to increase the spark advance on the low end for more grunt, while you might want to reduce the high-boost advance to stave off detonation. You can adjust the base timing at the distributor (except for T3 motors that using direct ignition), but like installing bigger injectors alone it's kind of an all-or-nothing proposition, your timing change happens across the entire RPM range.

The AFPR and RRR combination is fairly expensive. You need to mount and plumb them in your engine bay, which will certainly cause at least a raised eyebrow when it comes time for the visual component of an emissions test. Dialing them in properly is a time consuming process, and the fuel curve is an approximation at best of the engines actual needs at a given RPM and boost level.

Several vendors of custom calibrations have shown up on the market over the years. The problem is, who do you trust? Horror stories about massive amounts of spark advance causing destroyed motors have been circulating for several years. It's impossible to make a "one size fits all" calibration that will with complete accuracy safely extract the last possible unit of horsepower from a motor. So many variables are in play! The most you can hope for is a calibration that gets 85-90% of the theoretical maximum horsepower out of your combination and doesn't turn your pistons into ashtrays.

Speaking of money... calibrations are expensive too. The people who do it right invest lots of money in dyno time, parts and testing to ensure that their calibrations are accurate, safe and will function properly in a reasonably similar vehicle. That is reflected in the price since like any business they need to recoup their investment and put food on the table. Others are just greedy.

Last thing is the fact that a lot of us are "do it yourselfers". We don't want to hand over a big chunk of change for a mysterious black box, plug and pray that it will work properly to propel our cars to greater speeds and track times. We want to know how it works, get involved in the process and bring every aspect of our vehicle under our control.

A few years ago several like-minded people with diverse skill sets got together to pool their resources and knowledge of just what was going on inside that black box. This package is the end result of a lot of hard work by several key people. A new level of control and flexibility is now available to you that should enable you to plot your own course to making more power.

Intended Audience

D-Cal is written for technology-savvy individuals who are also familiar with setting up and tuning a car. Some basic bits of knowledge you need to have in order to use D-Cal properly:

- Understanding of the hexadecimal numbering system

- Understanding of basic computer concepts like bits, bytes, words, memory addressing, baud rates

- Experience burning EPROMs for embedded systems, socketing circuit boards, basic soldering

- Knowledge of the sensorium in a Chrysler car like MAP, TPS, coolant, oxygen sensors and the feedback they provide the computer

- Experience tuning the fuel and spark curves of a vehicle using an air/fuel gauge, Exhaust Gas Temperature gauge and boost gauge

There will no doubt be many people who will be tempted to use D-Cal without a firm grasp of the above knowledge and I say to that group: don't. Either put off using the program until you can do some research or hire a competent tuner to set up your calibration for you. It's far too easy to blow up your motor by making inappropriate changes to the calibration data. A 5% error on a single point in the fuel table can mean the difference between maximum power and holing your pistons. You should have a full compliment of gauges installed in your car (at least A/F and EGT) in order to determine the effect of the changes you make. Without them you're flying blind and that's total madness.

Getting Started

D-Cal requires a binary calibration file to edit that matches the year and model of your car. It understands straight binary (.BIN) or Motorola S19 formats. There are several ways to obtain the needed file. One is to dump the data out of your stock computer into a binary file by using the Flash section of D-Cal and a serial interface to connect to your car and read it. Another is to desolder the EPROM chip from the ECM, plug it into a chip reader and download it. Yet another is to look around on various web sites and mailing list groups to see if anyone has already done this. Since Chrysler is the copyright owner of the software in your car (you own the car and one copy, not the copyright rights) D-Cal will never come packaged with binary files.

Once you have the appropriate binary file, you also need a matching Table (.TBL) file that tells D-Cal where the important bits are in the binary, and what shape they take. D-Cal will come with a library of these files. It may automatically detect the right TBL for your binary file, or you may have to make a TBL for yourself using the Scan functions and some detective work. Be aware that over the years there were sometimes running changes made to calibrations. There are for example at least two different 89 T2 calibrations, with tables and data in completely different memory locations. A single TBL file will not work for both.

If you can't find a TBL for your application, then you will have to make one. This is a task for advanced users and is not recommended for novices. The best way to go about this is to disassemble the BIN file using a 6811 disassembler and examine the code to determine where the tables are and what they are being used for. The Scan function can greatly speed up this process (see the documentation).

Now that you have the BIN and TBL files, you need some way to get the altered calibration into the car. Again there are a couple of ways you can do this, the simplest is to buy or build an EPROM burner compatible with the type of chip you require for your application. Make the alterations and burn them to the chip. Remove the standard EPROM from the ECM and replace it with a chip socket, into which you plug your newly minted calibration.

Another way is to build a flashable ECM. There are a few recipes floating around on the net that describe how to install an EEPROM where the stock chip would go, and a serial cable is used to connect a standard PC and the ECM. Updates are quick and do not require removing the ECM from the vehicle. D-Cal features full support for this kind of setup!

I strongly suggest you peruse the links in the Resources section and get yourself involved with some of the online groups supporting this hobby. They can provide you with live assistance and technical help in a way that this document cannot.

Dialog Help

Main Page

The main page is the central working area of D-Cal. Other areas are accessed by one of the buttons along the bottom of the dialog. At some point D-Cal will be converted to SDI or MDI format (an example of MDI is Microsoft Word where you can have several documents open at once, with a background page that has the "File, Edit, View" menu entries). It originally started out as a simple dialog-based utility I wrote for use on my low-end laptop. It just kinda grew from there. :)

Starting on the left, the area "Table/Constant List" shows all of the data definitions imported from the TBL file. Each one represents a memory location in the cal and defines what kind of data is there, what it's ranges are, what units etc. More on that later in the Properties section. As you click on or scroll through the list, the graph window on the right will change to reflect the type of data and values that table entry represents.

There are three radio buttons under the table list that select how the list should be sorted. Sorting by Name, Address and Type are supported, each useful for different things. Sorting a list by Address is probably the most useful and is the default.

Just under the buttons is a small status window that lists the hex offset of the table and the data type.

Immediately below that is a checkbox titled "Disable Editing Binary". With this box checked (the default) you cannot make any changes to the data points shown in the graph window. This is a safety feature that guards against inadvertently moving a point. Sometimes while dealing with multiple copies of D-Cal it can be easy to do this. Uncheck the box before making any changes to data points and re-enable it when done.

Dominating the screen is the graph window. This area interprets into human-recognizable terms the binary data found at the table entry and allows editing.

For line graphs, each data point (commonly called a "breakpoint" in the tuning industry) is represented by a small white square. The point can be grabbed with the mouse and moved around in either axis. You will notice that sometimes the movement is restricted, for instance you can't move a point farther left than the previous point. This is intentional and is done to keep you from generating invalid table data.

The point you are currently editing is outlined in red. When any point is showing this color, it means the graph window has "focus". You may also use the keyboard to edit the point, using the four arrow keys Up, Down, Left and Right. To move between points, use the PageUp and PageDown keys. The X-axis runs left to right, and the Y axis runs bottom to top. To move around the various buttons and windows you can use the Tab and Shift-Tab key combinations. Spacebar activates the current button.

Editing with the keyboard allows you to have more precise control over the data being edited. The arrow keys increment the X/Y values one "binary unit" at a time, which is the highest precision for editing you can get.

On 16-bit line graphs the last point of the line is actually a "phantom point" that is used to allow editing the slope of the last line. This point has slightly different behavior than the others in that it cannot be moved in the X axis, and will move in the Y-axis when you move the second-last point up and down. This is normal.

On screens where the data is a bitfield or value array, the number keys 0-7 can be used to toggle the fields in addition to the mouse pointer.

Just under the bottom left corner of the graph window is the Mouse data area. This window shows what graph value the mouse is pointing at in realtime. When comparing two calibrations that may have breakpoints in different positions you can find the line value for a given axis value by moving the mouse until that value is lined up, then moving the pointer up or down until the tip intersects the line. The value displayed in the Mouse window is what the computer with interpolate from that line graph. When editing points with the keyboard, the value of the current point being edited is displayed in the Mouse box.

To the right of the Mouse box is the Description window. The description entered from the Properties window is displayed here for convenient reference while browsing up and down in the table list. Important information about the limits of the data or conditions for its use should be displayed here.

Load

D-Cal can read calibrations in either binary format (.BIN) or Motorola S19 files. The S19 files have a slight advantage in that they carry the memory data as well as the address information.

At load time, a Table (.TBL) file is looked for with the same name as the BIN/S19 file. If none is found, you will be asked for some information about the calibration. See the Cal Data section for a description of the fields.

Save

When unsaved changes are pending, the application title will have an asterisk (*) appended to it. The two disabled check boxes "Save Tables" and "Save Binary" on the dialog are there strictly for information purposes, and they represent the internal flags for which data types will be saved. Changes made to the binary and the table data are tracked separately and written to disk only as necessary. This avoids unnecessary resetting of the file date.

Both binary and S19 versions of the file will be saved. This avoids having to use an external utility to change formats for use with other utilities. This feature may be dropped in the future in favor of simply saving whatever format the file was loaded with. For now it stays.

You may edit the name of the file to be saved if you wish, this is equivalent to doing a "Save As" in most windows applications. The filename MUST contain either of the extensions ".BIN" or ".S19" to be valid and accepted. It allows you to make several incremental changes to a baseline calibration and save them separately. Changing the name will cause both of the grayed out check boxes to light, indicating that it will make copies of both the binary and table data. *** Please note that using the same name as an existing file will overwrite that file.

Checking "Make Current Edit" will have D-Cal change the name of the currently edited calibration to the one entered in the text box. If you don't change the file name, this check box has no effect.

Options

This panel contains the global options for the application. At this time there are only two:

Reload Last Edited - When the application opens, the last calibration you were working on is reloaded. Useful when you work for extended periods with a single calibration.

Hide Mouse Pointer - When the application starts, the mouse pointer is hidden from view. This was added because the mouse on my craptop doesn't work. When D-Cal loads the mouse pointer is left sitting right in the middle of the graph window - annoying. When you quit, the mouse pointer is restored.

Comparison Calibration - You can load a second calibration in the background to compare the table data (signed, unsigned and 16-bit only) to the current file. When the graphics system displays a table, if one with the same name is found in the comparison calibration, it is drawn in dark gray underneath the first. The word "SECONDARY" also appears in the upper left-hand corner of the graph to let you know when it is displaying two tables in case the data points are identical and the comparison table is obscured.

In case you are comparing two calibrations that use different units (e.g. a 2 bar cal vs. a 3 bar is the most common situation), the data from the comparison calibration is converted into the coordinate space of the editing calibration for accurate visual comparisons. This is usually indicated by the gray comparison line going off the side of the graph as in the above screenshot, or stopping short somewhere in the middle.

Flash

The Flash utility is the area where serial communications with a flashable ECM are carried out. There are several recipes available on the net for converting a standard ECM with an EPROM to use an EEPROM that can be programmed by the CPU when put in the right mode.

The process involves putting 12 volts to one of the pins on the Motorola 6803 or 6811 processor that will put it into a special "bootstrap" mode when powered on. This mode allows the CPU to receive via the built-in serial communications port a small program that is downloaded by D-Cal (originally written by Chad Clendening) into the CPU's memory space. This program is then able to receive further instructions from the PC - it can read the ROM data and send it out, or receive new data and burn it into the EEPROM if the write line on the EEPROM chip is enabled (usually the bootstrap mode and write mode lines are tied together on a single toggle switch when the ECM is made flashable).

The connection between ECM and PC requires a serial interface. The schematic for this is also available on the net and is built around the commonly available MAX232 chip. Occasionally people offer these interfaces up for sale as a kit. Sign up with a news group from the Resources section to get in on these deals.

Communication happens primarily at 9600 baud. Because the baud rate is a function of the clock rate of the ECM, SMECs have some trouble getting a baud rate that a PC can understand. The actual baud rate the ECM is programmed for when bootloading is 9615 baud. Close enough to the PC's 9600 baud, but sometimes errors in transmission do occur. Because of this, there are several verification tools employed by D-Cal to ensure that the cal you have loaded is reliably burned to the ECM's EEPROM and I suggest you make use of them until you have a feel for the quality of the connection between your PC and ECM. Dropping a couple of bytes in the middle of a fuel table would be very, very bad.

ECM Type - Select the type of ECM you are communicating with. This controls which bootloader is used, baud rate, memory address, etc. Currently only SMEC flashing is supported by LM is in the works, and I simply need a test vehicle for SBECs.

Serial Port - Select the COM port the serial cable is connected to. On most PCs the 9 pin serial port is COM1, however check your machine specs to be sure.

Read - Used to read out the ROM memory of an ECM. This mode can be used to access the stock program in your ECM and make it into a calibration file. When using this mode, any calibration loaded will be wiped, and there is a warning dialog to this effect before communications begins. The address and length of memory read from the module is controlled by the ECM Type selection. LMs and SMECs have ROM from C000 to FFFF, and SBECs from A000 to FFFF.

Full Write - Completely overwrites the ROM with the calibration data. When a new calibration is loaded, or D-Cal has not performed a flash operation before, this will be the only write option. This is to ensure that what is burned in the ECM is in sync with what is in memory. It's still possible to get them out of sync, so be careful and only run one copy of D-Cal at a time while flashing.

Differential Write - A copy of what was burned to the ECM last is retained on the local disk. When Differential Write is used, this copy is loaded and compared to the current binary data. Bytes that have been changed are burned individually to the ECM. While tuning only a few tables, this mode is a huge time saver since flash time is greatly reduced.

Verify - After a write operation, the complete calibration is read back from the ECM and compared to the one loaded in memory. An error is generated if there is a mismatch, otherwise no dialog appears. This operation is useful to ensure that no bytes were dropped during the burn process that might cause the ECM to malfunction.

The flash operation selected will begin when OK is selected. At the end of every write operation, a quick checksum is performed on both the PC and the ECM sides to ensure that the data matches. An error dialog will come up if there is a mismatch, and a re-burn is recommended with the Verify option checked. Check your serial connection and make sure your OSs serial drivers are up to date and functioning properly.

A word about OS issues. I was unable to get my laptop to flash my ECM while running the original Windows 95. In desperation I upgraded to Windows 98 and suddenly flashing was working perfectly. This clearly shows that OS can be an issue, and I suggest that if you are having problems getting flashing to work that you look there after making sure that your serial cable is functioning properly. Do not run any applications in the background that might hinder communications or take up CPU time, such as a virus scanner.

Cal Data

This area describes the properties of the calibration as a whole. Most of there data was initially put there for compatibility with ChEM TBL files.

Description - A line of text that describes the origin of the calibration. The model year, engine type (T1, T2, T3, T4), ECM type (LM/SMEC/SBEC), part number from the top of the stock EPROM are all good things to write into this field for future reference.

Author Name - The person who has created this calibration. The default is "D-Cal" of course, but you can insert your own name if you wish.

Base Address - The address in ECM memory that the first byte of the calibration resides at. This number is in hex.

Injector Size - The rating of the injectors used with this calibration. The value is "pounds per hour" of fuel flowed at 55psi.

Max Boost - The maximum boost this calibration will allow, value in psi. It is not calculated from the binary file, it must be updated by the author if the tables are altered.

Checksum - On startup, all ECMs perform a self-diagnostic where they add up the numeric value of all bytes in the ROM and compare the result against a special byte. If this test fails, the result is a code 53. Very annoying. D-Cal can automatically recalculate and correct this checksum before saving if you have made changes to the table data of the calibration that would normally cause this error.

Checksum Address is the offset in ECM memory that the special comparison byte resides at.

Fixup Address is the address of an unused byte of the calibration. The value of this byte is altered to make the sum of all of the other bytes equal to the checksum byte.

A note about the checksum adjustment: make very sure that the addresses you provide D-Cal are exactly as described above (especially the unused one!). Providing incorrect memory addresses can cause the calibration to become corrupted! You might whack a single byte of a table and never know it until you go to WOT and the temperature of the engine is less than 140F. Then again, the car may just crash when you power it up. If these values are not set in the TBL file, disassemble the calibration and find the appropriate locations or ask around to find someone who has. This is very important if you intend to use this convenient feature. How many people shell out big bucks for a calibration and have to drive around with code 53 all the time? Explain that to the dealership.

MAP Type - The type of MAP sensor used with this calibration. Stock turbo MAP sensors are 2 bar units that can read from 30" of vacuum to 14.7psi of boost. The S60 kit uses a 3 bar map sensor that allows the computer to see up to 29.4psi of boost. It's vitally important to match the MAP sensor and the calibration for proper operation. The MAP type is not calculated from the binary, and needs to be maintained by the author.

Binary

The Binary option allows you to view the data in one of two modes: a table view such as the image on the left, with X and Y values being printed in their literal hex format as well as being translated into real-world numbers using the axis min/max information. There is also available a raw hex dump view that is useful for people who understand what the data should look like in memory. Sometimes it is a great help in determining whether a table has been identified correctly. No editing is possible in either display.

If you have loaded a comparison calibration, and there is a match for the current table, you can switch between displaying the Primary (the one you're currently editing) and the Secondary by clicking the bottom-most button (initially marked "Secondary" when you open the dialog). The title of the window indicates which table you are looking at. If there is no match or you don't have a second calibration loaded, this button is grayed out.

Scan

The Scan function attempts to automatically identify data tables in the binary. It does this by looking for a specific assembly command: LDX #<value 16>. Typically calibrations use this instruction to load the offset of a data table just prior to doing a lookup. It is acknowledged that this method is not perfect, and will not discover all of the references to important data structures, especially constants or the few one-off data structures that are not widely used. It is very effective however at quickly locating the majority of the important tables.

When a hit on this assembly command is found, a heuristic is run on the data at the address referenced in an attempt to identify which type of table it is. The heuristic is pretty good, but isn't perfect. If it fails to identify the data type, it will default to "Unknown Type".

The Scan function will not duplicate, delete or modify a data entry that already exists. Some garbage tables that were previously deleted may be re-added.

Some garbage tables will always be created. They will be fairly easy to spot: no visible lines, lines crazy all over the place, values see-sawing up and down, etc. First thing to try is changing the data type to see if it will make more sense. If not, you can delete them from the list, or leave them for later identification. The heuristic is actually pretty good and can usually identify a table, so unknowns may be 8 or 16 bit constants that are tough for it to pick out because of a lack of information.

The heuristic often gets the Unsigned 8-bit and Signed 8-Bit table types mixed up. Sometimes you can tell by looking at the graph, but it may be necessary to examine a disassembly. Typically spark advance and AIS tables are signed, a couple of the boost-related tables are signed, the rest are unsigned. These are only generalities not hard fast rules.

The Scan function is not intended to plot every single table and constant for you. It is simply an aid to quickly identifying some of the data structures. In order to plot every single data structure automatically, something like a full threading disassembler would need to be implemented. While that is not out of the realm of possibility, the time resources to do so are better applied to other parts of the program right now. People who are able to disassemble binaries and read assembly code shouldn't have any problems manually building TBL files to serve their purposes. Hopefully those files will be shared with other D-Cal users.

Scan can also cross-identify the tables in one unknown calibration with the known data from another calibration. The Browse button brings up a dialog that you use to locate the second calibration binary/S19. A matching TBL file must exist with the same filename in the same directory. A standard scan is performed on the unknown calibration, then a second heuristic is used to try and match the tables from the known cal to the unknown tables. A best-fit algorithm is used that considers factors such as table type, offset in the file, number of data points, and max deviation between the curves.

The slider at the bottom can be used to control how closely a table must match before it is considered a good fit. The far left is a 50% cut-off, which is the default. When comparing calibrations that are very similar (ie same model year) this is probably sufficient. With cals of very different years or types (86 vs 89 or V6 vs T2) the slider should probably be increased towards 100% to cut down on the number of bogus tables generated.

Scale

The scale dialog allows you to make bulk changes to the points of a table. It has three basic functions: scaling, flattening (setting all points to the same value) and adding a value.

Scaling input is always expressed as a percentage. The existing data can either be shrunk (by giving a value less than 100%) or expanded (greater than 100%). Performing multiple scales on the same data is not a good idea. Rounding error will slowly distort the relative positions of the points, especially when dealing with 8-bit tables. This can be used to modify fuel tables to account for changing the size of the injectors, scaling MAP tables, etc.

Flattening will set all points of the table to the same value. Input is in whatever Y-axis units the table currently has defined, and the label after the input box will reflect that. This operation is usually useful for setting a table to all zeros to eliminate its contribution while trying to figure out how some aspect of a calibration works.

Adding simply adds some value to all points of the graph. As with flattening, unit type comes from the Y-axis of the graph.

Properties

The Properties panel allows you to edit the parameters of a table entry. You must double-click on an entry in the list of tables to bring up this dialog.

Name - The name of the data entry. Try to use a consistent naming scheme. I prefix all constants with "Const", and tables with their output type such as "Fuel" or "Advance". Don't make the name too long because the table entry list is only so wide and it may get truncated making it hard to read.

Chrysler Name - This is a ChEM compatibility field.

Hex Address - The offset into the calibration for this piece of data. This is always a four-digit hexadecimal value.

Graph Properties - Various parameters used to graph the contents of the data.

Quick Set - Click on the drop-down menu and select an entry to quickly fill in the parameters for the X or Y axis.

X-Axis/Y-Axis - The horizontal (left - right) axis is considered X, the vertical (bottom - top) is Y.

Name - The parameter name. Examples: MAP Sensor, Spark Advance, Pulsewidth.

Unit - The abbreviation for the unit of measure expressed by the axis. Examples: ms, V, deg.

Min/Max - Defines the range of the axis value. Most sensors area dealt with by the computer using a 0-255 binary value, but in order to translate the value into human terms the Min/Max units are used. Example: a 2 bar map sensor will measure from -14.7psi of vacuum (absolute zero) min to 14.7psi of positive pressure max.

Description (unlabelled) - The text description that will be printed underneath the graph window when the table is selected. This area should include a brief description of how the table is used by the ECM, any special circumstances under which it may behave differently, and any pertinent warnings or instructions about modifying the value.

Next/Prev - Allow you to advance to the next or previous table in the table list for easy sequential scanning.

Data Type - Selects what type of data structure this entry represents.

Tables

Unsigned 8-Bit - First byte is the number of entries in the table, the rest is a four-byte pattern of 8-bit X, Y, 16-bit slope. The Y value is unsigned. The last entry does not have a slope.

Unsigned 16-Bit - There is no count byte, the table is terminated by an X value of $FF. Entries are a five-byte pattern of 8-bit X, 16-bit unsigned Y, 16-bit unsigned slope.

Signed 8-Bit - Same as Unsigned 8-Bit except that the Y byte is a signed value (-128 to 127).

3D Table - Used in SBEC only. First two bytes are the table width and height, third byte indicates whether the data is signed (value of $FF) or unsigned (value of $00).

The rest is width x height bytes of data. ECM will do a triple interpolation to extract a value. Inputs to the table are two 0-255 values.

Constants

Unsigned 8-Bit - A single unsigned byte value. This is also the default for a table that the Scan heuristic cannot properly identify.

Unsigned 16-Bit - Two bytes in Motorola order, high byte first then low byte.

8-Bit Flag Byte - A byte whose individual bits represent an on/off flag, usually denoting an installed piece of equipment.

8-Bit Value List - A list of values that can be swapped into the bytes location. Used for doing and undoing baud mods at certain locations in the code, among other things.

Unknown - Tables that were found by Scan but could not be positively identified are labeled as this type until the user can manually identify them.

Define Fields - When either a Flag or Value list type is chosen, this button becomes active. It opens another dialog that allows you to enter text and/or a value for the eight fields of either type.

New

Creates a new table entry. The properties dialog will be shown and the information filled in. You cannot create an entry with exactly the same name as another entry (case is not important) and you cannot create an entry that has the same Hex Address. Clicking OK adds the table entry to the list, Cancel aborts the operation.

Delete

Removes the currently selected table entry in the Table/Constant List. Make sure you have the right table selected!

TBL Library

If a TBL file is not found in the directory with the binary when loading a calibration, D-Cal will attempt to locate one for you using the Library. The Library consists of many TBL files that have been previously identified and populated and are shipped with D-Cal. These are NOT calibrations, they are simply descriptions of what is where in a calibration of that type.

The Library files are matched up to a binary through the use of a CRC32 checksum created using the unknown binary file. This checksum is then compared one by one to the checksums in the TBL files of the Library, and if any are a match you will be asked if you want to load the library copy. If you answer yes, the TBL will be copied to the directory with your binary file, using the same filename except for the extension. After this any changes you make will be saved into the local TBL file.

Never modify Library files unless you know what you are doing! Any contributions you have to the Library will be gratefully accepted by the author for verification and inclusion in future releases. Please be sure to include a brief note on what changes you've made to the stock TBL files, and what you've added. The main interest here is in documenting the stock calibrations, not custom ones.

Resources

My homepage is where you can find the latest version of D-Cal and any other related utilities I publish, as well as some general automotive information and what projects I am currently working on.

http://members.rogers.com/derek.beland/

Newsgroup for users of D-Cal to help each other, be advised of new releases and share ideas.

http://autos.groups.yahoo.com/group/D-Cal/

The Mopar ECM Yahoo group is a group of people with the skills and background required to contribute to the knowledge pool about the computers that are the brains of our cars. It's a closed group but if you feel you have something to contribute you can apply for membership.
http://groups.yahoo.com/group/Mopar_ECM/

One of the pieces of software to come out of this effort is an editor and data-logger called ChEM, written by Geoff Allen. There is a Yahoo support group for that program where you can get the latest version and discuss ECM hacking in general. As far as I know, membership is open to anyone.
http://autos.groups.yahoo.com/group/Mopar_ChEM/

Geoff Allen's homepage, where there is more info on CHeM and ECMs in general.
http://www.roundededge.com/cip/ShelbyZ.html

Gary Donovan has a page on the basics of fuel injection for turbo cars:
http://www.thedodgegarage.com/turbo_pfi.html

Also an advanced page that talks about calibrations and actually has some of the binary files for download.
http://www.thedodgegarage.com/turbo_pfi_advanced.html

Dave Berken advertises ECM socketing, EPROM burning, used computers and custom calibrations. I have not used Dave's services personally, but if you have drop me a line.
http://www.geocities.com/berksglh/

The heart of an SMEC or SBEC computer is a Motorola 6811 processor. Earlier cars (LM) used the 6803 processor. These chips are one small step above the processors in the Commodore 64 or Apple II personal computers. Here are some links to technical documents about this processor and it's hardware/software environment. I provide multiple links because from time to time these files disappear.

68HC11 Reference Manual, Rev 6, 6.2M
Link 1: http://merchant.hibbertco.com/fs22/deact/fs22/pdf-docs/motorola/m68hc11rm.rev6.pdf
Link 2: http://cegt201.bradley.edu/~don/EE566DataSheets2/M68HC11RM.pdf

68HC11A8 Technical Data, 3.8M
Link 1: http://merchant.hibbertco.com/fs22/deact/fs12/motorola/MC68HC11A8TS_REV0.PDF
Link 2: http://e-www.motorola.com/brdata/PDFDB/docs/MC68HC11A8TS.pdf
Link 3: http://www.egr.uh.edu/courses/Ece4436/support/68HC11/MC68HC11A8TS.pdf

68HC11 Programming Reference Guide, Rev 1, 4.6M
Link 1: http://merchant.hibbertco.com/fs22/deact/fs22/pdf-docs/motorola/mc68hc11a8rg.rev1.pdf
Link 2: http://e-www.motorola.com/brdata/PDFDB/docs/MC68HC11A8RG.pdf
Link 3: http://www.egr.uh.edu/courses/Ece4436/support/68HC11/MC68HC11A8RG.pdf

68HC11A8 HCMOS Single-Chip Microcontroller, 770K
Link 1: http://e-www.motorola.com/brdata/PDFDB/docs/MC68HC11A8TS.pdf
Link 2: http://www.egr.uh.edu/courses/Ece4436/support/68HC11/MC68HC11A8.pdf

68HC11 Config Register Programming, 402K
http://merchant.hibbertco.com/fs22/deact/fs11/motorola/M68HC11CFG_REV1.PDF