The PPU type concept on the GBA is split between the VRAM (what holds the data) and LCD IO/OAM (what controls what is on screen), VBA, no$gba and more will have have viewers of these. http://problemkaputt.de/gbatek.htm#gbalcdvideocontroller
covers it all quite nicely. http://pineight.com/gba/managing-sprite-vram.txt
are also well worth having.
Equally nobody really makes tables using them on the GBA. They can help in some edge cases and with ordering and punctuation and such like. For table making you are better off with relative search, pointer decoding (most pointers on the GBA are of the form 08?????? so find a bunch of 08s close together and you tend to have found pointers, if the values they decode to correspond to sentence/paragraph length and are all quite variable then you have your text), working backwards from assembly, general tracing, compression searching/SWI logging, maths or linguistics based searching, and even corruption is something I would look at before I looked at NES style ppu fiddling for tables.
Even if you wanted to then the GBA graphics system is far more flexible (see earlier links) and devs make use of it so you would have a very hard time getting anything useful out the classic "ppu" style approach.
Also FFTA has been explored by a few people, perhaps not as much as the PS1 or DS entries but still known and looked athttp://ffhacktics.com/smf/index.php?topic=6334.0http://www.insanedifficulty.com/board/index.php?/topic/219-ffta-texthacker-01-alpha/http://datacrystal.romhacking.net/wiki/Final_Fantasy_Tactics_Advance:String_Tables