While testing the TK-II's U1MB screen tracking I noticed something interesting and kind of inconsistent. If you have SDX enabled, after 1st entering the LOADER screen, then going to SETUP, upon returning with either ESC or X you will be put back into the LOADER. This makes sense, and will consistently do this until you either do a restart (CTRL+R) from the LOADER, or do a restart (C or B) from SETUP. But if SDX is not enabled, then it doesn't matter if you were in the LOADER before going to SETUP, because ESC or X will always bail you out to the Basic prompt. I don't see how having SDX enabled or not should influence this, but it does.
It's easy to see why this happens, I think. When SDX is disabled in the setup menu, it actually completely deactivates the exposed ROM banking register (so SDX should be completely invisible to the system once the configuration lock is applied). The exception to this is when the loader is booted while SDX is disabled. In that case, the SDX banking register is left exposed on a one-off basis so that the OS can boot with the correct bank present. When you subsequently perform reset, the BIOS - aware that SDX is disabled - completely hides the SDX banking register again. Therefore, when you come out of setup, you end up in BASIC.
The unfortunate thing with the banking register is that it's write only, and believe me that made the bank handling quite difficult given all the extra functionality. For instance, if we do a COLD /N from the SDX prompt, we have to make sure we never touch the banking register at all on warm reset (not until we re-enter setup). The upshot of this is that setup can't tell which ROM bank was present when we entered setup.
A solution might be a persistent flag which keeps track of the state of the system on the previous boot. But that may in itself bring about unwelcome side-effects unless carefully managed. For instance, if you launch a BASIC program from the loader, then enter setup, do you really want to be back in the loader when you leave setup again? I think you'd really want to be in BASIC, so having a flag in the IO RAM which shadows whether we're in the loader or not might solve the problem.
Be nice if the action of ESC or X from SETUP would always return you to where you came from irrelevant of whether SDX was enabled. So if you came to SETUP directly from the LOADER, then you would return to the LOADER when ESC or X were issued in the SETUP screen. And vice versa if you came from either the DOS CL, or the Basic Prompt into SETUP, then that's where you would return instead. Don't know if there is an underlying mechanism that mandates the current method be used, but if not it would be great to see this changed. And if it can't be changed to what I have suggested, then perhaps it is better to have ESC and X always take you back to the DOS CL or Basic prompt, irrelevant if you came to SETUP from the LOADER.
I definitely wouldn't want to mandate a return to any particular place when coming out of setup. Ideally, we'd want to end up exactly where we started, as you suggest. Simply implementing the loader as a separate external cart at the board logic level would have made life so much easier, but there's nothing we can do about it now.
Separate topic related to CF Reset...
In the LOADER, CTRL+D executes this function, with out doing a visible reset of the Atari. However outside of the LOADER using the alternative SHIFT+RESET CF Reset does appear to do a system reset as well. Any reason for this? Be nice to have the more silent action like CTRL+D does in the LOADER. Is there a reason for the difference?
Yep, because the only way the PBI BIOS gets to see there's a hotkey held down is on system reset (and during SIO calls, but hotkeys during IO would be ugly as sin). The loader is issuing a card reset off its own back and then calling the SIO with the "refresh partition table" command.
No reason you couldn't have a small tool (as I think I mentioned previously) on the SDX CAR: drive which would reset the card without a system reset.
I noticed the effort put into state tracking of the U1MB via the TK-II, and while it's impressive I'm slightly unsure why it's necessary. Is this just so that you can have single-key assignments for what would normally be multi-key actions?
Caution is probably advisable, anyway, since a minor change to a BIOS key assignment or some other aspect of behaviour could upset everything. I'm not saying things will necessarily change at all, but it would seem to be something else to go wrong, so to speak.
Edited by flashjazzcat, Wed Jul 12, 2017 12:40 PM.