Depends upon the disassembly, assembler and what you did in the meantime. The basic ROM hack for a non filesystem (so anything older than the DS that did not come on a floppy disc or optical media, give or take some homebrew efforts) game will tend to start from the assumption that the basic ROM layout is the same. One wherein you assemble the whole ROM from some kind of source code (be it leaked or fan recreated) could well radically alter things and not have it be anywhere near as annoying as doing that is for a baseline ROM as a hack. Indeed I would tend to assume it was going to be different until proven otherwise -- making a more matching one then probably wanting to match assembler handling (be it by recreating it or finding and making whatever Nintendo used all those years ago run on what you have available to you), build scripts and whatever else Nintendo used back when (
https://www.pagetable.com/?p=28&cpage=1 is somewhat related at this point, even if only as an example of what might be in store for that one and I am not sure if such things have been included in any of the gigaleaks or similar).
If you are playing with a disassembly forcing it into GBA mode is nothing too drastic -- there will be a little check during early run of the game and going from there. You can then recreate such a thing, or indeed dodge it entirely if you so desire. Colour restoration in that is also nothing too troubling -- if memory serves the same thing that also did the "is on GBA" is also the thing that tells it if so then also put these brightened/washed out palettes on there because this first gen unlit GBA screen is so dark (it being several years before the SP, never mind the GB player or SP 101, was even a glint in Nintendo's eye at this point).
https://bgb.bircd.org/pandocs.htm#cgbregisters has how GBA detection works.
Character per line limit, assuming you don't care to make it larger, is something you can generally find your yourself once you have the text -- new lines will either be handled by pointers, some kind of autowrap (unlikely on a GB/GBC but not impossible) or some kind of value within the text itself (windows typically using 0d0A, unix tending to be 0a, hence the option you might be given in various editors or windows notepad not necessarily always displaying new lines in ASCII art and whatnot). Pointers (which will come back up in a second) might take a bit more effort but if you have found the text (relative search, tracing, corruption, grabbing text from RAM and back searching for it, compression searching... it matters not, just that you have it) and thus have enough to start making a table you can then doodle on.
Alternatively if it is not a variable width font you can usually figure out how many pixels it assigns to characters, the general borders of the thing and then use an image editor if you wanted to multiply it out.
"As far as editing the text goes, I know with some editors you had to make sure not to go make the each dialog any longer than it was already because it could potentially overwrite the next. Are there any restrictions like that with a disassembly either in terms of individual dialogs or the total dialog length?"
Is perhaps not the right question or line of thought in it. I don't doubt there are restrictions with various editors and there are good technical reasons for them, however if you are at the point in life where you are considering playing with disassembly then it is moot.
There are two reasons for such restrictions, three if you want to count screen real estate issues but that is only related at best and sort of covered above.
1) Not enough space in the ROM. Not an issue for almost any GBA ROM (Mother 3 tending to be the only exception worth speaking of) where anyone can have 32 megabytes of total ROM space absolutely trivially if they wanted, could be more of one for the GB/GBC as they were more limited in space and increasing space might have been a hard task (see mbc changing). Working with a disassembly might make this easier but still could throw up some hurdles.
2) Someone did not care to sort out the pointers properly.
Pointers are like contents pages in a book is usually how I describe things. Open up a book, rip out a bunch of pages or stuff some new ones in and if you go along dutifully counting pages to get to what the old and out of date contents page says and chances are you will not be where you want to be. As your little 4.194304MHz z80 a like with 8K of RAM (which is actually more powerful than a lot of even older systems) is not going to want to parse an entire game script every time it wants to do something then it will have little signposts saying where things are, pointing the way if you will. Change the text and you change these, add more in and you have to find new space somewhere in the ROM. Making a text editor handle this I would generally have considered as part of the basic functionality but not all will do that, and might not even need that for the purposes of the would be coder of it if they are less interested in fiddling with major translations as much as changing a word or two here and there and just need a glorified program to display text as determined by their table along with any placeholders and markup, and at least pull from pointers.
Topic: Text Editors for TLoZ Oracle of Ages & Seasons (GBC) & Minish Cap (GBA)? (Read 1601 times)