Power on off wait times

[Faicuai]

/headdesk.

 

Just the mere fact it's in the $Cxxx area means it's outside the realm of the original OS.

"Documented" doesn't mean squat. It's still not a recognised legal entry point, and the only usage case would be if you're developing a custom OS and using it from within it.

 

Anyway - feel free to continue your false beliefs, it's not as if you'll be releasing software that's going to affect people due to them.

Of course I will. I would only correct that it is $C290, instead of $C2A1 (that was from my own memory, just checked my own dissassembly-notes). In fact, $E474 is a mere jump to $C290 (PWS) which is why PWS is declared as official entry point in source code.

 

$C2A1 is PWS1, which allows to test COLD-START without veriying cart-equivalence (status), which I needed for some particular carts and test scenarios. In BOTH cases, BASE MEMORY will be erased if $0244 is set to $FF first, without even cycling the power switch, which will help anyone here having delays with RAM-content reset.

 

You don't know the OS deeeply enough, and for that, no one needs to be releasing any software, of any kind.

Edited January 20, 2019 by Faicuai

[_The Doctor__]

never-mind.... Faicuai corrected his mistake, and the rest of it was ok... but I think we should all still program/release software none the less

Edited January 20, 2019 by _The Doctor__

[cx2k]

The Doctor,

 

You mentioned in another thread about a capacitor that was responsible for holding the memory. Did you ever find out which one it was?

 

http://atariage.com/forums/topic/206880-130xe-reverse-option-key-for-basic/page-2

 

 

John

 

never-mind.... Faicuai corrected his mistake, and the rest of it was ok... but I think we should all still program/release software none the less

[Faicuai]

never-mind.... Faicuai corrected his mistake, and the rest of it was ok... but I think we should all still program/release software none the less

Yes, so in summary for anyone needed a fast base-ram erase WITHOUT cycle-powering and waiting for ANYTHING (for XL/XE OS):

 

1, Store $FF (255) in $0244 (580).

2. Jump to either $E474 (58484), or directly to OS documented PWS entry point, $C290 (49808), which is where $E474 will take you, anyway.

 

Bam! Full reset, and base memory is ALL clear, until the first NON-RAM address.

Edited January 20, 2019 by Faicuai

[+Nezgar]

$E474 must point elsewhere on 400/800 OS though. (Since there's no OS at $Cxxx)

[Faicuai]

$E474 must point elsewhere on 400/800 OS though. (Since there's no OS at $Cxxx)

It does, as multiple things changed from 400/800 to XL/XE OS.

 

Owner of this thread is reporting issues with 800 XL, instead. All of the information posted here, applies to XL/XE (or i-800 in XL/XE mode). Now, if memory-persistence issues relate to EXTENDED memory, then no OS released to this day may help, as none erase (quickly) extended memory during PWS / PCS execution.

[phaeron]

$C290 isn't correct for all Atari XL/XE machines even with the stock OS. The 1200XL OS has WARMSV pointing to $C34B. Furthermore, it is definitely not an official/legal entry point just because it is in the listing, because Atari specifically admonished against this in the OS manual:

 

 

The OS contains many vectored entry points at the end of the ROM and in RAM that will not move. The floating point package is not vectored but all documented entry points will be fixed. Do not use undocumented routines found by scanning the listing. A list of the fixed ROM vectors can be found in Appendix J.

 

The official fixed vector of WARMSV ($E474) will work on every machine, stock XL/XE or not. There's no reason not to use it.

 

There is another way to force a cold start from BASIC: BYE, followed by Reset. I do this to avoid having to power cycle the computer to boot another program/image.

[+slx]

Any easy way to bypass the RAM clear wait (very long for Antonia) when the system has crashed?

[Rybags]

Check the 1200XL OS - the version I have is different again, shooting the C2AA, C290, whatever - theories out of the water.

[Marius]

People should not advertise the use of illegal entry points, ever. We have seen enough trouble with that since developers ignored official guidelines, which resulted in incompatibilities between OS A/B and XL/XE. (I remember I had to fix Synassembler ROM using a hex editor because the official entry points were bypassed)

 

And as far as I know there is always just one official entry point for any 'routine', feature or whatever you want to call it.

$E474 = WARMSV and $E477 = COLDSV

 

If you think it is not true, please explain what those entry points $E474/$E477 are.

 

Otherwise: as far as I know doing a JMP $E477 will lead to a coldstart on any atari 8bit computer.

I do not see that happen with JMP $C2C8 on OSA/OSB; so this will only lead to a coldstart on XL/XE (not sure about 1200XL...)

 

In Mapping the Atari, the XL/XE edition I read in Appendix 12 this:

 

The JMP vectors in locations 58448-58583 ($E450-$E4D7) remain the same, but point to new vector addresses:

 

 

Label Loc JMP To

===================

DISKIV E450 C6A3

DISKINV E453 C6B3

CIOV E456 E4DF

SIOV E459 C933

SETBV E45C C272

SYSBV E45F C0E2

XITBV E462 C28A

SIOINV E465 E95C

SENDEV E468 EC17

INTINV E46B C00C

CIOINV E46E E4C1

SELFSV E471 F223 (used To be BLKBVD)

WARMSV E474 C290

COLDSV E477 C2C8

RBLOKV E47A FD8D

CSOPIV E47D FCF7

Edited January 20, 2019 by Marius

[Rybags]

The bigger joke about it is that the 3 cycles saved would never be noticed.

Funny how we've spent the last 30 years working to get as much software as universally compatible as possible yet there's still people around who want to revert to the bad habits for no good reason.

[flashjazzcat]

I think it's been mentioned before that Mapping the Atari - wonderful book though it is (I'd have been lost without it these past thirty years) - didn't exactly help matters by listing a lot of undocumented OS and DOS addresses. This results in 'Hey: look at me - I can open the screen editor without using the CIO by jumping straight into the OS! I saved a dozen bytes and made my software likely to crash with any other OS!'. Big whoop.

[Marius]

I think it's been mentioned before that Mapping the Atari - wonderful book though it is (I'd have been lost without it these past thirty years) - didn't exactly help matters by listing a lot of undocumented OS and DOS addresses. This results in 'Hey: look at me - I can open the screen editor without using the CIO by jumping straight into the OS! I saved a dozen bytes and made my software likely to crash with any other OS!'. Big whoop.

 

True! But I believe the information I took was valid. Right? Btw. Big Whoop... wasn't that the lost treasure of Melee Island in Monkey Island II?

[flashjazzcat]

True! But I believe the information I took was valid. Right? Btw. Big Whoop... wasn't that the lost treasure of Melee Island in Monkey Island II?

Certainly: all valid info (although the 'JMP to' column is another example of what I was talking about).

 

As for Monkey Island II... no wonder I couldn't find Big Whoop. I was looking for it in Monkey Wrench II.

Edited January 20, 2019 by flashjazzcat

[Marius]

Certainly: all valid info (although the 'JMP to' column is another example of what I was talking about).

 

It should have been JMPs to. We talked about it. The entry point $E474 JMPS -in an Atari XL/XE OS- to $C290. Everyone who uses $C290 instead of $E474 should have their license to code revoked (Whistles James Bond License to Kill tune)

Edited January 20, 2019 by Marius

[Faicuai]

The bigger joke about it is that the 3 cycles saved would never be noticed.

 

Funny how we've spent the last 30 years working to get as much software as universally compatible as possible yet there's still people around who want to revert to the bad habits for no good reason.

 

Talking about jokes (real ones), I really got a good laugh at this one: STILL using Altirra 2.7x (!!!) in January, 2019 (!!!)

 

http://atariage.com/forums/topic/287240-draconus-4-cas-file-at-1400-bps/?p=4200595

 

 

 

