Products > Programming

Unraveling some time code?

(1/2) > >>

Chipping away at some code and I think I have finally identified the segment that deals with correlating the unit and system clocks.

However, I'm having a bit of difficulty visualizing how the time is calculated and stored. I'm not entirely sure if it is just a 7-day rollover or if it is some offset beyond 1/1/1980.

I'm hoping that someone a bit more familiar with assembly-level math and 6801 / HC11 assembly can see what I cannot.

If I can get a better understanding of what's going on here, it will help "unlock" some more of the code for me.

NVR_46 - NVR_48: local time register
NVR_49 - NVR_4B: system time register
SRM_C0 - SRM_C2: likely a scratchpad area
SRM_D1 - SRM_D2: time difference temp register?
timeDiff: Time difference (for setting time sync flag and calculating time on battery)

--- Code: ---app_DAB
LDX   #NVR_49
JSR   sub_687

LDX   #NVR_46
JSR   sub_687

BCC   app_DC0 ; higher or same?
ADDD  #$9D80

BEQ   app_DDE

LDX   #$0008
BLT   app_DDE
BCS   app_DDE ; lower?

STAB  timeDiff



; Some type of time calculation
; Accumulators A / B hold result (16-bit value in Accumulator D)
sub_687 LDAB  $02,X
LDAA  #$90
ADDB  $01,X
ADCA  #$00
LDAA  #$14
LDAB  #$14
ADDB  $00,X
ADCA  #$00

--- End code ---

Disclaimer: AFAIK I have zero experience with this architecture.

Procedure sub_687 seems to be doing:
--- Code: ---2880 * t[2] + 20 * t[0] + t[1]
--- End code ---
… 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? ;)

There's a counter elsewhere in the code that resets every 1800 counts, so you may be on to something there.

I'll post that code later (it is one in a series of counters).

Edit: I've read through it again and tbh, I think I can see a few more parts of the puzzle moving into place.

There is definitely a need for a day of the week value, as the unit has a 7-day schedule.

I missed one possibility that also includes 144 and 20. Quarter-minutes (15 s), 144 of which is 12 h. In this scenario 40320 neatly fits exactly one week.

Pieces sliding together...

As I went to clean up the definitions section of the source, I realized the very next variable after SRM_C2 (my temporary notation for the SRAM address $C2), is that counter that resets when it reaches 1800.

So $C0 - $C2 may not be just a scratchpad... and are actually referenced throughout the code. So would it be safe to say that is the actual clock reference?


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod