--- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
>
> Yes, the VDLK doesn't scroll, I never really looked into why.

It seems it's not calling the timer 0 interrupt.  Scrolling works if you call
lcdPixelScrollMsg{Left|Right} yourself after setting up scrolling.

Argh...  Just when I thought the app was ready for release I found a really
nasty crash bug.  When there were zero records free, going to the "unused
entries" display caused the LCD contrast to drop to nothing, and made the watch
stop responding to button presses...  Kind of scary, just suddenly having an
apparently blank display and requiring a hard reset to fix it...  (I couldn't do
a button reset since the watch wasn't responding to buttons...)

lcdDisp4DigitSegDataZeroSup was the culprit.  It prints out a 4-digit BCD number
stored in BA, suppressing leading zeros:
If there are no leading zeros, it writes four digits to LCD memory...
If there is one leading zero, it writes three digits...
If there are two leading zeros, it writes two digits...
If there are three leading zeros, it writes one digit...
If there are four leading zeros, it writes 256 digits...

(Basically, it correctly calculates the number of digits to display and loads
that into a DJR loop...  But when it reaches DJR and B is already zero, it
decrements and wraps around...  Ugh.)

I fixed it (yes, more special-case handling code that needs to go in my app,
thank you Timex) but this kind of kills my hopes of releasing the app today... 
It's clear I need to spend more time testing.  :(

> I just finished it last night, actually.  :) It did take some work.
> All kinds of little mistakes in my first attempt, and then that API
> bug that I'd neglected to heed your warnings about.

Comdolences. And congratulations. :)

> I don't actually sort the whole database on the watch - When I save a
> record I try to re-insert it in the proper position, based on an
> assumption that the DB is already sorted.
>
> So if you have an unsorted DB and edit a record, its position will
> change...  If you edit-and-save each record the DB will wind up
> sorted.

OK, so insertion sort. That's not too bad - you don't need to deal with
swapping elements, though tht's really just adjusting prevnext pointers
- thouggh I disagree that it will wind up sorted if you edit/save all
the elements. Consider the case where you have an early event near the
end - other events will get put after it, until the early one is
resorted, and then the previously inserted ones will be wrong. Or even
just consider a list in reverse-sorted order.
Anyway, not trying to say yours is bad, or needs to be changed, just
pointing it out.

> For now it's not even a very good method - I just start at the end of
> the record list and search backward until I find my insertion point.
> I wanted to do something a little smarter (like start at the record's
> original position, search forwards and backwards) - based on the
> assumption that a lot of the time someone may edit a record in such a
> way that its position doesn't really change much, or at all.  But to
> get the code written quickly and keep the code small I chose to go
> with the simpler method, at least for the time being.

I think that one's probably a lot harder to do - it's a mess to search
both ways, and I'm not sure I'd make that asumption. For example, I
frequently keep an old appointment reminder - say, that my library books
are due (yep, some people still use the library!) - and update it,
rather than making a new one. Dates can jump by a few weeks. It nmight
be better to keep a copy of the old date/time for a quick comparison
with the new one, and then you can know which way to look.

> > [IX use]
>
> As long as I don't need IX for something, it's cheaper to set it and leave it
alone.
>
> IX is used later on in LOAD_EVENT, again with the assumption that it points to
the start of the ASD.  So it's the same situation

- it's cheaper to copy IX into another register and increment the copy than it
is to increment IX and restore its old value again.

That's fine, as I mentioned, I didn't check everything. If it's used,
it's used.

> > I like your optimizations of CP A, #0 with OR A, A, and CP A, #0 with OR A,
B. Another one you can use is XOR A, A to clear A,

rather than SUB A, A. Saves a byte in a handful of places.
>
> SUB A, A actually only takes one byte, so there's no savings in code size. 
Though XOR A, A does have other advantages: it's not

sensitive to decimal mode or unpack mode, and it won't clear the overflow or
carry bits if some other operation has set them.

Huh. So you're right. My apologies. I guess it's just so ingrained in me
to use XOR that I didn't even remember that it was also good, or to
check. Maybe I'd thought it was fewer cycles, too, but that's clearly
not the case when checking.

> If you go to the app and pull the crown when you're in the banner
> state, you visit state 3 before you've visited state 1.  When I wrote
> the initialization code I was under the impression that mode browsers
> skip the banner state: So I couldn't put initialization code in the
> banner state (0) because mode browsers could skip it, and I couldn't
> put initialization code in state 1 entry because crown set can get you
> to state 3 first.  But since you've said Neolink actually does run the
> banner state, I can probably revisit that, and put init code in the
> banner state, save some more space from the common area.

Ahh, yes. That makes sense. And moving the initialization code into the
banner state might be very helpful for code size, then. :)

>    In this case, my code is cheaper, because I take advantage of the
>    value of HL a few lines down with "inc [HL]" - which is a
>    fabulously cheap instruction. If I didn't already have #INIT_STATE
>    in a register then setting [INIT_STATE] to something nonzero would
>    require at least three additional bytes of program space.

Ahh, right you are. It is a great set of instructions to manipulate [HL].

> They don't.  All the common code between CROWNCW and CROWNCCW is in
> LOAD_NEW_RECORD.  CROWNCW falls through to this code, while CROWNCCW
> jumps to it.  The only other difference between the two event handlers
> is which offset they load into [IX].

Whoops. I totally missed the LOAD_NEW_RECORD label, there. I'd thought it
was somewhere else in the file, hence that they were different. How
embarassing. :(

> As they're written they can't really share more code than they do.
> The differences are in which table they load into IY, and how they
> calculate the offset into the table.

Yeah, it was the
                 add A, A
                 ;; Clear B so that we can add A to IY with the following
instruction:
                 ld B, #0
                 add IY, BA
that I was seeing that seemed duplicated, and I'd missed the 2/3 difference
in the final load. Seems like a pity, but I guess there's no way around it.
Pushing/popping B around a block elsewhere probably wouldn't save any.

> 'Course, more space can be saved by calculating the table offsets with
> MLT instead of adding A to itself and zeroing out B - Not sure why I
> didn't go that route.  I think I used MLT earlier on and thought maybe
> I could do better - but all the little things I needed to do (like
> zero out B, etc.) just added up.

Yeah, I thought of suggesting a table lookup for your database state,
but decided that it probably wouldn't end up helping.

> I need ADD and SUB because I'm adding/subtracting one in BCD mode.  INC/DEC
doesn't do that.
>
>    According to the docs, inc doesn't touch the carry bit. The only bit it
should be setting is the zero bit.  And the code does

work.  (If I set the calendar to Dec 31, 1999, then navigate to the months field
and increment, I get Jan 31, 2000, not Jan 31,

1900.)
>
> DEC doesn't set carry - and I probably wanted to retain the original value of
B.

Damn. Right you are again. I'm getting far too rusty, here! :(
I apologize for my misinformation, and good on you to verify. And now I
need to go check my Neolink code to make sure I didn't use that inc/dec
for a carry bit, since I must have gotten the idea from somewhere...

> > Yes, the VDLK doesn't scroll, I never really looked into why.
>
> It seems it's not calling the timer 0 interrupt.  Scrolling works if
> you call lcdPixelScrollMsg{Left|Right} yourself after setting up scrolling.

Huh, neat. The source code for the VDLK is on sourceforge, should you feel like
fixing it. :)
http://sourceforge.net/projects/virtualdatalink/

> Argh...  Just when I thought the app was ready for release I found a really
nasty crash bug.  When there were zero records free, going to the "unused
entries" display caused the LCD contrast to drop to nothing, and made the watch
stop responding to button presses...  Kind of scary, just suddenly having an
apparently blank display and requiring a hard reset to fix it...  (I couldn't do
a button reset since the watch wasn't responding to buttons...)
>
> lcdDisp4DigitSegDataZeroSup was the culprit.  It prints out a 4-digit BCD
number stored in BA, suppressing leading zeros:
> If there are no leading zeros, it writes four digits to LCD memory...
> If there is one leading zero, it writes three digits...
> If there are two leading zeros, it writes two digits...
> If there are three leading zeros, it writes one digit...
> If there are four leading zeros, it writes 256 digits...
>
> (Basically, it correctly calculates the number of digits to display and loads
that into a DJR loop...  But when it reaches DJR and B is already zero, it
decrements and wraps around...  Ugh.)
>
> I fixed it (yes, more special-case handling code that needs to go in my app,
thank you Timex) but this kind of kills my hopes of releasing the app today... 
It's clear I need to spend more time testing.  :(

My condolences. I think that makes 3 or 4 bugs I've seen/caught/special cased in
their ROM. And that doesn't count the things that they should have added, but
didn't, that get requested a surprisingly large number of times - like number of
seconds night-mode stays on for (not the same as how long to hold to turn night
mode on/off). Programming lesson: Never hard-code magic numbers. Always make
them easily changable, and configurable by the user, if possible. I'll forgive
the number of Timezones, since that actually takes a chunk of memory for each.
:)


> Thanks for taking a look at the code.  I'm not feeling too much
> pressure to cut down on code space at the moment (the big thing was
> getting LOAD_EVENT to fit in the 900 byte overlay, to make switching
> events faster) - right now I'm more focused on bugs and features.  I
> want to get v1.0 ready.  Digging too deep into code space optimization
> would be troublesome at this point, 'cause it means lots of regression
> testing.  But it's always fun to talk shop and nice to get another set
> of eyes on the code for a fresh look.

No problem at all; it was fun to read through. I completely get the
regression testing, though it sounds like you need to do some more of
that, anyway. :P But that was more why I'd focused on peephole
optimizations, though apparently got enough of those wrong, even so. :(

--- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
> OK, so insertion sort. That's not too bad - you don't need to deal with
> swapping elements, though tht's really just adjusting prevnext pointers
> - thouggh I disagree that it will wind up sorted if you edit/save all
> the elements. Consider the case where you have an early event near the
> end - other events will get put after it, until the early one is
> resorted, and then the previously inserted ones will be wrong. Or even
> just consider a list in reverse-sorted order.

Whenever a record is saved, the sorting code guarantees that all records that
appear after the saved record's new position have deadlines that occur after the
saved record...  And that guarantee is maintained for that record any time
another record is saved.  Consider:

{unsorted}, A, {unsorted, but all greater than A}    ; A just got saved, so the
app scanned left from the end of the list until it found the position where it
could maximize the size of that right-side list.

If you open and re-save another record, B, it gets picked out of one of those
"unsorted" regions.  If B < A, then B will appear to the left of A.  (Due to
transitive property - A is less than that unsorted blob or it wouldn't have been
put to the left of it when saved.  Therefore B is less than everything in that
blob, too.)

If B > A, then it winds up back in that right-side blob when it's saved.  Thus,
the assertion made when saving A is maintained: anything to the right of A has a
later deadline.

Because that assertion is never invalidated, that means that once we've saved
all the records, the assertion applies to all records.  Anything to the right of
any given record has an equal or later deadline.  Therefore (by induction,
starting with the first record) the list is sorted.

In terms of the user experience it's a lousy way to sort a database - but it's
hopefully not something the user would ever see - since the python database
creation script I wrote now sorts the records, too.

> I think that one's probably a lot harder to do - it's a mess to search
> both ways, and I'm not sure I'd make that asumption. For example, I
> frequently keep an old appointment reminder - say, that my library books
> are due (yep, some people still use the library!) - and update it,
> rather than making a new one. Dates can jump by a few weeks.

Still, as a starting point for a search, it's a pretty good bet.  But the code I
wrote is good enough for now.  "Good enough" has been a big thing with this
project...  Like I'll come up with a "better" way of doing something, but it
won't actually be "better" 'cause it makes the code larger.  :)

> Ahh, yes. That makes sense. And moving the initialization code into the
> banner state might be very helpful for code size, then. :)

Indeed...  It's good that you pointed that out, I moved the init code,
streamlined it, and saved a bunch of overlay space.

> > > Yes, the VDLK doesn't scroll, I never really looked into why.
> >
> > It seems it's not calling the timer 0 interrupt.
>
> The source code for the VDLK is on sourceforge, should you feel like fixing
it. :)
> http://sourceforge.net/projects/virtualdatalink/

I may take that on at some point.  Though I'm not really set up at home to work
on Windows code - let alone in Pascal.  So I might not get too far unless I port
the thing to Linux first.  :)  Which would also be really nice...  Wine works
but it really annoys me sometimes...

I've been working on fixing various long-standing bugs and putting some polish
on in a few places:
- App now "fails gracefully" when displaying an interval greater than 9999 days
(it shows "9999d+" as the countdown...  not great but it beats the garbled
jumbles and even crashes I was getting before...)
- The scroll message now scrolls once and stops at the beginning of the message.
(I stared at the API scroll code in the debugger until it started to make sense,
and I set up a timer that starts after I get the end-of-scroll-message event to
check to see if the current scroll position is the start of the message.)
- Pressing the crown (EL press) resumes scrolling
- Added code for correct pluralization of "UNUSED ENTRY"/"UNUSED ENTRIES"
- Pulling the crown now shows one of three different messages depending on the
condition: "EDIT EVENT" (instead of the previous one, "SET DEADLINE"), "NEW
EVENT", or "NO RECORD" if you try to create a record when the DB is full)

So it kind of sucks that I wasn't able to release v1 when I wanted to...  But
the app will be a lot better as a result of the extra attention.

It also turns out that decrementing the day in calendar view can get me to "Year
0"...  I may not bother fixing that one just now.  :)

I have been hitting some bugs that just seem really random, though - like the
app will be running, apparently without any problems for hours, and then I'll
switch events and everything will go screwy...  Or an alarm will go off any my
watch will crash when I dismiss it.  I have no idea what's going on there...  I
haven't managed to reproduce any of these issues yet but every now and then a
new one turns up...  It's very disturbing.

--- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
>
> Ahh, yes. That makes sense. And moving the initialization code into the
> banner state might be very helpful for code size, then. :)

Unfortunately it also appears that if an alarm goes off while the app is
running, COREWorkBuffer is filled with alarm data, and the app that was running
gets a COREEVENT_STATEENTRY.

What I don't know is what happens in between.  I can't readily find out with
VDLK because if my app is loaded, Alarm isn't.  :)  But based on bugs I've been
seeing in T-Minus it seems that the app may be going straight to state 1 in the
app, bypassing the banner state (and, thus, the initialization code).

It's hard to dig too far into what exactly happens when coming back from an
alarm due to the VDLK issue, but it kind of looks like I can't rely on the
banner state to do initialization in this case.

> Whenever a record is saved, the sorting code guarantees that all records that
appear after the saved record's new position have deadlines that occur
> after the saved record...  And that guarantee is maintained for that record
any time another record is saved.  Consider:
>
> {unsorted}, A, {unsorted, but all greater than A} ; A just got saved, so the
app scanned left from the end of the list until it found the position
> where it could maximize the size of that right-side list.
>
> If you open and re-save another record, B, it gets picked out of one of those
"unsorted" regions.  If B < A, then B will appear to the left of A.
> (Due to transitive property - A is less than that unsorted blob or it wouldn't
have been put to the left of it when saved.  Therefore B is less than
> everything in that blob, too.)
>
> If B > A, then it winds up back in that right-side blob when it's saved. 
Thus, the assertion made when saving A is maintained: anything to the right
> of A has a later deadline.
>
> Because that assertion is never invalidated, that means that once we've saved
all the records, the assertion applies to all records.  Anything to the
> right of any given record has an equal or later deadline.  Therefore (by
induction, starting with the first record) the list is sorted.
>
> In terms of the user experience it's a lousy way to sort a database - but it's
hopefully not something the user would ever see - since the python
> database creation script I wrote now sorts the records, too.

That all works very nicely, but only if you have the invariant that your array
is always sorted to start with. If you have {unsorted, might be bigger or
less than A}, A, {again, don't know comparison}, you're in a bind. I guess if
you only insert elements through t-minus, it'll work, but otherwise ou
don't have that guarantee.

> Still, as a starting point for a search, it's a pretty good bet.  But the code
I wrote is good enough for now.  "Good enough" has been a big thing
> with this project...  Like I'll come up with a "better" way of doing
something, but it won't actually be "better" 'cause it makes the code larger. 
:)

