Introduction

Winter time is retro computing time. This year I got myself an Profi-5E Mikrocomputer. It’s an 8085 based computer used for educational purposes. About 30 years ago I did learn machine code programing on a similar 8085 based Mikrocomputer für Ausbildung (MFA computer). Therefore the Profi-5E looked like an interesting system to play with. Especially since it can be found on ebay for a few Euro.

Typing in programs on the hex keypad got old pretty quickly. So a way to upload binary code to the system was desired to be able to do cross-development with a cross-assembler like a85. The documentation does not have any information how that could be done with the default monitor ROM. So some reverse engineering was needed.

Profi-5E Overview

There is a Wikipedia page about the Profi-5E with some basic information. Also, there is still printed documentation available from EPV Verlag. That includes schematics and programming instructions.

A few technical details:

• CPU: 8085A
• RAM: up to 6 kB
• ROM: 8 KB monitor EPROM + additional socket
• I/O: 8255 (two of three free for user)

Available Input/Output Options

The Profi-5E has a small keypad for machine code entry and control. For output there is an 8 digit LED display. Solder bridges allow to configure memory size and type. Other settings like serial speed are done with DIP-Switches. An EEPROM contains a monitor program to interact with the system. The monitor program allows reading and writing of memory as well as starting programs.

There is an audio interface for storing and loading programs to/from a cassete deck. The signal level is a little low for -10 dbV equipment, but storing and loading works fine with an old cassette deck using a RCA connector cable and an adapter for the DIN connector.

There is also a V.24 serial port using a 25 pin D-SUB connector. The serial port can be operated at the amazing speed of 300 Baud up to 2400 Baud. The interface uses -4V and +4V levels. It can be connected to a standard FTDI-USB-serial converter (please note: that excludes the 5V or 3.2V TTL-level USB-serial converters). The cabling has to ensure that receive readiness is signaled on pin 5, or DIP-Switch 5 has to be switched to OFF. Fortunately I found a chain of adapters that converts from 25 pin to 9 pin D-SUB and connects pin 5 of the Profi-5E output to pin 1 on the USB-serial device.

There is a documented “F-8”-function (started by pressing F-8-G) that allows reading ASCII text into memory from the serial port. This looks promising for the desired goal of cross-development. But to find out whether it can be misused for binary, the monitor ROM has to be further analyzed.

Monitor ROM Analysis with Ghidra

To get the monitor ROM in binary form, one can always use an EPROM reader. That was unavailable, but there is another way. The “F-6” function allows to dump memory to the serial port. With some scripting this can be converted back into binary and loaded into Ghidra without problems. Ghidra does support 8085 code out of the box.

The Profi-5E documentation contains several useful functions with entry points. It helps to locate these functions and give them proper names in Ghidra. Following the cross-references of the serial port functions, you will find the “F-8” implementation at 0x04B6.

**************************************************************
*                          FUNCTION                          *
**************************************************************
                     undefined SYS_F8_ASCII_IN(void)
     undefined         A:1            <RETURN>
                     SYS_F8_ASCII_IN
ram:04b6 21 77 77        LXI        HL,0x7777
ram:04b9 cd 07 07        CALL       HEXIN
ram:04bc 22 ac 87        SHLD       (DAT_ram_87ac)
ram:04bf 21 00 87        LXI        HL,0x8700
ram:04c2 22 ae 87        SHLD       (DAT_ram_87ae)
ram:04c5 cd 6b 05        CALL       BAUD
ram:04c8 cd 80 03        CALL       DUNKL
                     sys_f8_loop_next_character
ram:04cb cd f1 04        CALL       ASCII
ram:04ce 2a ac 87        LHLD       (DAT_ram_87ac)
ram:04d1 77              MOV        (HL=>DAT_ram_7777),A
ram:04d2 fe 03           CPI        0x3
ram:04d4 ca b2 0e        JZ         TEXT8_ENDE
ram:04d7 cd 1f 05        CALL       SYS_F8_ASCII_IN_BACKSPACE
ram:04da cd 15 05        CALL       SYS_F8_ASCII_IN_CR_ADD_LF
ram:04dd 23              INX        HL
ram:04de 22 ac 87        SHLD       (DAT_ram_87ac)
ram:04e1 e5              PUSH       HL=>DAT_ram_7778
ram:04e2 2a ae 87        LHLD       (DAT_ram_87ae)
ram:04e5 eb              XCHG
ram:04e6 e1              POP        HL
ram:04e7 cd bf 06        CALL       HLDE
ram:04ea da cb 04        JC         sys_f8_loop_next_character
ram:04ed cd 25 05        CALL       SYS_F8_ASCII_IN_SFENDB
ram:04f0 76              HALT

