@nina_kali_nina (For the future) In my limited-yet-diverse experience with ghidra, that behavior is usually because there's a function somewhere much deeper in the call chain that was incorrectly tagged as noreturn by the initial analysis pass and it's "helpfully" re-propagating that flag by re-establishing the flow overrides in the disassembled function. I've learned to not run the "non-returning functions" analyzer on older/embedded code due to that... (There's frequently a lot of "helpers" that don't match the standard ABI, which can confuse that analyzer pretty badly)
It could also help to identify the point where the problematic function does return and set a flow override there to "properly" tell the decompiler "yes, this function really does return to the caller here" even if it really wants to ignore the unset noreturn flag on the function.
@evv42 the code is a mighty beast, with over 1MB in overlays. So I keep interesting bits in Ghidra, find them in overlays, find overlays in RAM in Bochs, set breakpoints, and investigate. I've tried Qemu+GDB, it just doesn't cut if. Bochs' debugger is not awesome, but it might be the best thing available for my kind of project.
MAME is an option, but its debugger doesn't show stack frames. Marty PC is interesting, but it doesn't fit on my display.