In that sense, I suppose I should follow the example and go back to Candle/s or PBIO BIOS 1.x, for this matter.

Edited January 20, 2019 by Faicuai

[Faicuai]

 

It should have been JMPs to. We talked about it. The entry point $E474 JMPS -in an Atari XL/XE OS- to $C290. Everyone who uses $C290 instead of $E474 should have their license to code revoked (Whistles James Bond License to Kill tune)

 

Well, let's put your theory to the test:

 

Why don't you open up a new thread, and summon al those coders out-there that COMPLETELY by-pass and disregard the OS, as well as DOS, and threaten them with "revoking their coding licenses"?

 

I do wish you good luck, though... (Note that I would be among the very first ones supporting your motion., as I've never been on any other page...)

Edited January 20, 2019 by Faicuai

[Marius]

Well, let's put your theory to the test:

 

Why don't you open up a new thread, and summon al those coders out-there that COMPLETELY by-pass and disregard the OS, as well as DOS, and threaten them with "revoking their coding licenses"?

 

I do wish you good luck, though... (Note that I would be among the very first ones supporting your motion., as I've never been on any other page...)

Did you notice the ... that means that it was meant funny. Don't take it so hard.

[Faicuai]

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:

1. 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.
2. The original question pertains to an 800XL with expanded memory.
3. 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....

Edited January 20, 2019 by Faicuai

[cx2k]

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.

 

John

 

 

 

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:

1. 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.
2. The original question pertains to an 800XL with expanded memory.
3. 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....

Edited January 20, 2019 by cx2k

[flashjazzcat]

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.

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.

Edited January 20, 2019 by flashjazzcat

[Marius]

Well, sounds like as we all age, we certainly get more emotional and "re-active", in general...

 

Hmm... most of the people around me, including myself, are just the opposit of that. The older they grow, the wiser they get and know how to respond on a joke. But ok, I do not want to fight or argue with you; but I wished on the other side that you understood the importancy of this issue.

 

Let me state one difference though. You are right: there are a lot of coders who do amazing things, and find ways to push the atari-hardware to the limits and sometimes even beyond that. Indeed, they have a unconventional way of coding, and yes I think that is allowed, because it serves the goal they try to achieve.

 

But that is not the case here. As long as you write something that uses OS-vectors, one should -always- follow the official guidelines; if not, what is the use of the guidelines then anyway? If you write for your own computer, and you have no plans in releasing anything, but it is just for your own use... fine feel free to use any address in your Atari OS. It is your computer, who am I to tell you what address you should use? But if compatibility is your goal, please do not be stubborn.

 

Perhaps I open a can of worms now, but let me use Mr. Atari and his MyBIOS as an example. He wrote a third party os that turns a simple cartridge into a Harddisk interface. I know not everyone here is a huge fan of MyIDE, but it is a good example. Why does his OS works so well? Because on the official entry-points there are new vectors. That is how entry points work. He respects the original entry points, and they all JMP to his own custom created routines. And it must be said: the compatibility of his OS is amazingly high.

 

Now... let's say you write some fabulous piece of software, but you do not give anything about official entry points. You state: hey guys... the last 36 years $c290 was where to jmp to cause a warm reset... your fabulous piece of software will definitely not run from MyIDE or on other Atari's with possibly a custom OS.

 

I know you can not support any possible OS. True. But there do circulate also other official Atari OS's (I remember the Atari OS with the 128KB memory test in selftest). It is different from Rev. 2 XL/XE os. If you rely on non-official vectors/entry-points or whatever... you'll meet sooner or later unhappy users of your software, since it won't run.

 

Please accept that.

Edited January 20, 2019 by Marius

[Faicuai]

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.

Edited January 20, 2019 by Faicuai

[Faicuai]

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.

 

John

 

 

 

 

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....

Edited January 20, 2019 by Faicuai

[flashjazzcat]

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.

Edited January 20, 2019 by flashjazzcat