This shows that 0x03 (CTRL-C) is interpreted as end-of-transfer. Also backspace has special handling and CR is expanded to CR-LF. That doesn’t look like it works for binary transfer, although the input function does support 8 bit data.

Looking for a place that calls this function reveals a function pointer table around 0x028C with 16 function pointers. F-0, F-E and F-F are not used as they contain 0xFFFF. Interestingly F-D is used but not documented. It points to 0x0F70:

**************************************************************
*                          FUNCTION                          *
**************************************************************
                     undefined SYS_FD_BINARY_IN(void)
     undefined         A:1            <RETURN>
                     SYS_FD_BINARY_IN
ram:0f70 21 77 77        LXI        HL,0x7777
ram:0f73 cd 07 07        CALL       HEXIN
ram:0f76 22 ac 87        SHLD       (DAT_ram_87ac)
ram:0f79 21 00 87        LXI        HL,0x8700
ram:0f7c 22 ae 87        SHLD       (DAT_ram_87ae)
ram:0f7f cd 6b 05        CALL       BAUD
ram:0f82 cd 80 03        CALL       DUNKL
                     sys_fd_loop_next_character
ram:0f85 cd f1 04        CALL       ASCII
ram:0f88 2a ac 87        LHLD       (DAT_ram_87ac)
ram:0f8b 77              MOV        (HL=>DAT_ram_7777),A
ram:0f8c 23              INX        HL
ram:0f8d 22 ac 87        SHLD       (DAT_ram_87ac)
ram:0f90 e5              PUSH       HL=>DAT_ram_7778
ram:0f91 2a ae 87        LHLD       (DAT_ram_87ae)
ram:0f94 eb              XCHG
ram:0f95 e1              POP        HL
ram:0f96 cd bf 06        CALL       HLDE
ram:0f99 da 85 0f        JC         sys_fd_loop_next_character
ram:0f9c cd 25 05        CALL       SYS_F8_ASCII_IN_SFENDB
ram:0f9f 76              HALT

This “F-D” function looks very much like “F-8”, except it doe not interpret any special characters. There is no stop condition except the memory limit at 0x8700 (which should protect monitor program variables space). The missing stop condition is no problem as the interrupt key can be used instead.

Uploading Code to the Profi-5E using F-D

To upload code to the Profi-5E follow these steps:

• Press the red F key and then the black D key

• Press the G key to start the function

• Enter start address and confirm with red S key.

• The display will be turned off (“DUNKL”)

• Transmit a binary from a connected computer:

  cat out.bin | cu -s 300 -l /dev/cuaU0

The transmission is most reliable at lower speeds. With 2400 Baud I found that bits get lost intermittently.

Extending the monitor ROM to allow loading IHEX format

Uploading programs using F-D requires entering the start address every time. It would be much nicer if the monitor ROM could accept IHEX formatted data, which contains the address to load to in every input line:

:10810000C3148100000000000000004900000000CE
:1081100000000000160801038179824FCD60033E04

While reading the monitor ROM I noticed that some of the F-functions were unused, in particular F-0, F-E, F-F. Also there is some unused space between 0x0fa0 and 0x1c00, which would allow to add functionality.

So I wrote a little IHEX parser and embedded it into the monitor monitor ROM. The result can found in my Github repository. To use this, you have to read the original EPROM content and write a patched EPROM. Patching the EPROM data is part of the build process.

Afterwards the Profi-5E computer will be able to read IHEX data from the serial port using the F-E function keys

Summary

The undocumented F-D function allows to transmit programs to the Profi-5E using the standard monitor ROM. This allows to develop with a 8085 cross-assembler and transmit the results via serial line to the target system.

With a modified monitor ROM, the Profi-5E can read IHEX data from the serial port, making cross-development even easier.

The Daum Ergo Bike writes result records for each training to SD-Card directory data/result/ergo_bike. The data can be extracted with emc2edit.exe provided by Daum and converted to CSV.

The result file format was undocumented so far. After procmon revealed that the records are 44 Bytes long it’s not too hard to figure out the details by comparing the binary content with the CSV data:

result_file = GreedyRange(
    "result_record" / Struct(
        "elapsed_time"  / Int32ul,   # s
        "distance"      / Float32l,  # m
        "energy"        / Float32l,  # kJ
        "slope"         / Int16sl,   # 1/10 %
        "torque"        / Int16ul,   # 1/10 NM
        "rpm"           / Int16ul,   # 1/10 RPM
        "speed"         / Int16ul,   # 1/10 km/h
        "power"         / Int16ul,   # Watt
        "gear"          / Int8ul,
        "device_active" / Int8ul,    # 1
        "pulse"         / Int8ul,    # bpm
        "pulse_type"    / Int8ul,    # 7=invalid pulse, 0/4=valid pulse?
        "pulse_time_1"  / Int16ul,
        "pulse_time_2"  / Int16ul,
        "pulse_time_3"  / Int16ul,
        "pulse_time_4"  / Int16ul,
        "pulse_time_5"  / Int16ul,
        "pulse_time_6"  / Int16ul,
        "training_type" / Int16ul,
        "training_value"/ Float32l
))

I’ve written a simple python script that decodes the result records to CSV similar to the emc2edit output. It’s Available on Github.

I’ve added pictures of the PCB, including serial port location, and a serial console boot log to the daum project page.

For checking the performance calculation of my electronic flight book application of choice, I have implemented a little program for calculating the density altitude on an HP48 calculator. Here are the steps to derive the formula. This is posted an example only without any guarantees of correctness, so don’t rely on this. Especially these equations and programs don’t consider humidity.

Equations

First step is to calculate the density at the given altitude, using pressure reduced to sea level (QNH or p₀), and altitude h as inputs:

The equations use the following constants:

Next step is to apply temperature correction to the density with ΔISA as input to get the temperature corrected density ρ₂:

The calculated density can then be converted back to a virtual altitude at international standard athmosphere (ISA) conditions, aka density altitude:

If you fill in the some example numbers (e.g. 0 ft, QNH 1013.25 hPA, ΔISA 1 K), you will get an increase in density altitude per ΔISA of about 118 ft per ΔISA for small positive ΔISA. This closely matches the rule of thumb of 120 ft per ΔISA.

RPL Program for HP48 using ΔISA

%%HP: T(3)A(R)F(.);
@ calculate density altitude with delta ISA:
\<<
  "DENSITY ALTITUDE"
  {
    { "ALTITUDE   " "ALTITUDE IN FT             " 0  }
    { "QNH        " "QNH IN HPA                 " 0  }
    { "DELTA ISA  " "TEMPERATURE DIFFERENCE IN K" 0  }
  }
  1
  { 0 1013.25 0 }
  { 0 1013.25 0 }
  IF INFORM THEN
    OBJ\-> DROP
	3 PICK
	3 PICK
	3 PICK
    \-> alt qnh isa
    \<<
      alt 0.3048 *
      -9.80665 287.05 -0.0065 * /
      1 -
      qnh 100 * 287.05 288.15 * /
      \-> h k1 rho0
      \<<
        rho0
        1 -0.0065 h * 288.15 / +
        k1 ^
        *
        \-> rho1
        \<<
          288.15 -0.0065 h * +
          288.15 -0.0065 h * + isa + /
          rho1 *
          
          1
          9.80665 287.05 -0.0065 * /
          1 +
          /
    
          \-> rho2 k2
          \<<
            288.15
            288.15
            rho2 1.225 /
            k2 ^
            *
            
            -
            -0.0065
            rho2 1.225 /
            k2 ^
            *
            
            /
            
            0.3048
            /
          \>>
        \>>
      \>>
    \>>
  END
\>>

RPL Program for HP48 using tempature in °C

