Writing Amiga <-> PDA software

@kvasir

OK, back to writing this thing today. Re-doing from scratch, as I've found better ways of coding virtually every function I had in here. Plus I want to make it modular enough to support a GUI, when my skill approaches that level. Also, a complete re-write is surely easier than finding the missing semi-colon/ parenthesis/ wrong malloc() value/ whatever else could be wrong that is causing a workout of the GURU screen. Fun fun.. Going to actually flowchart the thing this time.

@kvasir

any chance you can get the iPhone working too .

@kvasir

For what it is worth I would LOVE to be able to use my Palm with the Amiga. While an Amiga version of the PALM desktop program would be the 'best' anything is a move in the right direction. Currently I have a Sony Clie PEG TJ37 that I use everyday and it would be nice to sync it with a new X1000. Keep up the good work!

@328gts

Unfortunately, I can only tinker with the gadgets that I own, and an Iphone isn't among them. :( (Impoverished student) Though I'm not trying to write an i/o program to do the synchronization/data transfer so much as convert the data when its already on the Amiga. Depending on the iphones data format (android is XML based, which would be really easy to deal with, as mentioned in some post or another above this one), and my skill with a hex editor, I might be able to get it to work. However, the only thing this proggy would do is convert PalmOS data to/from Iphone or android. Though it's designed to convert to/from existing Amiga applications that I already use for similar functions. (Palm date book to limpidclock events, palm address book to yam address book, not exacltly sure what the hell to do with the to-do list and memo pad, but they've proven useful enough to figure something out).
As far as the connection and syncing, I'm trying to steer away from that, as its pretty much re-inventing the wheel at this point. (several proggies on Aminet do this) However, after the data conversion routines are done, I could probably tinker about with the USB API (I use poseidan, unsure if anything is available with Anaiis/anails/however its spelled) and get an all-in-one package going, including a MUI GUI (perhaps something more rudimentary for people wanting pre-os2.x stuff), and even a complete desktop package. (after the conversion, this wouldn't be too difficult, as I can just use the conversion routines to write something a bit more in-line with my admittedly chaotic thought patterns)

For connection to Palm devices, the poseiden stack comes with PDAtransfer if using USB, and I believe Aminet has some rs-232 compatible stuff, too. (Might even be the same program, the guy who wrote Poseidan seems to have done alot of really good work in this area)

Though I'll try to kick up an Iphone, and an android phone, plug 'em into my usb, and see what happens. If I can transfer some data, I'll peek at it with a hex editor (as well as google what the Linux geeks doing the same are up to).

@AmigaSource

