WinOLS Guide (2/10): Finding Maps — Damos, A2L, Mappacks & Manual Search

When you open an ECU binary file in WinOLS, every byte on screen carries equal weight. There are no labels, no headers, no XML tags to guide you. The file is a flat image of the microcontroller’s flash memory — a single, unbroken stream of bytes that mixes executable machine code with calibration data. The skill that separates competent tuners from beginners is the ability to find and identify maps inside that stream. This guide explains what maps actually are at a technical level, then walks through every method WinOLS offers to locate them — from automated Damos imports all the way down to scrolling through raw hex by hand.

What Exactly Is a Map?

At the hardware level, a map is a lookup table stored as a flat array of bytes in the ECU’s flash memory. The ECU’s firmware reads sensor inputs (RPM, load, temperature, pressure), uses those values to index into the array, and retrieves a calibration value that it plugs into a control equation. A one-dimensional map (often called a curve) is a single row of values indexed by one input. A two-dimensional map (a surface) is a rectangular grid indexed by two inputs — for example, RPM along one axis and load along the other. The ECU interpolates between breakpoints when the real sensor value falls between two stored axis entries.

Crucially, flash memory stores these arrays with no metadata attached. The map’s name, dimensions, axis labels, units, and scaling formula all exist only in the firmware source code and the OEM’s development tools — none of that information is written into the binary. This is precisely why finding maps is the hardest skill in WinOLS: you are looking at raw bytes and must infer structure from patterns alone.

Damos Files: The Architect’s Blueprint

A Damos file (from the German Datensatz-Management-System) is a proprietary calibration development file created by ECU manufacturers such as Bosch, Continental, or Siemens. During ECU development, the OEM’s calibration engineers use these files inside tools like Bosch INCA to read and write every tuneable parameter in the firmware. A Damos file typically contains:

• Every map name in the calibration — often hundreds of entries, using the OEM’s internal naming convention (e.g., KF_MDMAX_ES for the engine torque limiter)
• Memory addresses — exact byte offsets where each map’s data begins
• Dimensions — the number of rows and columns for each map
• Axis definitions — what physical quantity each axis represents, with breakpoint values
• Units and scaling formulas — how to convert raw byte values into engineering units (e.g., raw value × 0.01 = boost pressure in bar)
• Data type information — whether the values are 8-bit, 16-bit, signed, unsigned, or floating-point

Importing a Damos is like receiving the architect’s blueprint for a building you previously could only see from outside. Instantly, hundreds of anonymous data regions become named, scaled, fully defined maps. You import a Damos in WinOLS via File → Import → A2L/Damos. WinOLS parses the file, maps each definition to the corresponding address in your binary, and populates your project’s map list.

The challenge is obtaining Damos files. They are confidential OEM engineering documents, never officially sold or distributed to the aftermarket. The files that circulate in the tuning world were leaked from OEM development departments or calibration tool databases over the years. For many newer ECU types, no Damos exists outside the manufacturer. When one is available for your exact software version, it is the single most valuable resource you can have.

A2L Files: The Standardised Alternative

An A2L file follows the ASAM MCD-2 MC standard (formerly known as ASAP2), an industry-wide format defined by the Association for Standardisation of Automation and Measuring Systems. A2L files serve the same purpose as Damos files but use a standardised, text-based syntax that any compliant calibration tool can read. During OEM development, engineers use A2L files with tools such as INCA and CANape to calibrate and measure ECU parameters on test benches and in prototype vehicles.

Inside an A2L file you will find several key record types:

• CHARACTERISTIC — defines a calibration parameter (a map, curve, value array, or single scalar). Each entry includes the address, dimensions, axis references, and display format.
• MEASUREMENT — defines a live measurement channel (e.g., actual boost pressure, actual RPM). These are not maps but real-time values the ECU computes at runtime.
• COMPU_METHOD — defines the mathematical formula to convert a raw stored value into a physical unit. For example, RAT_FUNC with coefficients that turn a 16-bit integer into milligrams per stroke.
• AXIS_PTS — defines shared axis breakpoint arrays that multiple maps can reference.

You import an A2L file in WinOLS through the same path: File → Import → A2L/Damos. The result is identical to a Damos import — your project gains a complete set of named, scaled, dimensioned maps. Like Damos files, A2L files are extremely difficult to obtain because they originate from OEM development environments that are not accessible to the public.

Mappacks: Community-Created Map Definitions

A mappack is a WinOLS-specific file that contains a collection of map definitions created by a tuner rather than an OEM. A tuner who has spent hours (or days) manually identifying maps in a particular ECU type can export those definitions as a mappack and share or sell them so that others do not have to repeat the work. Mappacks are imported in WinOLS via File → Import → Mappack.

Mappacks contain only map structure information: the map name, the starting address, the number of rows and columns, the data type, and basic axis configuration. They do not contain scaling formulas, physical units, or the comprehensive coverage that a Damos provides. A typical mappack for a common diesel ECU might define 30–50 tuning-relevant maps, whereas a Damos for the same ECU could define 500 or more parameters including diagnostic thresholds, sensor calibrations, and internal software constants that a tuner would never touch.

Damos/A2L vs. Mappacks: Key Differences

Because mappack quality depends entirely on the skill of the person who created it, you must always verify a mappack after importing it. An incorrectly defined map — pointing to the wrong address or with the wrong dimensions — is more dangerous than having no definition at all, because you could unknowingly edit the wrong data.

Manual Map Finding — The Core Skill