%%HP: T(3)A(R)F(.);
@ calculate density altitude with absolute temperature
\<<
  "DENSITY ALTITUDE"
  {
    { "ALTITUDE   " "ALTITUDE IN FT  " 0  }
    { "QNH        " "QNH IN HPA      " 0  }
    { "TEMPERATURE" "TEMPERATURE IN C" 0  }
  }
  1
  { 0 1013.25 15 }
  { 0 1013.25 15 }
  IF INFORM THEN
    OBJ\-> DROP
	3 PICK
	3 PICK
	3 PICK
    \-> alt qnh tmp
    \<<
      alt 0.3048 *
      -9.80665 287.05 -0.0065 * /
      1 -
      qnh 100 * 287.05 288.15 * /
      \-> h k1 rho0
      \<<
        rho0
        1 -0.0065 h * 288.15 / +
        k1 ^
        *
        \-> rho1
        \<<
          288.15 -0.0065 h * +
          273.15 tmp + /
          rho1 *
          
          1
          9.80665 287.05 -0.0065 * /
          1 +
          /
    
          \-> rho2 k2
          \<<
            288.15
            288.15
            rho2 1.225 /
            k2 ^
            *
            
            -
            -0.0065
            rho2 1.225 /
            k2 ^
            *
            
            /
            
            0.3048
            /
          \>>
        \>>
      \>>
    \>>
  END
\>>

I've published initial results from some Daum ergo bike reverse engineering that I did beginning of 2017. It’s available on my daum project page. The page will be updated whenever I find out more. Current status:

• Documented EPP training file format and implemented converter from GPX
• PINs for protected menus
• Root access via telnet
• Cross toolchain for Fedora 28, strace and OpenSSH cross-compiled, running on the control panel
• Cross-compiled kernel module as a preparation for additional device drivers

My internet connection was slow intermittently, so I needed a way to automatically collect throughput information several times a day. The internet service provider (Unitymedia in this case) has a speedtest page that's pretty useful for that, but it requires manual clicking a button every time. Not very practical for automated collection.

Turns out with Selenium this is pretty easy to automate. I did use the python API with chrome on Ubuntu 17.10, with following packages:

• python3-selenium
• chromedriver

The example code below runs the speedtest, collects the results and prints them to stdout in a somewhat structured way after the test run.

Update (2018-02-05): The script collects ping time as well now.

#!/usr/bin/env python3

import time
import sys

from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.support.ui import WebDriverWait

browser = webdriver.Chrome(executable_path="/usr/lib/chromium-browser/chromedriver")
browser.get('https://speedtest.unitymedia.de/')
browser.implicitly_wait(2)

assert 'Unitymedia' in browser.title
browser.find_element_by_link_text("Weiter zum Internet Speedtest").click()
browser.find_element_by_id("icon-unitymedia-cable").click()
browser.find_element_by_class_name("speedtest-btn--primary").click()

result_link = (WebDriverWait(browser, 60)
               .until(lambda x: x.find_element_by_link_text("Details & alte Ergebnisse ansehen")))
result_link.click()

browser.find_element_by_class_name("speedtest-toggle-header").click()
results = browser.find_element_by_class_name("speedtest-toggle-header")
results_id = results.get_attribute("data-test-id")
results_day = results.find_element_by_class_name("day").text
results_time = results.find_element_by_class_name("time").text
results_download = (results
                    .find_element_by_class_name("download")
                    .find_element_by_class_name("number")
                    .text)
results_upload = (results
                  .find_element_by_class_name("upload")
                  .find_element_by_class_name("number")
                  .text)

result_details = browser.find_element_by_class_name("speedtest-toggle-wrapper")
result_ping = (result_details
               .find_element_by_class_name("ping-result")
               .find_element_by_class_name("speed")
               .find_element_by_class_name("number0")
               .text)

print("{};\t{};\t{};\t{};\t{};\t{};"
      .format(results_day, results_time, results_download,
              results_upload, result_ping, results_id))
browser.quit()

Here is a little writeup of the steps taken to implement an altitude module eZ430-Chronos within openchronos-ng-elf. The challenge is that the MSP430 controller is a 16bit RISC controller, which has no floating point and no builtin multiply/divide instructions. In addition, the code size is limited to 32K

