Author Topic: Unraveling some time code?  (Read 765 times)

0 Members and 1 Guest are viewing this topic.

Offline metertech58761Topic starter

  • Regular Contributor
  • *
  • Posts: 156
  • Country: us
Unraveling some time code?
« on: November 15, 2023, 03:30:47 pm »
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.

Variables:
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: [Select]
app_DAB
LDX   #NVR_49
JSR   sub_687
STD   SRM_D1

LDX   #NVR_46
JSR   sub_687
SUBD  SRM_D1

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

LDAA  NVR_47
CMPA  NVR_4A
BEQ   app_DDE

LDX   #$0008
CPX   SRM_D1
BLT   app_DDE
BCS   app_DDE ; lower?

STAB  timeDiff

(continued)

app_DDE
(continued)

; Some type of time calculation
; Accumulators A / B hold result (16-bit value in Accumulator D)
sub_687 LDAB  $02,X
LDAA  #$90
MUL
ADDB  $01,X
ADCA  #$00
STAA  SRM_C0
LDAA  #$14
MUL
STD   SRM_C1
LDAA  SRM_C0
LDAB  #$14
MUL
TBA
CLRB
ADDD  SRM_C1
ADDB  $00,X
ADCA  #$00
RTS
« Last Edit: November 15, 2023, 09:13:59 pm by metertech58761 »
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1287
  • Country: pl
Re: Unraveling some time code?
« Reply #1 on: November 16, 2023, 07:54:01 am »
Disclaimer: AFAIK I have zero experience with this architecture.

Procedure sub_687 seems to be doing:
Code: [Select]
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? ;)

« Last Edit: November 16, 2023, 09:13:53 am by golden_labels »
People imagine AI as T1000. What we got so far is glorified T9.
 

Offline metertech58761Topic starter

  • Regular Contributor
  • *
  • Posts: 156
  • Country: us
Re: Unraveling some time code?
« Reply #2 on: November 16, 2023, 01:29:53 pm »
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.
« Last Edit: November 16, 2023, 03:22:15 pm by metertech58761 »
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1287
  • Country: pl
Re: Unraveling some time code?
« Reply #3 on: November 16, 2023, 03:19:54 pm »
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.
People imagine AI as T1000. What we got so far is glorified T9.
 
The following users thanked this post: metertech58761

Offline metertech58761Topic starter

  • Regular Contributor
  • *
  • Posts: 156
  • Country: us
Re: Unraveling some time code?
« Reply #4 on: November 16, 2023, 04:39:07 pm »
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?
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1287
  • Country: pl
Re: Unraveling some time code?
« Reply #5 on: November 16, 2023, 06:51:11 pm »
SRM_C0…2 are blindly overwritten by sub_687. Without caring about the previous contents. That happens twice for sys/local time comparison, one invocation destroying the results of the previous one. So I would say: it was your initial guess about these being scracthpad memory, that was right.
People imagine AI as T1000. What we got so far is glorified T9.
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1287
  • Country: pl
Re: Unraveling some time code?
« Reply #6 on: November 18, 2023, 02:51:14 am »
I inquired ChatGPT about the formula (2880 * t2 + 20 * t0 + t1) in multiple ways. It didn’t point to anything specific. But the responses were in a way peculiar. The smortnet was weirdly stuck with the idea, that variables tN represent days, hours and minutes. DHM is not the most popular date-time storage format. This gives a slight hint, that perhaps it seen it somewhere and we are on the right track about minutes (or half-minutes) being the basic unit and the topmost octet representing days.

Going in reverse, in hope ChatGPT generates something from the original context, yielded nothing of value.
« Last Edit: November 18, 2023, 02:52:46 am by golden_labels »
People imagine AI as T1000. What we got so far is glorified T9.
 

Offline metertech58761Topic starter

  • Regular Contributor
  • *
  • Posts: 156
  • Country: us
Re: Unraveling some time code?
« Reply #7 on: November 20, 2023, 06:26:25 pm »
Definitely on the right track... here's one routine that makes use of the above:

;   Subroutine
;   First call loads X register with the pointer to LMT time (previous NVR_46)
;   Second call loads X register with the pointer to system time (previous NVR_49)

;   Other variables:
;   SRM_D1 - 8-bit value
;   SRM_D2 - 8-bit value
;   Outside of this routine, SRM_D1 and SRM_D2 are handled as a single 16-bit value

;   SRM_D4 - 16 bit value - probably load profile-related (only other use is routine that works with load profile data)

;   NVR_4F - may be schedule? Code below suggests addresses $0C4F - $0C56 is used for this

;   NVR_59 / NVR_5A - 16 bit value, no other calls from LMT ROM - is likely written by absent DCT ROM
;   There is a routine that wipes most of upper RAM ($0C28 to $0CFC aka NVR_28 to NVR_FC), so assume NVR_59 & NVR_5A are 0 for now

Code: [Select]
sub_6A5 LDAA  flgTosSch ; is schedule flag clear (i.e., active)
ORAA  flgTmSync ; is time sync flag clear (i.e., LMT is synced to system time)
BEQ   sub_6B1
CLR   outBits ; No. Clear PIA output buffer and exit
RTS

; Unit is in sync with system time and schedule is active. Continue.
sub_6B1 LDAA  $02,X ; Current day
PSHX
INCA
ANDA  #$0E
STAA  SRM_D1
LDD   NVR_59
DEC   SRM_D1
sub_6BF DEC   SRM_D1
BLE   sub_6C7
LSRD
BRA   sub_6BF

sub_6C7 LDAA  #$00
ANDB  #$03
BEQ   sub_6D2
CMPB  #$01
BNE   sub_71D
LDAA  #$05
sub_6D2 STAA  SRM_D2
LDAB  #$04
STAB  SRM_D1
LDAB  #$00
PULX
LDAA  $02,X ; Current day
ANDA  #$01
BEQ   sub_6E2
LDAB  #$90
sub_6E2 LDAA  #$00
ADDD  #$0090
SUBB  $01,X ; Minutes in current interval
SBCA  #$00
STD   SRM_D4
PSHX
LDX   #NVR_4F
LDAB  SRM_D2
ABX

LDD   SRM_D4
PSHA
PSHB
LDAA  #$00
LDAB  $00,X
STD   SRM_D4
PULB
PULA
SUBD  SRM_D4

BLT   sub_722
sub_6F7 INX
DEC   SRM_D1
BEQ   sub_703
STD   SRM_D4

LDD   SRM_D4
PSHA
PSHB
LDAA  #$00
LDAB  $00,X
STD   SRM_D4
PULB
PULA
SUBD  SRM_D4

BGE   sub_6F7
sub_703 LDX   #NVR_4F
LDAB  SRM_D2
ADDB  #$04
ABX
LDAA  $00,X
LDAB  SRM_D1
BEQ   sub_716
sub_711 ASRA
ASRA
DECB
BNE   sub_711
sub_716 ANDA  #$03
CMPA  #$03
BNE   sub_71D
LDAA  #$00
sub_71D STAA  outBits ; Set TOU rate: 0 = base, 1 = lower peak, 2 = upper peak
PULX
RTS

sub_722 PULX
LDAB  $02,X ; Current day
INCB
BITB  #$01
BNE   sub_72B
INCB
sub_72B CMPB  #$0F
BNE   sub_731
LDAB  #$01
sub_731 LDAA  #$01
STD   tmSysMin ; B register: tmSysDay
RTS
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf