Monday, 22nd September, 2008
I’ve decided that I’m just way too busy with everything else in my life to do justice to DSmaps. The main difficulty, if I’m completely honest about it, is that because my day job involves writing a lot of code, the last thing I want to do in my spare time is write more code. I’ve also got a young family and a very time consuming sporting interest.
The obvious solution therefore is to let others take the reins. However, I’ve never been involved in the delivery end of an open source project before so I’m looking for suggestions on how best to do this. In the interests of QA I’d ideally like to maintain some sort of ‘editorial control’ over the project – even this is just to control the domain name and this blog. Please shout with your thoughts…
Thursday, 12th June, 2008
About two months ago, my family and I discovered that we were going to have to move house. This came quite out of the blue. We had been lead to believe that our lease would be renewed for another year, as would be the norm where I live. But then, unexpectedly, the owner decided to put the place on the market – some sort of rearrangement of his personal finances apparently. So with little time to spare we had to find somewhere else to live that wasn’t too far away, and then orchestrate the actual house move itself. We have small children so stuff like this is a bit of a stressful ordeal. And for a while we didn’t even have broadband!!! It has only been in the last couple of weeks that things have finally calmed down as we have started to find our feet in the new place. It has actually worked out well as it turns out, because we now have a much bigger house, on a nicer street, at a much lower rent!
Anyway, why am I tell you all this? Because, obviously, with all of this going on in my private life, I haven’t exactly been focussed on DSmaps for the last couple of months. That’s just the way it is when the person behind a home project has a very busy home life! The move has affected my day job too and I’m having to make up for that during the evenings. I can’t really apologise for it I’m afraid!
But suffice it to say that I haven’t abandoned you. My wife is my biggest (only?) fan and she constantly nags at me to finish the next release. So it will get done – my domestic happiness and sanity depends on it!
Monday, 24th March, 2008
It has taken a bit longer than I would have liked to finish 0.3a. The main reason for this is that I’ve had to roll my own UI widget library from scratch – not something I had anticipated doing. Sure, I could have used Woopsi. But having played around with it quite a bit, it wasn’t suitable for my purposes – the map panning and zooming effects that I do require that things happen a certain way with the VRAM banks, etc. And if I’m completely honest about it, I’m a bit of a control freak who likes things to work exactly how I want them to work! So I’ve ended up coding classes for panels, tab controls, buttons, labels, text boxes with pop-up keyboard, modal dialogs, etc., etc. I also had to spend a bit of time working out how to render anti-aliased text that was reasonably legible. Combine all of this with the fact that I’ve been really busy in my day job and personal life and you’ll hopefully understand the delay. Sorry!
Tuesday, 26th February, 2008
From comments posted to this blog, as well as discussion in various forums elsewhere, it seems that the top three most-requested features are:
- Search by placename, i.e. integrated geocoding.
- Pre-fetch of the map tiles for a particular location to allow offline viewing.
- Ability to pan and zoom using the stylus.
I propose tackling in this order and I’ve started looking at the options for geocoding. I’m currently leaning towards a web service provided by www.geonames.org. It seems to be comprehensive, fast, and totally free. One slight problem though is that when it returns co-ordinates for a place, it doesn’t suggest an appropriate zoom level for a map. I’m thinking of just guessing the best zoom based on the type of place (i.e. street, suburb, city, region, country, etc.) and the population, if available. But this isn’t always going to work very well so if anyone has any better ideas, please shout!
Some users continue to report file system corruption. Sure, this could be caused by something like a buffer overrun in my code, but I really don’t believe that it is. I have been using DSmaps for weeks on my R4DS, and in the last few days I have supplemented my test hardware with a second NDS and a CycloDS card. The plain and simple fact is that other than the issue with the creation of the top-level folder on FAT32 that was fixed in 0.2.1a, I haven’t got a sniff of file system corruption. I know however that a number of significant bugs have been fixed in libfat over the last few months, which I will incorporate into DSmaps as soon as the source is buildable from SourceForge. For the record: I’m absolutely not bagging libfat here in any way! It is an incredible piece of work, without which the homebrew community simply wouldn’t exist.
Wednesday, 20th February, 2008
This is a service release to address the file system corruption problems that have affected a very small number of users in recent days. You can download it from here. Two changes have been made:
- I have fixed a bug in the library that DSmaps uses to interact with the file system on the microSD card. At issue was a fairly obscure detail in the FAT file system specification, which results in the ‘rule’ for top-level folders being subtly different to other folders. The bug only affects the FAT32 variant of the file system. Judging from comments I’ve received and postings in various forums, this bug seems to have affected other homebrew projects too. So I’ve passed my fix to the maintainers of the library and I guess it may be included in their next release. That’s up to them.
- In getting familiar with the FAT specification, I’ve realised just how incredibly badly it accommodates long file names. I had no idea what a nasty hack it is. And supporting this hack adds considerable complexity to the file system library that DSmaps uses. All this complexity is completely shortcutted however if file names follow the ancient MS-DOS “filename.ext” pattern. As a result, I’ve changed the naming scheme for files in the tile cache so that they do just that. The upside for DSmaps users is better performance, less space used on your microSD card, and far less complexity to go wrong. The downside is that any files already in your tile cache will be silently ignored once you install this service release. It might be better to completely blow away your DSMAPS folder and start again.
As a service release, I haven’t made any other changes to DSmaps, i.e. there are no new features to play with. But now that these file system woes are hopefully behind me (it has taken two nights) I can get back to working on release 0.3a. Expect to see that in 2-3 weeks, and please keep those comments coming!
Tuesday, 19th February, 2008
I’ve traced the problem reported in the previous post. As I suspected, it is related to the type of file system on the microSD card. There appears to be an issue with the library routine that DSmaps invokes to create its working folder in the root of the microSD card. Using a little test program, I can consistently cause corruption when using FAT32 but never when using FAT16.
N.B. Most microSD cards come pre-formatted with the FAT16 file system, so unless you have re-formatted your card to FAT32, you will not be affected by this problem. That said, the standard caveats when using any pre-release software still apply.
To determine if you are affected, pop your microSD card into a PC and run the chkdsk command on the command line (if your card appears as the E: drive, the command syntax would be “chkdsk E:” – be careful to use the correct drive letter!). The first line of output from chkdsk will tell you the file system type, where “FAT” means that you’re using FAT16 and “FAT32” means you’re using FAT32. If file system corruption is reported, re-run the command in fix mode (following the previous example, the command syntax would be “chkdsk E: /F”).
I’ve contacted the original creator of the library I’m using, in an effort to get some help. With a bit of luck there will be a simple coding work-around, in which case I’ll issue a patched revision asap. In the meantime, if you are using FAT32 and want to try out DSmaps without re-formatting your card, simply create the DSMAPS working folder on your card before you start DSmaps for the first time – if the folder is already present I don’t need to create it so the problem doesn’t arise.
Monday, 18th February, 2008
A couple of users have reported a corrupt file system on their SD cards after using DSmaps. I’ve been using the unreleased 0.1a version of DSmaps for a few weeks now, during which time I’ve accumulated over 3,000 files in my tile cache without experiencing anything like that. In fact I haven’t had as much as a hang. And judging by various download logs, hundreds of you have being trying out DSmaps today without any problems at all. So while these seem to be rare occurrences, please remember that this is alpha software and these things are an unfortunate fact of life when using any pre-release software – particularly alpha versions. The bottom line is that you should back up the contents of your SD card before you try out DSmaps or any pre-release software.
As to finding a resolution for the problem…the only file system writes done by DSmaps are creating directories to act as cache buckets, and creating the cache files themselves. Nothing is ever renamed, moved or deleted. Everything is done using the standard C library functions. Exotic, barely-documented functions are not used, nor is there any direct access to the raw file system. So it’s difficult to know what could be causing this. But one theory I’m working on is that the problem relates to the type of file system on your SD card. In all my development and testing I’ve been using FAT16, which was the default on my SD card. But at least one of the affected users was using FAT32 (possibly the others too – they haven’t said). I’ve reformated my SD in an effort to repro this, and I’m also doing a bit of research into potential issues with libfat on FAT32.