The TI eZ430-Chronos contains a pressure sensor. To calculate the altitude from current pressure according to International Standard Atmosphere (ISA) we can derive the following equations:

A number of input values are constant:

Putting the constants into the ISA formula, we get:

As reference this uses p₀, the current pressure reduced to mean sea level using the International Standard Atmosphere. In aviation that’s called QNH and can be looked up online for the closest airport.

Straigt-forward Implementation Using libm

Implementing the altitude function using pow() from libm, large chunks of libm get linked, resulting in a code size of about 16.8K. That is a lot, considering the controller in the eZ430-Chronos has only 32K of flash memory. So a better implementation is needed.

Implementing x^y with Binomial Series

Next idea was to replace the exponentiation part of the formula with a binomial series, which doesn’t require to link libm anymore. That leaves only multiplications and additions after pre-computing the constants:

For low altitudes (p ~ QNH, x ~ 1) the series converges pretty quickly. As termination criterium for the series the step size seems to work ok. The resulting altitude module code size is reduced to about 8K.

Lookup Table with Interpolation

The next optimization step was to use a lookup table with interpolation. This allows to avoid floating point math entirely. The function to replace with a lookup table looks like this:

The lookup table has been generated with a ruby script, that also determines the maximum error in a brute force way by feeding all possible input values into the lookup table and comparing with the exact altitude.

To get an error of max 5 ft with a QNH between 900 and 1100 and a pressure between 500 hPa and 1100 hPA a table size of 1342 bytes is sufficient. Since the lookup table generator places nodes directly onto the exact function values, we could optimize a bit by moving the points slightly off the exact value to minimize the error squares.

The resulting code including lookup table is reduced to about 3.6K. The code can be found on GitHub.

Results

The following table compares code size of various alternatives with the firmware without altitude module compiled in (baseline).

---------------------------------------------------
Module            rodata    text     sum   relative
---------------  -------  ------  ------  ---------
baseline             356   13056   13412          0
lookup table        1738   15399   17137       3725
binomial series      716   20918   21634       8222
libm                 722   29894   30616      17204
---------------  -------  ------  ------  ---------

After getting a new hard disk for my Lenovo X230 a fresh installation was required, so I decided to try UEFI dual boot installation of Fedora and OpenBSD on a single disk. This guide uses the builtin BIOS boot manager to not depend on chainloading OpenBSD via GRUB or an external EFI boot manager like rEFind.

BIOS Setup

First of all, enable UEFI Boot in BIOS Setup. Navigate to the the "Startup" tab and select 'UEFI Only'. CSM Support, which enables legacy support on top of UEFI is automatically disabled:

Fedora Installation

We start with installing Fedora 24. The installer supports UEFI and Fedora will even be bootable with UEFI Secure Boot, as it is using a signed shim loader.

Make sure to select "I will configure partitioning" and do not assign all of the disk to Fedora. There should be space left at the end. Fedora will automatically create a FAT formatted EFI system partition that is required for UEFI boot.

Fedora creates a traditional Master Boot Record (MBR) with a single partition that covers the whole disk to protect from legacy system seeing the disk as empty. In addition it creates a GPT partition table that contains the actual partitions. After Fedora is installed, the disk partitions should look like this:

Fedora uses efibootmgr to add a new boot option to the BIOS boot manager. That means there will be an entry "Fedora" in the boot device list in BIOS setup and in the boot menu that is reachable with F12 during boot. We will use efibootmgr later on to create a similar entry for OpenBSD.

OpenBSD Installation

I have used the latest released OpenBSD version 6.0 for this guide, UEFI is supported since version 5.9 there is support for UEFI boot. Depending on the installation medium you might need to temporarily enable legacy boot in BIOS setup for the installation process (for example for booting from CD-ROM or PXE).

Having successfully booted the installer and after selecting the installation disk, you will be presented with the following options:

Use (W)hole disk MBR, whole disk (G)PT or (E)dit? [whole] e

Make sure to select (E)dit. Otherwise the installer will directly wipe your GPT partition table and you have to start over. After selecting (E) you get a little text what the installer expects from you:

