Loading ...
Sorry, an error occurred while loading the content.

Re: WIP on my first app for the M851

Expand Messages
  • George
    ... It seems it s not calling the timer 0 interrupt. Scrolling works if you call lcdPixelScrollMsg{Left|Right} yourself after setting up scrolling.
    Message 1 of 46 , Jan 1, 2012
    • 0 Attachment
      --- 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.
    • George
      ... 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
      Message 46 of 46 , Jan 6, 2012
      • 0 Attachment
        --- 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.
      Your message has been successfully submitted and would be delivered to recipients shortly.