When no Damos, A2L, or mappack is available for your ECU, you must find maps yourself. This is the most time-consuming method but also the most educational. Every experienced tuner has spent hundreds of hours scrolling through binary files, and the pattern recognition you develop becomes intuitive over time.

Step 1: Set the Correct Data Width and Byte Order

Before you begin scanning, configure WinOLS to interpret the raw bytes correctly. Most modern ECUs (EDC16, EDC17, MED9, MED17, Simos, and similar) store map values as 16-bit (2-byte) words. Set WinOLS to 16-bit display mode. Next, set the byte order. Bosch ECUs built on the Infineon Tricore platform use HiLo (big-endian) byte order, meaning the most significant byte comes first. Siemens/Continental ECUs often use LoHi (little-endian). If the data looks like random noise in one byte order, switch to the other — the correct setting makes structured data immediately visible.

Step 2: Scan in 2D View

Switch to the 2D graph view and slowly scroll through the entire binary. In this view WinOLS plots consecutive data values as a line graph. The executable code sections of the binary appear as chaotic, high-frequency noise with no discernible pattern. Calibration maps, by contrast, appear as smooth, structured shapes: gentle curves, clean staircases, ramps that rise and plateau, or flat lines. When you see a smooth region emerge from the noise, you have found a candidate map.

Step 3: Recognise Visual Patterns

With practice, common maps develop recognisable visual signatures in the 2D view:

• Boost pressure target — a curve that rises steeply in the low-to-mid RPM range and then levels off into a plateau, reflecting how the turbocharger reaches its maximum output
• Injection quantity map — a structured staircase pattern with distinct steps at each load breakpoint, increasing as load increases
• Torque limiter — a relatively flat line that drops off sharply at high RPM, reflecting the engine’s declining volumetric efficiency near the rev limit
• Temperature compensation — a smooth S-curve that transitions between two value ranges, reflecting how the ECU adjusts a parameter as coolant or intake temperature changes
• RPM axis data — a clean, linearly rising line (e.g., 500, 1000, 1500, 2000 … 6000), easy to spot because breakpoints are evenly or semi-evenly spaced

Step 4: Use the Hex View for Fine Detail

Once you have identified a candidate region in 2D view, switch to the hex view to examine it at byte level. In hex view, maps appear as rectangular blocks of similar values. Axis data (RPM or load breakpoints) appears as a series of incrementing values — easy to spot because each successive word is slightly larger than the previous one. The space between maps is typically filled with 0x00 or 0xFF padding bytes, which acts as visual whitespace separating one data structure from the next.

Step 5: Set the Correct Column Width

This is a critical and often overlooked step. In hex view, change the number of display columns so that it matches the map’s row width. When the column count is correct, the map appears as a clean, aligned rectangle — each row of the map occupies exactly one display row. When the column count is wrong, the map’s data wraps incorrectly and looks like diagonal stripes or meaningless noise. Common column widths to try are 16, 17, 18, and 20 — these correspond to typical axis sizes in popular ECU families. Adjust the width until the rectangular structure snaps into focus.

Step 6: Mark and Define the Map

Once you have confirmed a map’s boundaries, press M to mark the start address and W to mark the end address. Then open the map properties dialog to set the dimensions (rows × columns), the data type (8-bit, 16-bit, signed or unsigned), and the axis type (whether axes are stored inline before the map data or referenced from a separate address). Give the map a clear, descriptive name following a consistent convention — for example, Boost_Pressure_Target or IQ_Limiter_Smoke. Consistent naming pays off enormously as your project grows to dozens of identified maps.

Using File Comparison to Find Maps

One of the most effective shortcuts for finding tuning-relevant maps is to open two versions of the same file — a stock original and a known tuned version — and use WinOLS’s comparison feature to highlight differences. Every address range that differs between the two files is almost certainly a map that the tuner modified. This will not tell you the map’s name or function, but it immediately narrows your search from an entire megabyte binary down to a handful of specific regions. From there, you can analyse each changed region to determine what it controls based on its values, axes, and shape.

Verifying Maps After Any Import Method

Regardless of whether you used a Damos, A2L, mappack, or manual identification, always verify every map before you edit it. Verification is a non-negotiable step:

• RPM axes should show realistic values — typically 0 to 7000 or 8000 for a passenger car diesel. If an RPM axis displays values like 53291 or 2, the definition does not match your binary.
• Load or pressure axes should fall within physically plausible ranges — 0–2500 mg/stroke for injection quantity axes, 0–3000 mbar for boost axes, 0–100% for pedal position axes.
• Map values should not be all zeros (0) or all maximum (65535 for 16-bit). A map full of 65535 likely means the address is wrong and you are reading empty flash memory.
• 3D surface shape should be smooth and physically plausible. A boost target map should form a coherent rising surface, not random spikes. A torque limiter should be a relatively flat plane, not chaotic terrain.
• Cross-reference against known good values from OEM specifications, community data, or published tuning results for your ECU type. If the community consensus for a stock 2.0 TDI torque limiter is around 320–340 Nm and your map shows 47 Nm or 9000 Nm, something is wrong with the definition.

Taking ten minutes to verify saves hours of troubleshooting a tune that was built on incorrectly identified maps.

Next in the Series

WinOLS Guide (3/10): Diesel Engine Tuning — Maps, Strategy & Practical Editing takes everything you’ve learned about finding maps and applies it to real diesel ECU calibrations. We’ll walk through the complete torque-based control strategy, identify every map you’ll edit for a Stage 1 tune, and explain what safe modifications look like in practice. Stay tuned.

If you don’t have the time or expertise to tune files yourself, upload your original ECU file to fileservice24.at and receive your professionally modified file in about 60 seconds.