You will now create two GPT partitions. The first must have an id
of 'EF' and be large enough to contain the OpenBSD boot programs,
at least 960 blocks. The second must have an id of 'A6' and will
contain your OpenBSD data. Neither may overlap other partitions.
Inside the fdisk command, the 'manual' command describes the fdisk
commands in detail.

Fedora created the EFI system partition with id 'EF' already, so the only thing left is to create the OpenBSD partition with id 'A6'. At the fdisk prompt, first print the partition partition table that was created by Fedora:

Disk: sd0       Usable LBA: 34 to 937703054 [937703088 Sectors]
GUID: 1876166f-3413-44c9-8b7e-9e559bccb79f
   #: type                                 [       start:         size ]
      guid                                 name
------------------------------------------------------------------------
   0: EFI Sys                              [        2048:      1024000 ]
      c1a42d93-a363-4104-ab7e-050d48291df7 EFI System Partition
   1: Linux files*                         [     1026048:      1024000 ]
      d42b1596-d3cd-403f-8f6a-a191fa70f815
   2: Linux files*                         [     2050048:    325083136 ]
      82e12efd-b0eb-4962-9e55-7a18c759611e

The next free partition would be 3, so type type 'e 3' and enter the parameters for the new GPT partition. The tricky part is to calculate the start offset of the new partition and type it correctly, as the default was 34 in my case (if I remember correctly). The start offset of partition 3 should be start + size of the previous partition 2, 2050048 + 325083136 = 327133184 in my case. The default for the size is good again, as we want to use all the remaining space for OpenBSD. The finished GPT partition table looks like this:

Disk: sd0       Usable LBA: 34 to 937703054 [937703088 Sectors]
GUID: 1876166f-3413-44c9-8b7e-9e559bccb79f
   #: type                                 [       start:         size ]
      guid                                 name
------------------------------------------------------------------------
   0: EFI Sys                              [        2048:      1024000 ]
      c1a42d93-a363-4104-ab7e-050d48291df7 EFI System Partition
   1: Linux files*                         [     1026048:      1024000 ]
      d42b1596-d3cd-403f-8f6a-a191fa70f815
   2: Linux files*                         [     2050048:    325083136 ]
      82e12efd-b0eb-4962-9e55-7a18c759611e
   3: OpenBSD                              [   327133184:    610569871 ]
      c9377bdd-3b14-4002-8a22-c1dcd9595d2f

After writing the partition table ('write') and exiting fdisk ('quit'), follow the standard OpenBSD installation process. In my case I enabled full disk encryption for the OpenBSD part, so I had to follow some extra steps.

After finishing the installation remember to enable UEFI boot again in case you needed to disable for booting the installer. When booting, select the disk device as boot device. The UEFI BIOS will try to boot from the default path within the EFI system partition, which is 'EFI\BOOT\BOOTX64.EFI'. OpenBSD did place its UEFI bootloader there during installation:

