On Fri, Apr 1, 2011 at 2:59 PM, Andy Allan <[email protected]> wrote: > On Thu, Mar 31, 2011 at 6:34 PM, Steve Ratcliffe <[email protected]> wrote: > >>> I'm happy to do some more experimentation / testing patches etc if you >>> can give me some things to try. >> >> Could you try the attached patch please. If it works it should take it >> up to 512M. >> >> If you need more than that there will have to be some experimentation to >> find out what is implemented. Actual devices ignore all this as far as I >> know. > > Initial testing is good - I got an image of 172M working fine. Thanks! > I haven't yet tested all the way to 512M. > > It would be great for me if images up to 2G in total were supported. > Next week I'll try Felix's suggestions of going via the mapsource > installer and see if I can generate large gmapsupp.img files that big > that Basecamp is happy with. That might give us some hints as to > what's ultimately possible.
I spent a few hours on this today, but I couldn't get the nsis installer working with large files - when I ran the .exe it would crash complaining the installer was corrupt. However, I did manage to get the nsis installer running and installed a small (~121M) .exe file, and then used Basecamp to re-export that as a gmapsupp.img (~173M, about 4k bigger than the one mkgmap produced). I've spotted two interesting things about it 1) Basecamp won't re-import it the manner that it imports a gmapsupp that mkgmap produces, which is annoying. 2) The values at OFF_HEADS and OFF_CYLINDERS are different and suggest the upper limits aren't what we think What's the etiquette for reverse engineering this stuff? Is it helpful for me to post e.g. "hd gmapsupp.img | head -n 20" or is that a bad idea? Cheers, Andy _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