Absolutely. Get it to market faster, bug free. Optimizations come later.

> I may take that on at some point.  Though I'm not really set up at home to
work on Windows code - let alone in Pascal.  So I might not get too far
> unless I port the thing to Linux first.  :) Which would also be really nice...
Wine works but it really annoys me sometimes...

Pascal is pretty straightforward (lots of examples around in the code, for
style/syntax), and you can get the Delphi toolchain/IDE for free on their
site, which is what all the project files are in. But yeah, if you want to port
it to Linux, that would be amazing!

> I've been working on fixing various long-standing bugs and putting some polish
on in a few places:
> - App now "fails gracefully" when displaying an interval greater than 9999
days (it shows "9999d+" as the countdown...  not great but it beats the garbled
jumbles and even crashes I was getting before...)
> - The scroll message now scrolls once and stops at the beginning of the
message.  (I stared at the API scroll code in the debugger until it started to
make sense, and I set up a timer that starts after I get the
end-of-scroll-message event to check to see if the current scroll position is
the start of the message.)
> - Pressing the crown (EL press) resumes scrolling
> - Added code for correct pluralization of "UNUSED ENTRY"/"UNUSED ENTRIES"
> - Pulling the crown now shows one of three different messages depending on the
condition: "EDIT EVENT" (instead of the previous one, "SET DEADLINE"), "NEW
EVENT", or "NO RECORD" if you try to create a record when the DB is full)
>
> So it kind of sucks that I wasn't able to release v1 when I wanted to...  But
the app will be a lot better as a result of the extra attention.

Very impressive list. Nice!

> It also turns out that decrementing the day in calendar view can get me to
"Year 0"...  I may not bother fixing that one just now.  :)

Sounds like a wraparound issue. Not too hard to fix, you just need to find it.

> I have been hitting some bugs that just seem really random, though - like the
app will be running, apparently without any problems for hours, and then
> I'll switch events and everything will go screwy...  Or an alarm will go off
any my watch will crash when I dismiss it.  I have no idea what's going
> on there...  I haven't managed to reproduce any of these issues yet but every
now and then a new one turns up...  It's very disturbing.

I'm going to guess that's part of the issue from below. Also note that some
stuff happens in the background on the hour/day, so that could be a culprit,
too.

> > Ahh, yes. That makes sense. And moving the initialization code into the
> > banner state might be very helpful for code size, then. :)
>
> Unfortunately it also appears that if an alarm goes off while the app is
running, COREWorkBuffer is filled with alarm data, and the app that was
> running gets a COREEVENT_STATEENTRY.

Ah, yes I remember running into that, somewhere. When another app has an
interrupting background event (there are a few kinds, but they're rare, usually
alarms/chronos, etc. triggering) it steals control, fires off the background
event, and then returns. Warning, may destroy work buffer. It's even worse
when it's not a built-in app, since the background code might be bigger than
your background code, and thus overwrite some of your state (or just the
background code). Or at least, that's my vague recollection of a seperate bug
when I was trying to work on background ittyben chimes. I gave up, but if
you want to try (and succeed) definitely let me know!

> What I don't know is what happens in between.  I can't readily find out with
VDLK because if my app is loaded, Alarm isn't.  :) But based on bugs I've
> been seeing in T-Minus it seems that the app may be going straight to state 1
in the app, bypassing the banner state (and, thus, the initialization
> code).

I think I mostly described what happens, above. I'm not sure of a good solution
offhand, sadly, other than rerunning the initialization code. Maybe have
a flag bit at the end of the work buffer? Not guaranteed, but better than
nothing.

What I can offer, however, is a solution to your testing issue. The VDLK
supports reading in a ROM from your watch. I have no idea how well it works in
Linux, and I haven't used the feature in donkey's years. But you have the
potential to load on an Alarm and T-Minus, then read it into the VDLK, and
step through what's happening. It does suck for repeated testing, though, as you
have to re-load onto a physical watch. At one point I made a
pseudo-alarm mode, that I could toss into the VDLK and it would just jump into
the built-in handlers at the various modes. It had some very strange
occasional bugs in it, and I'd have to go digging to find it, but I can try, if
you think it would be helpful.

> It's hard to dig too far into what exactly happens when coming back from an
alarm due to the VDLK issue, but it kind of looks like I can't rely on the
> banner state to do initialization in this case.

Actually, that reminds me of another option: rather than moving the code back
into common code, it would probably be nicer to just rerun the whole
banner, and then come back to state 1/3. A bit too much EEPROM loading, but you
might not notice it, and it saves on space. You can do it like so:
    LD    B, #0
    LD    HL, #0A72DH
    PUSH  HL
    JR coreCommonModeChange
The 0A72DH is a specific address in rom (took me a long time to find, when
working on Neolink) that's the code in the banner handler which will jump
into the next state. It might be the part that chooses if it's a
password-protected state, and might jump to state 5 if that's set. So fiddle
with it in
the VDLK a little, but it should get you 90% of the way there.

--- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
>
> > Whenever a record is saved, the sorting code guarantees that all records
that appear after the saved record's new position have deadlines that occur
> > after the saved record...  And that guarantee is maintained for that record
any time another record is saved.

> That all works very nicely, but only if you have the invariant that your array
is always sorted to start with. If you have {unsorted, might be bigger or
> less than A}, A, {again, don't know comparison}, you're in a bind. I guess if
you only insert elements through t-minus, it'll work, but otherwise you
> don't have that guarantee.

You would only have that condition in cases where A hadn't been opened and
re-saved on the watch yet.  If you save a record, then you know that any records
that appear later in the record list happen after A, because that's what the
sorting code does.  Once you've saved record A there will not be a record that
appears after A but occurs later.  This is because when the DB code decides
where to insert the record, it does it by scanning from the end of the list.  As
soon as it finds a record that should appear before A, it stops looking and
inserts A after that record.

So if you have these records:

5, 7, 1, A=4, 8, 3, 9, 6

And you open and resave A, you wind up with this:

{5, 7, 1, 8, 3}, A=4, {9, 6}

Records 5, 7, and 8 should appear after A, of course - but the point is the
values in the right-hand set are all greater than A, and this will remain true
when any other records are saved.  This is because it is not possible, after A
is saved, for a record with a value less than A to wind up in the set to the
right of A.  If a record (B) with a value less than A is saved, it will sort to
the left of A, because B<A and B<x for any x where A<=x.

The array -should- always be sorted, though.  The DB creation script sorts
records and the app always keeps them sorted.

> > I may take that on at some point.  Though I'm not really set up at home to
work on Windows code - let alone in Pascal.  So I might not get too far
> > unless I port the thing to Linux first.  :) Which would also be really
nice...  Wine works but it really annoys me sometimes...
>
> Pascal is pretty straightforward (lots of examples around in the code, for
style/syntax), and you can get the Delphi toolchain/IDE for free on their
> site, which is what all the project files are in. But yeah, if you want to
port it to Linux, that would be amazing!

I'm familiar with Pascal. I actually learned Turbo Pascal before I learned C.
the problem is more that I don't have (or particularly want) a Windows box at
home to develop on.  I suppose it might be possible to run Delphi in WINE...

Also, I found a bug in VDLK's CPU emulation.  Basically, SBC A, #0 in decimal
mode will result in non-decimal values if the lower four bits of A are zero. 
(So when A=20h and decimal is on and carry is set, SBC A, #0 yields A=1Fh
instead of A=19h) I think this line:

       if (bs and $F) > (bd and $f) then begin

Should say this instead:

       if ((bs and $F) + c) > (bd and $f) then begin

The if statement condition controls whether the lower 4 bits of the result are
adjusted to keep the result in the decimal range - detecting underflow of that
digit.  It just didn't account for carry...

There's a similar bug in ADC:

        if ((Word(bd) and $F) + (Word(bs) and $F)) > 9 then begin

should say

        if ((Word(bd) and $F) + (Word(bs) and $F) + c) > 9 then begin

Both bugs manifest in the calendar mode of T-Minus, as well as the Calendar app:
When ktodSubtractYears is used to subtract 1 from 2000, the result is 1f99 - and
adding 1 to 1999 yields 1a99.

> > I've been working on fixing various long-standing bugs and putting some
polish on in a few places...

