As I said above, I just figured out the first chunk of the file, which is an array of (x+1).(y+1) floats.
I released my source code in the zip. Just download it and have a look at the algorithm. It's the best "documentation" you can get. But there really isn't more than what I said: a replacement of each float in the chunk by a new height value. The range (in meters) between the lowest and the highest point can be defined in the tool. If you want small hills, put the height of the white pixels to 20 meters (that's the default value). If you want larger mountains, put it to 200 meters.
The reason for the "+1":
DOS terrains are made of rigid tiles, each tile being rendered on screen by 4 coplanar quads (2x2). You can choose a different texture per quad which makes a smooth blend of 4 textures on each tile, but you can only choose the height of the tile borders (so, once every other quad). When you define the size of the map in the engine, you choose the number of quads / textures. And the number of tiles is half that. The heights that are stored in the data file are the heights of the vertices between tiles, not the tiles themselves. So if you choose a terrain of 1000x1000 in the editor, it is made of 500x500 tiles and those tiles have 501 borders (499 being shared between 2 tiles and 2 being the map borders).
If you're still not convinced, take a chess board. It's made of 8x8 squares and from one border to the other, you have 9 lines. That's a total of 81 intersections (9x9).
