Disclaimer: AFAIK I have zero experience with this architecture.

Procedure

`sub_687` seems to be doing:

`2880 * t[2] + 20 * t[0] + t[1]`

… where

`t` is the i-th byte in an

`NVR_`*x* triplet. Yes, the order is “2, 0, 1”, not “2, 1, 0”. The operation is split into multiplying by 144 (8-bit · 8-bit → 16-bit) and then by 20 (16-bit · 8-bit → 16-bit). Doing 16-bit multiplication seems to be the cause of all the temporary values shuffling: it’s split into two 8-bit multiplications.

Unless there is some deeper meaning behind these values,

^{(1)} it may be packing values into a single 16-bit number, so they can be cheaply compared in their lexicographical order. If that is true, the ranges would be limited to:

- [0, 19] for t[1]
- [0, 143] for t[0]
- [0, 22] for t[2]

This way the above expression would fit the values into 16 bits without collisions. Does any number, which fits in these ranges (likely smaller than any of them) make any sense in the context of how these triplets are used elsewhere?

The only thing, which pops up, is 2880, which is twice 1440 (the number of minutes in a day). So, hypothetically pair (t[0], t[1]) may be storing half-minutes of a day in some convoluted little-endian format, and t[2] counts days. t[0] may be 10-minute periods of the day, and t[1] half-minutes in the current 10-minute period.

0x9D80 is exactly the number of half-minutes in 14 days. Also exactly the number of hours in 240 weeks, but that is less likely. I have no idea, why it would be added to local time in case system time is greater.

0x0008 may be a number chosen to fit the alredy existing values, without any meaning by itself. But if the half-minutes hypothesis is right, it would indicate 4 minutes. Do 4 minutes manifest themselves anywhere?

^{(1)} Due to a mistake I already managed to discover subsequence (positions 54–68) of OEIS A025642 in your code. And 0x9D80 is 8!. So who knows?