Thread: Garmin 12XX drawing problem

Did you hard reset it after update? 'First Aid' for any weird behaviour. [Hold lower RH corner as turn unit on].

The only issue I see is that the map drawing speed is too slow.

You can try erasing NV ("ergn,41" command in update.txt, read [Only registered and activated users can see links. ]) and formatting the internal flash drive (while making backups, of course. read [Only registered and activated users can see links. ]), and copying back the minimal number of files that are required for the unit firmware to run normally. I guess, the only item you need is the Garmin folder. Everything else should be recreated by the unit firmware.
Thus you would erase most of the unit "life experience".

And then you can install the map of interest and see how it behaves.
If this fixes your issue you can restore the missing files from the backup or by running WebUpdater.

Also what is the target map? Are you building it on your own? Have you checked if this is the map issue by using other maps?

These Nuvi's are not famous for Quick Map Redraw the 1300 is also sluggish.
Some Tips.
Install only the Map tiles That you need.
Remove Dem maps from unit and SD Card.
Remove all unused Maps from Unit and SD Card.
Remove all JCV files from Nuvi and SD Card.
As Kunix suggested. Remove Unused files from Nuvi. (Voices Texts etc etc)

No, defragmentation can even have a bad effect over a flash memory. Only applicable for a HDD.

BTW think it is possible a little overclock of the CPU.

I was informed of this opinion a while back by a friend who is a computer tech: "Defragging flash media is at best unnecessary. Flash does not have to 'dart all over' like mechanical drive seek heads do if the info is in non-adjoining clusters. Regardless of where the data is, in a flash drive the seek time is almost instantaneous. In fact, because of the built-in 'wear leveling' of flash drives defragging them can even be counter-productive and life-shortening". Just repeating what he told me in an email.

Neil, it depends on the technical details. Flash chips can only be read by pages (typical page size is 2048 or 4096 bytes), i.e. if you want to read a byte of some pages you have to wait for the whole page to be transferred. And if the filesystem cluster size is less than the page size, fragmentation could affect the reading performance.

For example let's imagine that the cluster size is 512 bytes and the page size is 2048 bytes.
Then the reading speed of an extremely fragmented file (i.e. each cluster of it belongs to a separate page) would be 2048/512=4 times slower than the reading speed of a totally defragmented file.

The writing speed is even more dependent on the fragmentation, as flash pages have to be erased before being rewritten, and only the whole block (typically a block is 32-128 pages) can be erased. That's why in the worst case we would have to rewrite 128*4096 bytes of flash in order to write 512 bytes. That would be a disaster.

Maybe this device is so slow because it's writing some file too slowly, who knows?

So without precise knowledge about the page size of the flash chip and the filesystem used I wouldn't be that sure.

Wow. i actually understood that. [Either i'm becoming more computer literate or you could moonlight as an instructor at the local tech college].