Oh dear God, now I'm some immortal, or some geek God
Considering disassembling: I disassembled about 10 games and TOS 1.04 (without AES, Desktop part) . Sideways was on of the firsts. I was on idea to make it working on any RAM area, so to make it regular TOS relocatable program - it is done for begin address $144C0, with screen buffers at $70000 and $78000 . But I was not able to do it properly, so it worked not flawless on higher addresses. I abandoned idea, and used other ways to make it work from hard disk, on Falcon. Maybe I could do it now better, with some more experience, but really no need to waste time, I think.
So, this update of Sideways is done with 100% original object code, no reassembling. I just inserted jumps on locations where was need to change code. Placed 2 added screens (packed) and about 800 bytes of extra code below $144C0 - and it still works fine even with TOS 2.06 when is placed in AUTO folder of floppy. For instance, when energy runs out, it jumps to same code as when ship explodes after losing shield. Only that then needs restoring full energy. Most time went on tracing game, and finding locations where variables for shields, energy, life count, score are placed. New variables are of course outside original code.
Disassembling: it is very hard to find all locations which are not code, but some variables, constants, data in middle of some longer program, or binary area. And is much easier with regular TOS relocatable exec. Because then, you can check it for correctness almost 100% bullet proof: just need to reassemble your S file, and if it is 100% same as original, you found all locations what are relocatable. In some cases it may take couple days, In some it can be done in less than hour. I used Devpac 3 for all it. Tried with Easy Rider and some other tools, but they was not smarter (or I was not smart enough to use them properly ?) .
For instance, OIDS was easy case - because it was compiled in special way, so all data was in data segment. Probably same is case with Dungeon Master - but I did not disasm. it. Swiftar is another one, done likely with same compiler, and was about 1 hour to disasm. Recognizable by jump table at start.
What was hard was Prince of Persia - mixed code and data overall, then some seemingly constants, which are actually displacement between 2 locations in exec, so you need to find exact locs for what it stays, and put there labels, and replace constant with label2-label1. That is pretty hard to discover.
What I did not yet, is disassembling some low RAM binary. It is not possible to do it with Devpac directly. Maybe with some tricks. In theory, you can do it with Steem, but it just produces not useful S file, should after it correct zillion lines manually.
Disassembly is not needed for some smaller changes in games, for sure. Then you just add patches, what means jumps to extra code, and jump back. But in cases like Uridium, Hard 'n' Heavy ... it was better way. Time spent on disassembling paid, and then was much easier to add new code parts, to change some existing ones, and like.
And you can even fix bad RAM management of games - for instance Uridium did it pretty poorly - there was large free area in middle of main exec, instead using bss area for that. So, I cut down exec size from some 350 KB to 160 KB ! Without packing. Certainly, there is plenty of Atari SW what could be made much better, but life is short, so most of it will remain as is.