Shifting the focus of the argument to the 'true essence of the thread' doesn't make a bit of difference. The discussion regarding legitimate OS entry points was instigated by your volunteering $C290 as a valid entry point for the OS coldstart routine. I'm not going to be implicated in collective responsibility for losing sight of the 'true essence of the thread' when it's you who has written one emphasis-laden post after another attempting to justify the use of an undocumented OS call.
Well, I guess we may simply not be able to agree on this particular point... and give someone else the chance to effectively address the problem on hand, with an actual solution.
Actually, the real essence was to see if there's a hardware issue or some components that might be causing the issue or perhaps something that could help the issue.
Software discussion of vectors and entry-points to the OS is way over my head but I do find it fascinating.
Thanks for everyone's input but hoping there is a hardware cure other than using a different OS or adding a cart with coldboot.
In the true essence of this thread, more than enough collective talent has already congregated here to try building a simple piece of code you could run from any DOS or boot directly (even from an AtariMax) cart, that would simply detect your HW config. check existence of extended RAM, erase it bank-by-bank first, and end by simply instructing the OS to perform a PWS/PCS with $0244 set on $FF (to erase base memory during a reboot) and you would solve your problem in 5-7 secs. approx... while the HW problem (if any) is figured out later.
However, we became obsessed with how necessary and important was to strictly adhere to compatibility and development guidelines... without ever coding ANYTHING (SW-wise) to address the main problem presented here (unfortunately). That includes me, as well....
Commentators are simply attempting to motivate coders into using documented OS entry points because doing so is good practice and ensures compatibility with any operating system which observes and implements said documented entry points. Making a big song and dance about the fact that most of the time the documented vector targets a particular address and advocating the use of the target address instead of the documented entry point makes no sense at all unless the primary objective is to appear correct as a point of principle.
Likewise, making a big and dance about the impact on compatibility and software development is, in reality, a moot point on the ACTUAL context of this thread (e.g. there isn't any SW development in place or being discussed), unless the primary objective is re-iterating strict-programming guidelines, in principle.
That was precisely my thought! Personally, I could HARDLY ever argue against official compatibility and system programming / development guidelines... but as far as you can read back in time on this thread, that is NOT the original or intended context of this discussion.
It appears to have gotten there by virtue of Sunday-morning "collective hysteria" or Global-Warming concerns... Well, that's how it seems after reading one-by-one the reactions posted above, though... Obviously, it is not the case (as most folks are simply concerned with solid and sound advice), but, in our quest of being purely and strictly "right", we simply lost sight of what really counted, here, in my opinion.
Well, sounds like as we all age, we certainly get more emotional and "re-active", in general...
Seems like, for some reason, the current discussion has focused on repacing (or not) existing OS entry-points, jump vectors, and their different hard-coded values among different OS versions.
However, the real essence of this discussion was to:
Provide those with "memory latency" issues a simple, possible work-around for CLEARING memory (or at least a good part of it), by USING the OS to their advantage, REGARDLESS of whether they had Basic booted, DOS, or an external utility, and without having to power-cycle the machine.
The original question pertains to an 800XL with expanded memory.
The original question DOES NOT pertain to an on-going software development project, though.
To the above extent, the indirect Jump routine on Atari OS has been hard-coded with a direct jump to $C290 which has been hard-coded in ROM for the last THIRTY-SIX (36) years!. And, unless someone here is actually trying to motivate the rest of the audience to abandon Atari's own OS code-base and jump to a full-replacement of it (which in reality has close to ZERO chances of happening), we will continue to jump to $C290 for another century, or so.
In no form or shape the objective of this discussion has been to REPLACE / REMOVE the existing vectors at $E474, etc. More than that, instead, is just trying to provide additional tools to have the existing code on the OS work to OUR advantage, by leveraging its own operational footprint, well beyond an indirect jump to $E474.
As an example of the above, I would cite an interesting problem that I found weeks ago when testing Monkey Wrench II on BOTH an extended XL/XE and OS/B loads:
by just booting it, and simply iterating three or four times through SYSTEM RESET button (which involves processing PWS/PCS code on XL/XE OS and part of it on OS/B), the system soft-CRASHES (locks up at GR.0 screen editor), and another SYSEM RESET takes it out of it, and if you cycle again, it will eventually crash again, and so forth.
by controlling directly $0244 and jumping to $C2A1-PWS1 (not an actual entry-point on the OS itself and, with $0244 set to ZERO), the system reliably and consistently processes a WARM reset, time after time, and NEVER crashes.
whether an interaction between OS, Cart and/or Incognito, at this point is hard to tell, other than what effectively occurs, though. I cannot directly blame cart-equivalence check code on the OS (tracking of GINTLK / TRIG3 values) as such code is NOT present on OS/B, and the problem also shows up on OS/B, too!
In any case, it seems that this particular cart lives up well to its name: talk about throwing a real wrench at the OS and everything in between....