> Very impressive list. Nice!

Yeah, it seems like the list of things to be fixed never ends...  Today it was
the alarm thing and the year zero thing...  Every time I add some new tweak or
fix to state 1 I have to reduce the code size by enough to fit the new code in. 
So far I've managed to find the space I need each time I need to fit something
in - but I'm always worried that I'll run out of places to scrounge up a few
bytes.

> > What I don't know is what happens in between.  I can't readily find out with
VDLK because if my app is loaded, Alarm isn't.  :) But based on bugs I've
> > been seeing in T-Minus it seems that the app may be going straight to state
1 in the app, bypassing the banner state (and, thus, the initialization
> > code).
>
> I think I mostly described what happens, above. I'm not sure of a good
solution offhand, sadly, other than rerunning the initialization code.

    Well, the main thing that has to happen in init is loading the record - so I
added code so the app (again) does that any time there's state entry into state
1.  So for now I do that and it seems to work.  At the moment this also means
that I load the event twice on startup (once in the banner state, once in state
1) - which basically sucks, but that's more or less how it has to be right now.

    In general I've just got to have a better idea of what data I can rely on
remaining safe during a background event, and what sort of conditions I'll see
when the event is over...  I'm guessing COREForegroundCommonBuffer isn't
touched, and the ASD for my app should remain intact as well...  Not much I
could do if my code got overwritten, though.

    I'll have to see about getting or making a non-ROM app installed that does a
background event.  That's probably the easiest way to learn more about how they
work, and what I should do to try to prevent them from breaking my app.  :)

> You would only have that condition in cases where A hadn't been opened and
re-saved on the watch yet.  If you save a record, then you know that any records
that appear later in the record list happen after A, because that's what the
sorting code does.  Once you've saved record A there will not be a record that
appears after A but occurs later.  This is because when the DB code decides
where to insert the record, it does it by scanning from the end of the list.  As
soon as it finds a record that should appear before A, it stops looking and
inserts A after that record.
>
> So if you have these records:
>
> 5, 7, 1, A=4, 8, 3, 9, 6
>
> And you open and resave A, you wind up with this:
>
> {5, 7, 1, 8, 3}, A=4, {9, 6}
>
> Records 5, 7, and 8 should appear after A, of course - but the point is the
values in the right-hand set are all greater than A, and this will remain true
when any other records are saved.  This is because it is not possible, after A
is saved, for a record with a value less than A to wind up in the set to the
right of A.  If a record (B) with a value less than A is saved, it will sort to
the left of A, because B<A and B<x for any x where A<=x.
>
> The array -should- always be sorted, though.  The DB creation script sorts
records and the app always keeps them sorted.

Good idea. Why didn't I think of using an example? Too tired, I suppose. The
visual helps. I guess the distinction is in whether all the elements have to be
edited, or just most. I thought I'd had an better example, but I can't seem to
come up with it again, so I'll blame it on sleep deprivation. :(

> Also, I found a bug in VDLK's CPU emulation.  Basically, SBC A, #0 in decimal
mode will result in non-decimal values if the lower four bits of A are zero. 
(So when A=20h and decimal is on and carry is set, SBC A, #0 yields A=1Fh
instead of A=19h) I think this line:

Ahh, that might explain why the Julian Date (or was it Calendar) applet in
Neolink acted weird when going negative in the VDLK. I never really looked into
it much. The plus side is that it does actually work properly on the watch. :)

> Yeah, it seems like the list of things to be fixed never ends...  Today it was
the alarm thing and the year zero thing...  Every time I add some new tweak or
fix to state 1 I have to reduce the code size by enough to fit the new code in. 
So far I've managed to find the space I need each time I need to fit something
in - but I'm always worried that I'll run out of places to scrounge up a few
bytes.

And now you're truly a Datalink USB developer. Welcome to the club. :)

>    Well, the main thing that has to happen in init is loading the record - so
I added code so the app (again) does that any time there's state entry into
state 1.  So for now I do that and it seems to work.  At the moment this also
means that I load the event twice on startup (once in the banner state, once in
state 1) - which basically sucks, but that's more or less how it has to be right
now.

You could set a bit in the ASD if you're coming from the banner state, and then
hit a STATE_ENTRY, and clear it afterwards. It'll prevent the double-load at
least, even if it doesn't solve the code-location issue.

>    In general I've just got to have a better idea of what data I can rely on
remaining safe during a background event, and what sort of conditions I'll see
when the event is over...  I'm guessing COREForegroundCommonBuffer isn't
touched, and the ASD for my app should remain intact as well...  Not much I
could do if my code got overwritten, though.

I'm pretty sure it's just the Work/Scroll buffer, and potentially the background
buffer (if you happen to be using that). It shouldn't muck with your ASD, or
your foreground buffer, unless it's being very naughty. Or it was designed to do
otherwise (I've written a wristapp app like that before).

In theory it shouldn't nuke your code, but that's only if there isn't a bug in
the ROM. And we both know how flawless that code is. :)

>    I'll have to see about getting or making a non-ROM app installed that does
a background event.  That's probably the easiest way to learn more about how
they work, and what I should do to try to prevent them from breaking my app.  :)

Take a look in the timex manual under the section about background handlers. It
talks about COREEVENT_{DAY,HOUR}_UPDATE, as a start, which get called at the
appropriate times to modes of the appointment/alarm type. If you look at Core.h,
it actually lists mode types E0-E3 as dependent on the PTZ data, but when I
tried it, I vaguely remember them as not all being equal. Here's some ramblings
from a few years ago when I was playing with it:
http://tech.groups.yahoo.com/group/timexdatalinkusbdevelop/message/572
http://tech.groups.yahoo.com/group/timexdatalinkusbdevelop/message/818

At the very least, it's a place to start for running an interrupting background
task, that clears memory.

-Tons

George wrote:
> --- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
>>[...]
>> Pascal is pretty straightforward (lots of examples around in the
>> code, for style/syntax), and you can get the Delphi toolchain/IDE for
>> free on their
>> site, which is what all the project files are in. But yeah, if you
>> want to port it to Linux, that would be amazing!
>
> I'm familiar with Pascal. I actually learned Turbo Pascal before I
> learned C. the problem is more that I don't have (or particularly want)
> a Windows box at home to develop on. I suppose it might be possible to
> run Delphi in WINE...

A long time ago I wanted to port VDLK to compile in Lazarus.

Lazarus is a free, open-source alternative do Delphi that has a lot of
things compatible with it.

What I expect to be harder to port is the USB HID direct interface to
the watch. The rest of the code should be pretty straightforward.

I don't have enough energy left to do the port myself, but if it is
something you would consider doing, I could help out if you hit some wall...

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"God is love. Love is blind. Ray Charles is blind. Ray Charles is God."

--- In timexdatalinkusbdevelop@yahoogroups.com, Paulo Marques <pmarques@...>
wrote:

> A long time ago I wanted to port VDLK to compile in Lazarus.
>
> Lazarus is a free, open-source alternative do Delphi that has a lot of
> things compatible with it.
>
> What I expect to be harder to port is the USB HID direct interface to
> the watch. The rest of the code should be pretty straightforward.
>
    Well, at the moment it's a bit of an idle fantasy...  But I may take it on at
some point.  I've relied pretty heavily on VDLK for my project (honestly, all
the things that have gone wrong with the app - I hate to think of how all that
would have gone down if I hadn't had VDLK.  It's hard to imagine how I would
have made any headway at all.) - as such it'd be neat to fix up some of the bugs
and limitations I've encountered.  That's probably not going to happen unless I
port it to Linux first.

    It's good to know Lazarus is there as an option.  The fact that it's an
attempt, at least to be Delphi-compatible means there's some chance I could
avoid rewriting the GUI.

    I've honestly never used the USB features of VDLK - luckily libdlusb also
incorporates the ROM-dumping functionality, so that was enough to get me up and
running.  Under WINE the VDLK menu for communicating with watch hardware is
greyed out because it's not detecting the watch when it's connected, so I don't
even know what the contents of that menu look like.  :)

> I don't have enough energy left to do the port myself, but if it is
> something you would consider doing, I could help out if you hit some wall...

I'm sure if I decide to port and/or enhance VDLK I'll post all about it on here.
:)

--- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
> >
> > Yeah, it seems like the list of things to be fixed never ends...  Today it
was the alarm thing and the year zero thing...  Every time I add some new tweak
or fix to state 1 I have to reduce the code size by enough to fit the new code
in.  So far I've managed to find the space I need each time I need to fit
something in - but I'm always worried that I'll run out of places to scrounge up
a few bytes.
>
> And now you're truly a Datalink USB developer. Welcome to the club. :)

Ha!  I should get a tattoo that says "900 byte overlay"

> >    Well, the main thing that has to happen in init is loading the record -
so I added code so the app (again) does that any time there's state entry into
state 1.  So for now I do that and it seems to work.  At the moment this also
means that I load the event twice on startup (once in the banner state, once in
state 1) - which basically sucks, but that's more or less how it has to be right
now.
>
> You could set a bit in the ASD if you're coming from the banner state, and
then hit a STATE_ENTRY, and clear it afterwards. It'll prevent the double-load
at least, even if it doesn't solve the code-location issue.

Well, two issues with that:

Right now, loading the current event in state 1 is just two code bytes: CARS to
the relevant routine in the background handler.  (One of these days I will have
to try to determine if my app's background handler is fully restored when I
return from a background event...)  Conditionalizing that code will add code
size.  I'd rather not load the event twice but my feelings on that point aren't
so strong that I'd rather use another use an additional four bytes of program
code to avoid it.

Second, there is the possibility that a background task messing with
COREWorkBuffer would set those bytes in a way that indicates (to my app) that
the record is already loaded...  Or (perhaps more likely) leave them alone, in
which case their previous state (indicating that the record is already loaded)
would continue to hold even as other areas of the COREWorkBuffer get
overwritten.

If my app gets an app exit event (there is one of those, right?) when a
background task takes over, then I could use that to set something that
indicates the record will have to be loaded again when the background task is
done - but that, too would be more code.  At this point I can't afford even a
single additional byte of code in state 1 unless I trim down something else.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the timexdatalinkusbdevelop
group.

   File        : /WristApps/t_minus_v1.0_src.tgz
   Uploaded by : georgecaswell@... <gec144@...>
   Description : Source code for "T-Minus" deadline counter

You can access this file at the URL:
http://groups.yahoo.com/group/timexdatalinkusbdevelop/files/WristApps/t_minus_v1\
.0_src.tgz

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.html
Regards,

georgecaswell@... <gec144@...>

People:

I'm trying to set "daylight savings time" on my watch.

I use the libdlusb command:

tod_dlusb tz1=PST-08:00 observe_dst1=yes dst1=yes

... but it doesn't change the time by an hour.

I looked at the code and the Timex PDF files, and it all looks good.

I get the impression that the "observe_dst1" and the "dst1" don't do what I
think they do.

What do these flags do?

Cheers,
Ken

I was experimenting with decimal mode (unpacked) on the actual watch, using my
DEBUG program. The flags appear to react identically to packed mode (except
based on the low nybble). Here are some examples, using ADD A,B:

20 + D0 = 00. NVC clear. Z set.
30 + D0 = 00. NVC clear. Z set.
40 + D0 = 00. NVC clear. Z set.
07 + 01 = 08. NVCZ clear.
07 + 02 = 09. NVCZ clear.
07 + 08 = 05. NVZ clear. C set.
C7 + 52 = 09. NVCZ clear.

According to the S1C88 Core CPU Manual, 2.2.5, page 11 examples, C7+52 should
have resulted in the N and V flags being set, but they weren't. If I'm
understanding what the manual was saying, my 30+D0 and 40+D0 examples should
have set the V flag. And my 07+08 example should have set the N flag. To me,
these results seem to indicate that the manual is incorrect and that N and V are
always 0, as in packed mode.

Here is the program I entered:
F257: 9F  ; LD  SC,#30   Set decimal and unpack flags. clear all other flags
F258: 30
F259: C4  ; LD  BA,#52C7 Set A=C7, B=52.
F25A: C7
F25B: 52
F25C: 01  ; ADD A,B      Set A=A+B, and flags.
F25D: 9C  ; AND SC,#CF   Clear decimal and unpack flags, leave other flags
unchanged.
F25E: CF
F25F: F8  ; RET          Return to DEBUG

Then, I returned to address F257 and pressed Start/Split to run it. Results are
as above. A was set to 09 and none of the NVCZ flags were set.

I was curious whether there was a bug in my debugger, so I coded this:
F25D: 9F  ; LD  SC,#0F
F25E: 0F
and that resulted in all of NVCZ flags being set, so I know my debugger will
report the N and V flags if they were set.

Have I made any errors?

Thanks,
calamari

I think it seems worth experimenting with unpacked and decimal separately to
start with, as it seems less confusing. I know how decimal works, and just read
through the few paragraphs on unpacked. If I understand it properly, it's
basically a way to get 4-bit operations working simply - it will always clear
the upper nybble, and only set flags based on the lower ones. Seemes
straightforward enough.

I agree with you that your output differs from that of the manual, but I'm
assuming the manual is only talking about the unpacked flag being set, and not
decimal. This would have been clearer if they'd made one of their ADD A,B
examples end in A-F.

However, since you *also* have decimal set, it seems like the extra information
from that is relevant. Specifically, according to the left-column on page 10:

Following execution of the decimal opteration, the N/V/C/Z flags of the SC are
set according to the operation result, as shown below:

N: Always Reset (0)
V: Always Reset (0)
C: When there has been a carry from the 2-digit decimal value or a borrow to the
2-digit decimal value Set (1)
    When there has not been Reset (0)
Z: When the operation result = 0 Set (1)
    When the operation result != 0 Reset (0)

When both the decimal and unpacked are set, C/Z seem like they need to change to
be more like in the unpack instructions, and only be concerned with the lower 4
bits (in decimal format, for C), but that N/V will remain zero always, to match
what the normal decimal mode is like.

That seems like it also agrees with the results you've experienced - yes, N and
V are always 0, but not "as when in packed mode" as you suggest, but "as when in
*decimal* packed mode".

Or, at least, that's my interpretation of the CPU reference manual.

Hope that helps.

-Tons




--- In timexdatalinkusbdevelop@yahoogroups.com, "calamari" <jeffryjohnston@...>
wrote:
>
> I was experimenting with decimal mode (unpacked) on the actual watch, using my
DEBUG program. The flags appear to react identically to packed mode (except
based on the low nybble). Here are some examples, using ADD A,B:
>
> 20 + D0 = 00. NVC clear. Z set.
> 30 + D0 = 00. NVC clear. Z set.
> 40 + D0 = 00. NVC clear. Z set.
> 07 + 01 = 08. NVCZ clear.
> 07 + 02 = 09. NVCZ clear.
> 07 + 08 = 05. NVZ clear. C set.
> C7 + 52 = 09. NVCZ clear.
>
> According to the S1C88 Core CPU Manual, 2.2.5, page 11 examples, C7+52 should
have resulted in the N and V flags being set, but they weren't. If I'm
understanding what the manual was saying, my 30+D0 and 40+D0 examples should
have set the V flag. And my 07+08 example should have set the N flag. To me,
these results seem to indicate that the manual is incorrect and that N and V are
always 0, as in packed mode.
>
> Here is the program I entered:
> F257: 9F  ; LD  SC,#30   Set decimal and unpack flags. clear all other flags
> F258: 30
> F259: C4  ; LD  BA,#52C7 Set A=C7, B=52.
> F25A: C7
> F25B: 52
> F25C: 01  ; ADD A,B      Set A=A+B, and flags.
> F25D: 9C  ; AND SC,#CF   Clear decimal and unpack flags, leave other flags
unchanged.
> F25E: CF
> F25F: F8  ; RET          Return to DEBUG
>
> Then, I returned to address F257 and pressed Start/Split to run it. Results
are as above. A was set to 09 and none of the NVCZ flags were set.
>
> I was curious whether there was a bug in my debugger, so I coded this:
> F25D: 9F  ; LD  SC,#0F
> F25E: 0F
> and that resulted in all of NVCZ flags being set, so I know my debugger will
report the N and V flags if they were set.
>
> Have I made any errors?
>
> Thanks,
> calamari
>

