For a bit, I've been planning on doing a project for the NES. To that regard, I've so far
made a silly MMC3 tech demo in
NESASM, and then I diverted a bit of time into writing my own 6502 assembler in D (originally written in lex/yacc/C++, but I decided to port it after getting fed up with a few things). I will probably add a few features to my assembler down the road (control statements instead of just using goto), but it works for what it does now. I am now designing a world format that will work well on the NES.
My requirements are as follows: low ROM usage, even lower RAM usage, fast to decode, allows bidirectional scrolling (even if it means attribute glitches along the edges due to not having the nametable space unless you're using an MMC5 mapper. I can live). Being the NES, speed and memory are definitely an issue. But far as memory goes, it is usually better to use more ROM than to use up the scarce RAM that the NES has available (2K system RAM, and an optional 8K WRAM depending on cartridge mapper -- this is also used for game saves if battery backed).
Basically, a world consists of maps which in turn have width*height references into common rooms (screen-sized chunks of map which are packed in simple ways -- a mix of uncompressed, RLE, and LZ-style), 4 palette references, tileset references (which are contain 64 tiles that each contain 4 8x8 subpatterns), and pattern references (which basically state which CHR banks to use). I will likely waste 1K of RAM on screen buffer (buffer for 4 rooms, each room is 256 bytes uncompressed), and decode rooms in chunks as they're scrolled into.
I'm currently starting to write a world editor in Qt, which I'm enjoying thusfar (although I'm not far at all yet). I've had previous experience making minor contributions to
tiled-qt, but for this, things are sufficiently different that I pretty much need to write things from scratch. Once I get make some interesting progress, I will probably release my tools under a permissive source license (MIT or BSD), and a demo under something similar (although possibly more restrictive separate license on the non-code assets. Has yet to be seen).
I wouldn't normally invest quite as much effort into reinventing a map format if it weren't for the hardware it has to run on, and the fact that I have to decode it later in 6502 assembly (heh).
Anyways, that's what I've been up to for now.