IIRC, it's kinda been awhile sorry.

0.)
i'm pretty sure (tilesaddress) can be in ROM, but you need buffers of equal size in RAM somewhere.  I'm pretty sure iirc that the routine just reads the tiles from their source and saves the modifications in the buffers.

1.)
ya, 1 byte per entry, so 256 tiles max.  117 or less is the most efficient.  Anything above will seriously lose to a planeshifting tilemapper iirc.  Still, I can't imagine needing so many black and white tiles since you could always  change the tileset address that the routine reads from.

2.)
well, I do admit I wish that forum code boxes had syntax highlighting, but  


http://www.revsoft.org/phpBB2/viewtopic.php?t=644&start=0  

3+4.)
The concept behind this tilemapping technique is based on around the idea that an unaligned sprite will ALWAYS take up 2 bytes (if it's aligned for a moment, you can still say the second byte is %00000000).  If you look at ionputsprite, you notice that it too must split the sprite into it's two parts through rotations before it can write to the buffer.

Jim e just applied that to the tilemapper by pre-shifting EVERY TILE into it's two parts and saving one part in one buffer, and the other part in another buffer.  When it comes time to write, all you need to do is take the second part of the first tile and XOR/OR it with the first part of the tile next to it.  It's like putting unaligned sprites next to each right next to each other.  They both must share bits in the same bytes, the ones in the middle.

Hope that helps.

I'm pretty sure the only way to really use this in an app right now is to copy into reserved $9d95 space.