Ken,

Sorry for the delay, I don't check the developer forums here as often as I used
to, since they've had much less traffic.

I honestly couldn't tell you what the flags do. I remember looking at them at
one point when doing some work with Neolink and DST, but couldn't find anywhere
they were used. They definitely don't cause your watches' time to change
automatically. Rather, I think it was something set in the application to have
it output, for example, EDT instead of EST. I believe the PIM software would
change it when you re-synced after the changes, bit I rarely sync.

Auto-adjust might also have been a feature that they wanted to get working, but
never actually finished in the initial release. It's hard to say for certain.
But I will ask what it is you're trying to do. If you want your watch to
auto-adjust for DST, there's already a wristapp that does that! :)

-Tons

--- In timexdatalinkusbdevelop@yahoogroups.com, "popeye22202" <kjh@...> wrote:
>
> People:
>
> I'm trying to set "daylight savings time" on my watch.
>
> I use the libdlusb command:
>
> tod_dlusb tz1=PST-08:00 observe_dst1=yes dst1=yes
>
> ... but it doesn't change the time by an hour.
>
> I looked at the code and the Timex PDF files, and it all looks good.
>
> I get the impression that the "observe_dst1" and the "dst1" don't do what I
think they do.
>
> What do these flags do?
>
> Cheers,
> Ken
>

Roger,

Yes, I believe you mentioned this in the past. However, when I contacted you for
more details, you never provided any. I think you're the only one who reported
any issues - and I've had it working on a couple of watches for the past couple
of years.

I'm not clear when you say different version of Window OSes - you're using
multiple watches *and* multiple OSes? Is it the same software, or have they been
configured differently? It could be related to that - perhaps one of them
doesn't have the DST adjust toggled? Without something repeatable, or even
anywhere to begin, as the only symptom is "it doesn't work", which could
similarly be PEBKAC, it's virtually impossible to track down.

-Tons


--- In timexdatalinkusbdevelop@yahoogroups.com, Roger Mera <roger_mera@...>
wrote:
>
> *You are refering to your Appl.Neolink. I have the experience that the Auto
Summer/Winter Time Zone change not always work on some of my Datalink Usb(I have
severals)the change are working but not on my others, maybe it has something to
do with version of the Windows OS that was used on the PC when I was transfering
the Neolink appl.into the watch..?(I do not have any clue what causing this
difference..).
>
>
>
>
> ________________________________
>  FrAYENn: Tons <tonsofquestions@...>
> Till: timexdatalinkusbdevelop@yahoogroups.com
> Skickat: mAYENndag, 9 april 2012 23:49
> A*mne: [timexdatalinkusbdevelop] Re: Setting "daylight savings time" with
libdlusb tod_dlusb
>
>
>
> A

>
> Ken,
>
> Sorry for the delay, I don't check the developer forums here as often as I
used to, since they've had much less traffic.
>
> I honestly couldn't tell you what the flags do. I remember looking at them at
one point when doing some work with Neolink and DST, but couldn't find anywhere
they were used. They definitely don't cause your watches' time to change
automatically. Rather, I think it was something set in the application to have
it output, for example, EDT instead of EST. I believe the PIM software would
change it when you re-synced after the changes, bit I rarely sync.
>
> Auto-adjust might also have been a feature that they wanted to get working,
but never actually finished in the initial release. It's hard to say for
certain. But I will ask what it is you're trying to do. If you want your watch
to auto-adjust for DST, there's already a wristapp that does that! :)*
> *You are refering to your Appl.Neolink. I have the experience that the Auto
Summer/Winter Time Zone change not always work on some of my Datalink Usb(I have
severals)the change are working but not on my others, maybe it has something to
do with version of the Windows OS that was used on theA
PC when I was
transfering the Neolink appl.into the watch..?(I do not have any clue what
causing this difference..).
>
> -Tons
>
> --- In timexdatalinkusbdevelop@yahoogroups.com, "popeye22202" <kjh@> wrote:
> >
> > People:
> >
> > I'm trying to set "daylight savings time" on my watch.
> >
> > I use the libdlusb command:
> >
> > tod_dlusb tz1=PST-08:00 observe_dst1=yes dst1=yes
> >
> > ... but it doesn't change the time by an hour.
> >
> > I looked at the code and the Timex PDF files, and it all looks good.
> >
> > I get the impression that the "observe_dst1" and the "dst1" don't do what I
think they do.
> >
> > What do these flags do?
> >
> > Cheers,
> > Ken
> >
>

David,

Firstly, this is meant as the developer group, so really isn't the best location
to ask this. I'd suggest looking in the general users group, here:
http://groups.yahoo.com/group/timexdatalinkusb/

Secondly, I suggest try searching:
http://tech.groups.yahoo.com/group/timexdatalinkusb/msearch_adv

since this very question was commented on just a few days ago:
http://tech.groups.yahoo.com/group/timexdatalinkusb/message/14028

-Tons

--- In timexdatalinkusbdevelop@yahoogroups.com, David Dziadek <speedog40@...>
wrote:
>
>
>
>
>
> Has anyone found a source for a watchband for a Timex datalink USB model 851.
I have searched all over. Attached is a picture of the watch and band.
>

Unfortunately, no, it doesn't help too much. It's a little more specific, but
I've definitely seen situations where the software doesn't rensend some things
to the watch, since it thinks it already has everything. For example, Neolink
tries to preserve your current config/database, so unless you change the DST
settings after the watch->PC sync, it might not update them. Forcing the IM
software to resend Neolink from scratch might work, as well, but it's not always
obvious if it does so.

Note that the Datalink Software isn't really designed to sync with multiple
watches, and it can sometimes get confused. The same happens if you try to sync
one watch with multiple computers/installs. It's better to use separate
installs, or separate computers for each watch to avoid these problems. I
recommend a USB stick, since you can then sync on multiple computers, but use
the same application folder. There are some instructions in the main group's
files section.

The thing that would help the most is an image from the watch taken through the
VDLK, but that's probably more effort than you'd like, and it would also include
all the data on the watch - contacts, appointments, etc. If you were to wipe and
sync to get a fresher one, it wouldn't be clear whether it actually
self-adjusted for DST or not.

I hope that helps clarify a little.

-Tons

--- In timexdatalinkusbdevelop@yahoogroups.com, Roger Mera <roger_mera@...>
wrote:
>
> Tons,
> The strange thing is that they was configured from the same Datalink software
from the same computer PC (&OS)the only thing that was set different (as I can
remember)was the combinations of apps.set into the watch itself. Also in the
watch that the auto time change was working it also showed a dotted line(or
bars) showing the weekdays counting down to a appointment(or likewise do not
recall exactly what was indicated). Hope this was more precisely explained.
> /Roger
>
>
> ________________________________
>  FrAYENn: Tons <tonsofquestions@...>
> Till: timexdatalinkusbdevelop@yahoogroups.com
> Skickat: tisdag, 10 april 2012 1:16
> A*mne: SV: [timexdatalinkusbdevelop] Re: Setting "daylight savings time" with
libdlusb tod_dlusb
>
>
>
> A