Thanx for that! :D as soon as I get something working right (which I've actually made alot of progress with today), I'll zap the code to my brother and see if he can't do an OS4.x compile of it. (He has an A1 w/ 4.1 I believe, as well as a Sony cli?, unsure of the model number, just that it has more buttons than my computer, a flip-up qwerty keyboard, a bunch of gadgets, and looks like it would hurt if dropped on your foot) In the meantime, I don't know if Spitfire2 would work on OS4? I'm not sure if the author is taking registrations, but the core desktop programs are still compatible with the .pdb files pdatransfer pulls over via usb. Just have to move them into the right directories via a script.

Finally figured out the porb I ran into. I'm used to malloc() setting the length of a string (not exactly what it does, but its useful for doing this). All I knew is I had x number of characters to stick into y array, so I'd use x=malloc(y). When x is a structure with several different long ints, and you assume malloc will automatically figure this out, bad bad bad things happen....
Anyway, bug fixed, I feel like an idiot, and am now watching the simpsons.

OK, FINALLY got this thing working a bit. At least as much as I'm going to tonight. Er.. This morning... (3AM in Wisconsin right now) Tracked down the memory leak, as I mentioned in the previous post. Fine-tuned things alot, and got working HTML code. (will post a sample on my site, as soon as I use something other than my personal login password database as a test file). Most of the time I was fine-tuning its HTML output. The HTML output (will add AmigaGuide, too) is just for reverse-engineering pdb files, as it shows various record and database header information, as well as the records themselves. Only ASCII characters are readable, of course. Anything else is displayed as its HEX value, and color-coded (blue is ASCII, green is HEX numbers). Got what I believe to be a nice chart display for the other stuff, including database and record attributes.
The next thing is polishing this up a little bit. The dates are still stored as 32-bit integers, using PalmODS time. As opposed to Amiga (or POSIX) time... Did you know there are EXACTLY 2,082,844,800 second between midnight, January 1, 1904 and midnight, January 1, 1970? Coincidentally, there's a variable in my source called pdaoffset that holds that exact value.... If I find the guy at Palm who decided 1904 was a better year than 1970, and thus disagreeing with 90% of the 32-bit machines that bother to keep track of time, I'm going to do something the mere mention of which will probably get some moderators attention....
Anyway, the time display is pretty much a stub job using ctime, and the (incredibly annoying) offset. While it works, I'm going to change that to separate day/month/year/hour/minute/second values (crammed together in an array, already have that set up). This way, re-arranging them in whatever order/language another program uses should be easy.
Also, while I like the HTML output, adding an AmigaGuide option for the same would be pretty easy, so why not?
And I have yet to torture test this. There's a few .pdb files that crashed before, I'll see if it either works or at least trips the error trapping with this one.

Then, its just a matter of developing a "language" for the conversion files. (general order is load the .pdb file, load the conversion file, read conversion instructions from it, dump out a .whatever file) Thinking some sort of markup language with some macros. Possibly binary, with a de/compression utility. Not that I'm worried about the space, but the binary stuff would be easier to handle in the program. Anyway, rambling as usual. Time for bed....

OK, done a bit more work on this. (Been kinda slow with it, craziness as usual interfering. Mostly the 3 year old wandering into my office, saying "shoot aliens?", and requiring me to fire up Alien Breed SE ) I uploaded the output so far, though its only AmigaGuide (Might have to right-click-download for that one, unless you have an AmigaGuide mime type set) and HTML output, designed to show record-by-record hex dumps for reference when writing scripts. I'm still determining the "language" for the scripts, the ideas I've had so far are a bit more complicated than needed.
So far, I'm thinking of 3 separate "sections" of the conversion scripts, being a header, read, and write section. The header just contains user level information (something like "this is a PalmOS to-do list", followed by generic information about the palmapp that wrote it). The read section creates variables, and loads them with the data according to the following script. The write section(s) write the file in whatever format its configured for. The output linked to above has really nothing to do with the conversion system, aside from making reverse-engineering .pdb files easier.
oh, this is the shell output:
Quote:

@kvasir

ok. 3rd rewrite now, but got a beta on aminet (here) that con convert the memo database into AmigaGuide. Also figured out how the categories work. Still alot of problems with it, it doesn't check whatever file you plug into it for consistancy, so if it's not a Palm database, its gonna crash. Well, it might not crash. But the odds are it will. I put it up there to see if theres any problems with anybodys memo database (the one called MemoDB.pdb), and for any suggestions. Useful ones. I already know to add error checking.
The "scripting" language is more for my convenience than anybody writing a script, but thats because I'm planning on writing a stand-alone GUI to write the scripts, so it shouldn't be too big a prob.

@kvasir

Got bored, and my brain is too insomnia-fried to code (I've learned better than to attempt it the hard way. Trashed a hard drive because of repeated incremental filenames being saved to HDD in a closed loop. Without closing the file pointer. Apparently FFS doesn't like that a whole lot....) Anyway, got some screengrabs of how the thing works so far.


PalmOS Memo Pad, converted to AmigaGuide


PalmOS To-Do list pad, converted to AmigaGuide


PalmOS Datebook to both AmigaGuide and Limpidclock .reminder files.
Still thinking about the best way to automate pda->limpidclock, without either destroying Amiga-entered input or resulting in double entries on every hotsync. Might whip up a quick program to insert date into the file, while checking for duplicates. Limpidclock seems to ignore ; commented lines, might be able to stick the palm records ID number on the limpid entries previous line or something.

EDIT: After another attack of insomnia, I got the datebookdb.pdb file converted sufficiently to export limpidclock and amigaguide files.

@kvasir

Nice one. Will that work with a Palm Zire 21?

@trixie

I don't see why it wouldn't, as the palm files seem pretty consistant from one rev to the next, at least throught 5.x. I had a palm m130 and a zire 71, both seemed to be similar. Though I've not pried into them with a hex editor, and both are kinda broken. (PDA's are NOT the kind of thing to have in your pocket when wrestling around with your drunken friends when nearby a brick wall..) Anyway, do you have a way to get the data onto an Amiga? (either a cradle with a serial port or a usb device on your miggy with a usb cradle) If so, just grab the last upload @ Aminet, and give it a shot! just remember to "setenv pdaconvert.cfg <path to wherever you put the conversions drawer>" first.
The converter is CLI based, to do the memo to amigaguide conversion is:
pdaconvert -i memodb.pdb -o ram:memo.guide -c guide

also, if you're syncing with a pc, you can always copy the file manually, by copying it to a floppy or e-mailing it, etc...
If you try this and have problems, PLEASE let me know. Also, as its still "under construction", you might want to avoid anything important running in the background. I've seen this thing crash & burn before, granted that was caused by a rookie mistake with the malloc() commmand...

@kvasir

great work! wish I could get my Palm Treo 680 working again as I'd love to get the info from it onto my miggy