Yup, totally right.  After fixing the town, the areas use bank 01 for data.  I assume that when you mean planes, you are refering to the 8 pointers that refer to the different data tables, right?

How things work is that there are 6 banks.  You have 4 banks for overworlds, and 2 for dungeons.  You may notice that for the dungeon banks, there are extra pointers that lead to the same stuff.  I changed the 7th pointer, which is the same as the first dungeon pointer, and went to a side view area.  Like I said before, these two extra pointers are used for side view areas and changing rooms.  When you go into a side view area, you actually do warp to a different plane that contains the same data(for the most part).  However, I will bet there are some data that is different, and they define those extra things.  What I did was I changed the first dungeon data pointer(for area data), then went into a side view area.  Instead of ending up in the same dungeon bank, I went to the next one.  However, the overhead areas remained the same.  This certain begs more research.

I've been looking into the data for the tunstile in level 3, and it's interesting that there doesn't seem to be a flag that's triggered nor does there seem to be any alternate maps with the data.  I do know that once time I changed the plane number from 04 to 06 and it did appear, which indicates that the data must somehow be stored on that plane.

Also, yeah banks is not an approprate term.  Especially since it spans multiple banks.  A more correct term would be Dungeon Maps, or Dmaps, a term from Zelda Classic.  When I hear the word "plane", I think of layers.  Of course a plane could mean somthing like multiple dimentions or somthing, so it works in that way as well.  I'm still going to see how side view areas work, and why for some reason they use the alt planes.  One guess is that it has somthing to do with why the map cursor doesn't go right to that screen, but rather stays put.  It could also have somthing to do with how the edge of the screens work as well.

You mean what I've been calling macros?  Basically lines of pre constructed rows of data?  Anyway, I found out that what's happening is that those rooms stay the same, but tile data is written over top of certain areas to make it look different.  I am pretty sure that the floating islands in level 7 do the same thing.  I bet it's controled by the event data.

Oh, okay.  Just trying to get on the same page as you.  So Area Classes, as you call them, are basically the data that detemines how the map screen works.  If I remember correctly as well, on top of that, $40 makes the area have water, and $80 changes the graphics of the treasure chests from present to past.

I was actually refering to dungeons, but it makes sense for the overworld too.  I bet it's also what allows for the use of the Tune of Currents as well.

Edit:  Nope.  Okay, I found the code that determines if the screen is a small one or a large one.  Planes 04 and 05 are the ones that have enlarged rooms.  Changing it to 00 will make every screen large, but it doesn't actually enlarge the scroll boundries.  A few edits coupled with an overhaul of the map data will allow for larger sized overworlds, but that's foolish because nobody would want to code the overworld using dungeon style macros.  I also found that with the warp data, the last 2 planes are in fact used for sideview areas.  Basically, side view areas are either in plane 06 or 07, and when editing warp data, that must be put into consideration or else some things might not work, like exits and such.

Edit 2:  I was looking at the overworld pointers, and it seems that it's the same relative type as the dungeons, except it seems that the second byte of a pointer seems to have additional properties.  I suspect it has somthing to do with how the data is organized.  Perhaps the extra bits tell the game to use only one control code per line instead of 2.  I need to look into it some more.

What I meant by relative pointers, is that the pointers to the map data itself(the rooms), are not done in the usual mode of addressing the ram space, in the GBC's case, $40 to $7F.  Instead it starts from where the map data starts, then uses that pointer to skip that many bytes ahead.  Obviously the first room would be $00 00, but what I found with the overworld is that the first room actually has the pointer of $00 80.  That's odd since the GBC does not work that way.  What I found is that the extra bits on the second byte seem to do somthing.  I am not sure what it is though.  The pointer to the list of pointers is where I showed you before, in that little area before the area class list.  7 bytes for each plane with the first being what compression to use.  The next 3 bytes are a 3 byte pointer to the pointer list, or the macro and pointer list if that first byte is $00.  Next 3 bytes is where the data actually starts.  You take a pointer from the list and convert it into decimal, then count the number of bytes untill you get to the room you want.  The overworld pointers seem to have extra data in them that determines somthing.

Oh so you mean it basically tells the game how to treat the data at that location.  I wonder if that means there are uncompressed maps in certain places?  Uncompressed maps might be useful when there is enough unique tiles on the screen that compression would be fruitless.  Conversely, using a 16 tile encoding would be great for screens with only one or two types of tiles on the screen, such as sea maps.

Okay I confermed what the pointers do.  For overworlds, how it works is 4x of the second byte means that there is one control byte, followed by the tile that fills up all the 1's.  If the pointer is 8x, then it uses 2 control codes followed by the tile value of 1.  If however, it is set to 0x, then no control code is used.  This affects the entire screen, so if the first line uses a double control code, then the entire screen will use that.  This means 0x as the second byte is uncompressed tiles.  This will be important when loading the map data.