>
> Roger,
>
> Yes, I believe you mentioned this in the past. However, when I contacted you
for more details, you never provided any. I think you're the only one who
reported any issues - and I've had it working on a couple of watches for the
past couple of years.
>
> I'm not clear when you say different version of Window OSes - you're using
multiple watches *and* multiple OSes? Is it the same software, or have they been
configured differently? It could be related to that - perhaps one of them
doesn't have the DST adjust toggled? Without something repeatable, or even
anywhere to begin, as the only symptom is "it doesn't work", which could
similarly be PEBKAC, it's virtually impossible to track down.
>
> -Tons
>
> --- In timexdatalinkusbdevelop@yahoogroups.com, Roger Mera <roger_mera@>
wrote:
> >
> > *You are refering to your Appl.Neolink. I have the experience that the Auto
Summer/Winter Time Zone change not always work on some of my Datalink Usb(I have
severals)the change are working but not on my others, maybe it has something to
do with version of the Windows OS that was used on the PC when I was transfering
the Neolink appl.into the watch..?(I do not have any clue what causing this
difference..).
> >
> >
> >
> >
> > ________________________________
> >  FrAYENn: Tons <tonsofquestions@>
> > Till: timexdatalinkusbdevelop@yahoogroups.com
> > Skickat: mAYENndag, 9 april 2012 23:49
> > A*mne: [timexdatalinkusbdevelop] Re: Setting "daylight savings time" with
libdlusb tod_dlusb
> >
> >
> >
> > A
> >
> > Ken,
> >
> > Sorry for the delay, I don't check the developer forums here as often as I
used to, since they've had much less traffic.
> >
> > I honestly couldn't tell you what the flags do. I remember looking at them
at one point when doing some work with Neolink and DST, but couldn't find
anywhere they were used. They definitely don't cause your watches' time to
change automatically. Rather, I think it was something set in the application to
have it output, for example, EDT instead of EST. I believe the PIM software
would change it when you re-synced after the changes, bit I rarely sync.
> >
> > Auto-adjust might also have been a feature that they wanted to get working,
but never actually finished in the initial release. It's hard to say for
certain. But I will ask what it is you're trying to do. If you want your watch
to auto-adjust for DST, there's already a wristapp that does that! :)*
> > *You are refering to your Appl.Neolink. I have the experience that the Auto
Summer/Winter Time Zone change not always work on some of my Datalink Usb(I have
severals)the change are working but not on my others, maybe it has something to
do with version of the Windows OS that was used on theAPC when I was transfering
the Neolink appl.into the watch..?(I do not have any clue what causing this
difference..).
> >
> > -Tons
> >
> > --- In timexdatalinkusbdevelop@yahoogroups.com, "popeye22202" <kjh@> wrote:
> > >
> > > People:
> > >
> > > I'm trying to set "daylight savings time" on my watch.
> > >
> > > I use the libdlusb command:
> > >
> > > tod_dlusb tz1=PST-08:00 observe_dst1=yes dst1=yes
> > >
> > > ... but it doesn't change the time by an hour.
> > >
> > > I looked at the code and the Timex PDF files, and it all looks good.
> > >
> > > I get the impression that the "observe_dst1" and the "dst1" don't do what
I think they do.
> > >
> > > What do these flags do?
> > >
> > > Cheers,
> > > Ken
> > >
> >
>

Roger,

If you're going to reply separately, it makes sense to do the inline comments in
that as well, rather than separately, since otherwise it gets a little
confusing. I almost didn't see your comments, but perhaps it was the fault of my
browser.

For the installation on the USB stick, see the instructions in this
file:http://tech.groups.yahoo.com/group/timexdatalinkusb/files/MobileStart.txt


It's been a while since I played with the Neolink configuration tool, but I
tried to make it as preserving as possible. The best way to tell would be to
open up the settings it up right before syncing with the watch, and looking at
the DST tab. If it's set, that's what should get sent to the watch. If it's
disabled, or the data is wrong, that could be the cause of the problem.

You are right, however, that the software works poorly with multiple watches and
sets of data. I haven't played with it enough to try, though, so it's entirely
possible that if the initial sync is made from the same installation, and you
aren't syncing elsewhere, that it might handle it and just be internally
confused.

It would definitely be an interesting experiment to see if the failed DST
adjusts were tied to just a single watch, or perhaps a single installation. If
the former, there's a possibility of a hardware issue, but I'd think that might
cause other problems, as well, which it doesn't sound like you had.

But, in the end, I think it comes down primarily to the fact that I don't have a
reproducible test case, and you're the only one who's reported it. Without more
details or evidence, I think there's little I can do than attribute it to
sun-spots. :(


--- In timexdatalinkusbdevelop@yahoogroups.com, Roger Mera <roger_mera@...>
wrote:
>
> Tons,
> "Note that the Datalink Software isn't really designed to sync with multiple
watches,.."
> This not even work as if you try the software "senses"that it is not the same
watch and therefore it won`t sync and ask if you would like to replace the data
in the watch or not sync at all. I have had the Neolink app.on 2 different
computer and in two different(and once even 3)watches, in the oldest
computer(Windows XP OS) I think I had the Auto Summer Time change to work
several times(but not in one watch..strangely) but not in the newest PC(with
Windows 7 OS).
> The "behavoir"are some kind of"enigma" to me not explained by any possible
factor.
>
>
> ________________________________
>  Från: Tons <tonsofquestions@...>
> Till: timexdatalinkusbdevelop@yahoogroups.com 
> Skickat: tisdag, 10 april 2012 18:13
> Ämne: SV: [timexdatalinkusbdevelop] Re: Setting "daylight savings time" with
libdlusb tod_dlusb
>
>
>
>  
>
> Unfortunately, no, it doesn't help too much. It's a little more specific, but
I've definitely seen situations where the software doesn't rensend some things
to the watch, since it thinks it already has everything. For example, Neolink
tries to preserve your current config/database, so unless you change the DST
settings after the watch->PC sync, it might not update them. Forcing the IM
software to resend Neolink from scratch might work, as well, but it's not always
obvious if it does so.
>
> Note that the Datalink Software isn't really designed to sync with multiple
watches, and it can sometimes get confused. The same happens if you try to sync
one watch with multiple computers/installs. It's better to use separate
installs, or separate computers for each watch to avoid these problems. I
recommend a USB stick, since you can then sync on multiple computers, but use
the same application folder. There are some instructions in the main group's
files section.
>
> The thing that would help the most is an image from the watch taken through
the VDLK, but that's probably more effort than you'd like, and it would also
include all the data on the watch - contacts, appointments, etc. If you were to
wipe and sync to get a fresher one, it wouldn't be clear whether it actually
self-adjusted for DST or not.
>
> I hope that helps clarify a little.
>
> -Tons
>
> --- In timexdatalinkusbdevelop@yahoogroups.com, Roger Mera <roger_mera@>
wrote:
> >
> > Tons,
> > The strange thing is that they was configured from the same Datalink
software from the same computer PC (&OS)the only thing that was set different
(as I can remember)was the combinations of apps.set into the watch itself. Also
in the watch that the auto time change was working it also showed a dotted
line(or bars) showing the weekdays counting down to a appointment(or likewise do
not recall exactly what was indicated). Hope this was more precisely explained.
> > /Roger
> >
> >
> > ________________________________
> >  FrAYENn: Tons <tonsofquestions@>
> > Till: timexdatalinkusbdevelop@yahoogroups.com
> > Skickat: tisdag, 10 april 2012 1:16
> > A*mne: SV: [timexdatalinkusbdevelop] Re: Setting "daylight savings time"
with libdlusb tod_dlusb
> >
> >
> >
> > A
> >
> > Roger,
> >
> > Yes, I believe you mentioned this in the past. However, when I contacted you
for more details, you never provided any. I think you're the only one who
reported any issues - and I've had it working on a couple of watches for the
past couple of years.
> >
> > I'm not clear when you say different version of Window OSes - you're using
multiple watches *and* multiple OSes? Is it the same software, or have they been
configured differently? It could be related to that - perhaps one of them
doesn't have the DST adjust toggled? Without something repeatable, or even
anywhere to begin, as the only symptom is "it doesn't work", which could
similarly be PEBKAC, it's virtually impossible to track down.
> >
> > -Tons
> >
> > --- In timexdatalinkusbdevelop@yahoogroups.com, Roger Mera <roger_mera@>
wrote:
> > >
> > > *You are refering to your Appl.Neolink. I have the experience that the
Auto Summer/Winter Time Zone change not always work on some of my Datalink Usb(I
have severals)the change are working but not on my others, maybe it has
something to do with version of the Windows OS that was used on the PC when I
was transfering the Neolink appl.into the watch..?(I do not have any clue what
causing this difference..).
> > >
> > >
> > >
> > >
> > > ________________________________
> > >  FrAYENn: Tons <tonsofquestions@>
> > > Till: timexdatalinkusbdevelop@yahoogroups.com
> > > Skickat: mAYENndag, 9 april 2012 23:49
> > > A*mne: [timexdatalinkusbdevelop] Re: Setting "daylight savings time" with
libdlusb tod_dlusb
> > >
> > >
> > >
> > > A
> > >
> > > Ken,
> > >
> > > Sorry for the delay, I don't check the developer forums here as often as I
used to, since they've had much less traffic.
> > >
> > > I honestly couldn't tell you what the flags do. I remember looking at them
at one point when doing some work with Neolink and DST, but couldn't find
anywhere they were used. They definitely don't cause your watches' time to
change automatically. Rather, I think it was something set in the application to
have it output, for example, EDT instead of EST. I believe the PIM software
would change it when you re-synced after the changes, bit I rarely sync.
> > >
> > > Auto-adjust might also have been a feature that they wanted to get
working, but never actually finished in the initial release. It's hard to say
for certain. But I will ask what it is you're trying to do. If you want your
watch to auto-adjust for DST, there's already a wristapp that does that! :)*
> > > *You are refering to your Appl.Neolink. I have the experience that the
Auto Summer/Winter Time Zone change not always work on some of my Datalink Usb(I
have severals)the change are working but not on my others, maybe it has
something to do with version of the Windows OS that was used on theAPC when I
was transfering the Neolink appl.into the watch..?(I do not have any clue what
causing this difference..).
> > >
> > > -Tons
> > >
> > > --- In timexdatalinkusbdevelop@yahoogroups.com, "popeye22202" <kjh@>
wrote:
> > > >
> > > > People:
> > > >
> > > > I'm trying to set "daylight savings time" on my watch.
> > > >
> > > > I use the libdlusb command:
> > > >
> > > > tod_dlusb tz1=PST-08:00 observe_dst1=yes dst1=yes
> > > >
> > > > ... but it doesn't change the time by an hour.
> > > >
> > > > I looked at the code and the Timex PDF files, and it all looks good.
> > > >
> > > > I get the impression that the "observe_dst1" and the "dst1" don't do
what I think they do.
> > > >
> > > > What do these flags do?
> > > >
> > > > Cheers,
> > > > Ken
> > > >
> > >
> >
>

> First,Thank`s for taking your time for detailed answering..

Absolutely. That's why I'm still part of this community. :)