[EFI System Partition]
`-- EFI
    `-- BOOT
        |-- BOOTX64.EFI
        `-- BOOTIA32.EFI

There will be no dedicated boot entry created in the UEFI BIOS boot device list. See the next section on how to use efibootmgr on Fedora to create a Boot menu entry for OpenBSD.

Create a BIOS Boot Manager Entry for OpenBSD

First of all, mount the EFI partition in either OpenBSD or Fedora and create a subdirectory for OpenBSD and copy 'EFI\BOOT\BOOTX64.EFI' into that directory:

[EFI System Partition]
`-- EFI
    |-- BOOT
    |   |-- BOOTX64.EFI
    |   `-- BOOTIA32.EFI
    |-- FEDORA
    |   |-- BOOT.CSV
    |   :
    |   
    `-- OPENBSD
        `-- BOOTX64.EFI

Boot into Fedora and run the following command:

sudo efibootmgr --create \
	--disk /dev/sda \
	--part 1 \
	--label 'OpenBSD' \
	--loader '\EFI\OPENBSD\BOOTX64.EFI'

On next boot, the UEFI BIOS boot manager should show a new boot option:

Be aware that OpenBSD will install new versions of BOOTX64.EFI into the default path 'EFI\BOOT\BOOTX64.EFI' on upgrade. So you have to remember to update the copy that is referenced in the boot menu. Fedora created 'EFI\BOOT\BOOTX64.EFI' as well and might overwrite on update, therefore I believe creating a copy in subdirectory for OpenBSD is best to prevent it from becoming non-bootable.

Within the last couple of days I made some progress with decoding the Geogrid-Viewer OVL binary file format. Geogrid-Viewer is part of various Top50 map products available in Germany and Austria. The most recent Top50 versions use file format version 5.0, which consists of ZIP compressed XML files and likely very easy to convert. But there are still a lot of older OVL files up to version 4.0 available on the internet. My main motivation were these version 2.0 files, that I wanted to convert into GPX.

To get more information about the OVL file format, it helped to observe Geogrid-Viewer with Procmon while reading OVL files. Fortunately the OVL files are read in pieces, which provides valuable information about the file structure. For tricky bits OllyDbg was helpful as well.

With the following file format "specifications" (there are still a lot of unknowns in there) I've improved the gpsbabel importer I wrote a year ago. I can now successfully parse all of the 153 random binary OVL samples I found on the internet. The patch will be provided to gpsbabel soon.

Update (2016-01-13): Corrected type1/type2 decoding in V3.0/V4.0

Update (2016-01-16): Patch has been merged into gpsbabel git

Update (2019-07-12): “Radtouren rund um Paderborn” has disappeared, link to web.archive.org instead.

Update (2020-01-08): Corrected subtype decoding in V2.0, add missing padding after magic bytes in V3.0 and V4.0

Version 2.0

Here is a pseudo C code like structure definition of version 2.0 OVL files. Those files can be identified by looking at the first 23 bytes of the file, which contain the string "DOMGVCRD Ovlfile V2.0".

// Geogrid-Viewer OVL binary file format version 2.0

struct FILE {
  struct HEADER {
    char magic[23];    // "DOMGVCRD Ovlfile V2.0:\0"
    uint16 header_len; // usually 0x90 or 0x00
    if (header_len > 4) {
      uint16 i1;
      uint16 i2;
      char map_name[header_len - 4];
      // the map_name field contains more information
      // then just the null-terminated name, but details
      // are unknown
    }
  }
  struct RECORD[] {
    uint16 entry_type;
    // 0x02: text
    // 0x03: line
    // 0x04: area
    // 0x05: rectangle
    // 0x06: circle
    // 0x07: triangle
    // 0x09: bitmap
    uint16 entry_group;
    uint16 entry_zoom;
    uint16 entry_subtype;
    if (subtype != 0x01) {
      uint32 text_len;
      char text[text_len];
    }
    union {
      struct TEXT {
        uint16 color;
        uint16 size;
        uint16 trans;
        uint16 font;
        uint16 angle;
        double lon;
        double last;
        uint16 text_len;
        char text[text_len];
      }
      struct LINE_AREA {
        uint16 color;
        uint16 width;
        uint16 type;
        uint16 point_count;
        struct POINT {
          double lon; 
          double lat;
        }[point_count];
      }
      struct RECT_CIRC_TRI {
        uint16 color;
        uint16 prop1;
        uint16 prop2;
        uint16 angle;
        uint16 stroke;
        uint16 area;
        double lon;
        double lat;
      }
      struct BITMAP {
        uint16 color;
        uint16 prop1;
        uint16 prop2;
        uint16 prop3;
        double lon;
        double lat;
        uint32 data_len;
        char data[data_len];
      }
    }
  }
}

Version 3.0 and 4.0

Version 3.0 and 4.0 are a bit different as they allow multiple parts in one file that all start with the magic bytes "DOMGVCRD Ovlfile V3.0" or "DOMGVCRD Ovlfile V4.0". In addition there are two types of data sections. A "label" section that might contain group definitions or similar. And a "record" section that contain the real data, like tracks or other kind of geometric objects.

The header contains the number of "label" and "record" sections following the header (see label_count and record_count). These might be zero, which means the part does not contain any label or record sections. OVL files containing parts without label or record section or without both do actually exist.

struct FILE {
  // A version 3.0/4.0 file might contain multiple parts all
  // starting with DOMGCRD magic bytes and header
  struct PART[] { 
    struct HEADER {
      char magic[23]; 
      // either "DOMGVCRD Ovlfile V3.0:\0"
      //     or "DOMGVCRD Ovlfile V4.0:\0"
      char padding[8];
      uint32 label_count;
      uint32 record_count;
      uint16 text_len;
      uint16 text[text_len];
      uint16 i1;
      uint16 i2;
      uint16 i3;
      uint16 header_len; // usually 0x90 or 0x00
      uint16 i4;
      uint16 i5;
      if (header_len > 4) {
        uint16 i1;
        uint16 i2;
        char   map_name[header_len - 4];
        // the map_name field contains more information
        // then just the null-terminated name, but details
        // are unknown
      }
    }
    struct LABEL[label_count] {
      char label_header[8];
      char label_number[14];
      uint16 label_text_len;
      char label_text[label_text_len];
      uint16 label_flags1;
      uint16 label_flags2;
    };
    struct RECORD[record_count] {
      uint16 record_type;
      // 0x02: text
      // 0x03: line
      // 0x04: area
      // 0x05: rectangle
      // 0x06: circle
      // 0x07: triangle
      // 0x09: bitmap
      // 0x17: line
      uint16 record_prop1;
      uint16 record_prop2;
      uint16 record_prop3;
      uint16 record_prop4;
      uint16 record_prop5;
      uint16 record_prop6;
      uint16 record_prop7;
      uint16 record_prop8;
      uint16 record_flags;      // 0x0001=ZOOM, 0x0002=NOZOOM, 0x0800=ROUNDED, 0x10000=CLOSED
      uint16 record_prop10;
      uint16 record_text_len;
      char record_text[record_text_len];
      uint16 record_type1;
      if (record_type1 != 1) {
        uint32 record_object1_len;
        char record_object1[record_object1_len];
      }
      uint16 record_type2;
      if (record_type2 != 1) {
        uint32 record_object2_len;
        char record_object2[record_object2_len];
      }
      union {
        struct TEXT {
          uint16 text_prop1;
          uint32 text_prop2;
          uint16 text_prop3;
          uint32 text_color;    // 0x80bbggrr
          uint16 text_size;     // 100-1100
          uint16 text_back;     // 1=transparent, 2=solid, 3-8=various patterns
          uint16 text_font;     // 1=Arial, 3=Courier, 4=Times, 10=Comic
          uint16 text_angle;    // 100-460
          double lon;
          double lat;
          double unkown;
          uint16 text_label_len;
          char [text_label_len];
        }
        struct AREA_LINE {
          uint16 line_prop1;
          uint32 line_prop2;
          uint16 line_prop3;    // 0x1e
          uint32 line_color;    // 0x80bbggrr
          uint16 line_width;    // 101-115
          uint16 line_back;     // 1=transparent, 2=solid, 3-8=various patterns
          uint16 line_count;
          if (record_type == 0x04)
            uint16 line_stroke; // 1=solid, 2=dashed, 3=dotted, 4=dot-dash
          }
          struct COORD[line_count] {
            double lon;
            double lat;
            double unkown;
        }
        struct RECT_CIRC_TRI {
          uint16 rct_prop1;
          uint32 rct_prop2;
          uint16 rct_prop3;     // 0x1e
          uint32 rct_color;     // 0x80bbggrr
          uint32 rct_width;
          uint32 rct_height;
          uint16 rct_stroke;    // 1=solid, 2=dashed, 3=dotted, 4=dot-dash
          uint16 rct_angle;     // 0-360
          uint16 rct_lwidth;    // 101-115
          uint16 rct_back;      // 1=transparent, 2=solid, 3-8=various patterns
          double lon;
          double lat;
          double unkown;
        }
        struct BITMAP {
          uint16 bmp_prop1;
          uint32 bmp_prop2;
          uint16 bmp_prop3;     // 0x1e
          uint32 bmp_prop4;
          uint32 bmp_width;
          uint32 bmp_height;
          double lon;
          double lat;
          double unkown;
          uint32 bmp_len;
          uint16 bmp_angle;     // 100-460
          char bmp_data[bmp_len];
        }
      }
    }
  }
}

Recently the workq API was replaced by taskq. This requires a minor update to the fjkey driver. A new patch is available for download. For more information see the older post

Update (2015-01-27): There was another change affecting fjkey. The latest patch is available for download.