Notices

Thanks again, Nutter.

I think the hardware key problem is a bug that goes back to 1.4.7 and OS2007. I see the same problem with this configuration on the 770. If it's an easy fix for you to do, I would appreciate it. John may not want to resurrect a version that has been put on the shelf, so to speak.

LOL, that's right. I see John has little interest in touching MM1.4 again.

My Mod is basically to bring MM1.4 back to "modernization" to be useful . MM2.2 is just not for me, it's slow and keeps confusing me by rotating the maps. I'll check and see what I can do, I think 1.4 is kind of free to do any Mod.

It's possible that the card is being written to that many times, but it's incomprehensible to me that anyone would do that. It slows the whole app down by orders of magnitude. That's so inefficient that I still have doubts, but I'm not so interested that I'm willing to take the time to go through all the source code to verify it one way or the other.

I'm unsure of what you mean by rotating the maps. They don't rotate on mine unless I tell it to, and I prefer just keeping north up, so the maps are readable. Maybe you mean something else.

I just have the new mod version of MM1.4 done.

1. "Temporarily" fixed the hardware zoom key issue syzygy asked, now you can config MM1.4 zoom key to any keys. It's indeed an original MM1.4.7 bug.

2. Changed and optimized the memory allocation method during map tile downloading. The old method is really a crude one, only for concept proving, and it may cause crash during large area downloading.

3. Fixed a fatal issue in MM1.4.Mod.1 os2008 version, I did a dumb thing that I accidently delete the bluetooth DBus init code when cleaning up the ossoic DBus init routine, so the old 1.4 mod 1 version can't find GPS reciver. This problem is fixed now. os2006-2007 version doesn't have this issue.

To download the code, go to
http://code.google.com/p/mmpcmapper/downloads/list

I think we're close to there now. I will refine the file system to make it more "bullet prove", more robustic against "rouge" data. Then we will have a "perfect" MM1.4 working version.

I'm curios about that - is the "sync" (presumably an fsync(2) call?) in the gdbm code? Or in the MM application? That's not good to have on a flash fileystem - without it the operating system would be very much more efficient (as sgosnell already said earlier).

It's in the MM2.x application code. The old gdbm always sync the data with disk no matter how small change it is. The gdbm 1.8.3 seems to give user some choice and provides a sync command(basically fsync), you can choose to sync at your time.

The MM2.x does sync for each tile downloading. The structure of gdmb requires you to update data, hash table and header, not very good. But nevertheless, even you don't issue sync command, the gdbm will do a lot of flushing disk also since it has very little cache allocated.

As long as there's no explicit fsync(2) call (directly, or indirectly through e.g. fflush(3)), then the operating system itself is what determines when the data will be written to disk, and the application's/library's internal caching doesn't matter much (all disk writes go through the kernel's buffer cache, and when it's being physically written is determined by configured kernel parameters as well as by amount of available RAM).

Well, this is the source code:

in MM2.x(display.c)

if(++_curr_download == _num_downloads)
{
#ifndef MAPDB_SQLITE
if(_curr_repo->db)
gdbm_sync(_curr_repo->db);
#endif

In gdbm 1.8.3

void
gdbm_sync (dbf)
gdbm_file_info *dbf;
{

/* Initialize the gdbm_errno variable. */
gdbm_errno = GDBM_NO_ERROR;

/* Do the sync on the file. */
fsync (dbf->desc);

}

I may made a mistake by saying that it sync disk for each tile downloading. It may be for each downloading.

That looks like it does a sync when the download is complete, which it should do. I can't say for sure without seeing the complete source code in context, but ISTM that "if(++_curr_download == _num_downloads)" means don't do anything until the current download is the final download. One write per download is a far different thing than one write per tile. I don't think any competent coder would do a file write for every map tile.

That's probably one of the issue panning is slow. Even you downloading couple of tiles, it does a sync, which I really don't like.

Another thing MM2.x does a rotation calculation(even it doesn't rotate) for each display update, it slows down the speed as well.