> " If it's disabled, or the data is wrong, that could be the cause of the
problem."
> No,it was enabled..!

Well, I believe you (or maybe there was another issue?) said it went the wrong
way at one point. Which makes me think of configuration issues. So, it could be
enabled, but if it's set for the wrong day/month/direction of year, I can see it
doing something else.

> One possible explaination might be it depends which configuration Neolink are
set together with other application installed into the watch depending if the
auto correction works or not..?

I'd be very surprised at that, but it's not entirely impossible. Another app
could corrupt the wrong section of memory. Neolink also needs to be in the TOD
at some point during the day to do the adjustment. I tried to be as intelligent
about it as possible, but there is a chance I missed some scenario. Certainly if
you're out of the TOD for more than a day, or manually set (or sync) the time
sometime across the daylight saving boundary, it could get confused. I think I
tried to make it clear out the adjustment in those cases, as the user would know
better than it.

> However I have had some issues with the Value app.(among others)working in one
Datalink watch but not together with another one(there it was causing the watch
to"die" forcing me to do a hard reset aterwards to make it work normally again..

That sounds very strange, indeed. The value app is very simple, and should not
be causing any crashes, unless you've got some other poorly written software on
the watch.

> Otherwise I really appreciate your Neolink appl.capacity to be able to autoset
the Summer/Winter time!

I'm glad to hear it's been of use to you. Hopefully there are other features you
enjoy, as well. :)

-Tons

Yep, looks like you've solved it! Thanks!
calamari

--- In timexdatalinkusbdevelop@yahoogroups.com, "Tons" <tonsofquestions@...>
wrote:
>
> I think it seems worth experimenting with unpacked and decimal separately to
start with, as it seems less confusing. I know how decimal works, and just read
through the few paragraphs on unpacked. If I understand it properly, it's
basically a way to get 4-bit operations working simply - it will always clear
the upper nybble, and only set flags based on the lower ones. Seemes
straightforward enough.
>
> I agree with you that your output differs from that of the manual, but I'm
assuming the manual is only talking about the unpacked flag being set, and not
decimal. This would have been clearer if they'd made one of their ADD A,B
examples end in A-F.
>
> However, since you *also* have decimal set, it seems like the extra
information from that is relevant. Specifically, according to the left-column on
page 10:
>
> Following execution of the decimal opteration, the N/V/C/Z flags of the SC are
set according to the operation result, as shown below:
>
> N: Always Reset (0)
> V: Always Reset (0)
> C: When there has been a carry from the 2-digit decimal value or a borrow to
the 2-digit decimal value Set (1)
>    When there has not been Reset (0)
> Z: When the operation result = 0 Set (1)
>    When the operation result != 0 Reset (0)
>
> When both the decimal and unpacked are set, C/Z seem like they need to change
to be more like in the unpack instructions, and only be concerned with the lower
4 bits (in decimal format, for C), but that N/V will remain zero always, to
match what the normal decimal mode is like.
>
> That seems like it also agrees with the results you've experienced - yes, N
and V are always 0, but not "as when in packed mode" as you suggest, but "as
when in *decimal* packed mode".
>
> Or, at least, that's my interpretation of the CPU reference manual.
>
> Hope that helps.
>
> -Tons
>
>
>
>
> --- In timexdatalinkusbdevelop@yahoogroups.com, "calamari" <jeffryjohnston@>
wrote:
> >
> > I was experimenting with decimal mode (unpacked) on the actual watch, using
my DEBUG program. The flags appear to react identically to packed mode (except
based on the low nybble). Here are some examples, using ADD A,B:
> >
> > 20 + D0 = 00. NVC clear. Z set.
> > 30 + D0 = 00. NVC clear. Z set.
> > 40 + D0 = 00. NVC clear. Z set.
> > 07 + 01 = 08. NVCZ clear.
> > 07 + 02 = 09. NVCZ clear.
> > 07 + 08 = 05. NVZ clear. C set.
> > C7 + 52 = 09. NVCZ clear.
> >
> > According to the S1C88 Core CPU Manual, 2.2.5, page 11 examples, C7+52
should have resulted in the N and V flags being set, but they weren't. If I'm
understanding what the manual was saying, my 30+D0 and 40+D0 examples should
have set the V flag. And my 07+08 example should have set the N flag. To me,
these results seem to indicate that the manual is incorrect and that N and V are
always 0, as in packed mode.
> >
> > Here is the program I entered:
> > F257: 9F  ; LD  SC,#30   Set decimal and unpack flags. clear all other flags
> > F258: 30
> > F259: C4  ; LD  BA,#52C7 Set A=C7, B=52.
> > F25A: C7
> > F25B: 52
> > F25C: 01  ; ADD A,B      Set A=A+B, and flags.
> > F25D: 9C  ; AND SC,#CF   Clear decimal and unpack flags, leave other flags
unchanged.
> > F25E: CF
> > F25F: F8  ; RET          Return to DEBUG
> >
> > Then, I returned to address F257 and pressed Start/Split to run it. Results
are as above. A was set to 09 and none of the NVCZ flags were set.
> >
> > I was curious whether there was a bug in my debugger, so I coded this:
> > F25D: 9F  ; LD  SC,#0F
> > F25E: 0F
> > and that resulted in all of NVCZ flags being set, so I know my debugger will
report the N and V flags if they were set.
> >
> > Have I made any errors?
> >
> > Thanks,
> > calamari
> >
>

I recently managed to brake the ear where the post for the band clips in. Is
there any possibility in fixing this reasonably?  Replacement bezel, sending it
somewhere, DIY, etc..  If not is there any other watches anyone may suggest??

Thanks
Scott

Scott,

This is the developer forum, and this question is really more geared towards
general users. I've responded to you over there:
http://tech.groups.yahoo.com/group/timexdatalinkusb/message/14068

-Tons

--- In timexdatalinkusbdevelop@yahoogroups.com, "userswark" <sdwark@...> wrote:
>
> I recently managed to brake the ear where the post for the band clips in. Is
there any possibility in fixing this reasonably?  Replacement bezel, sending it
somewhere, DIY, etc..  If not is there any other watches anyone may suggest??
>
> Thanks
> Scott
>

I tried to download the developers kit from:
http://assets.timex.com/developer/datalink/index.htm but it errors out when I
hit the "I accept" button.  Anyone know where I can download the programs?

Thanks
Chuck