On Fri, Apr 1, 2011 at 2:59 PM, Andy Allan <gravitystorm@gmail.com> wrote:
On Thu, Mar 31, 2011 at 6:34 PM, Steve Ratcliffe <steve@parabola.me.uk> 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