Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 from ihnp4 4.3bsd-beta 6/6/85; site chinet.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!chinet!draco
From: draco@chinet.UUCP (Kent D. Meyers)
Newsgroups: net.micro.6809
Subject: Re: Spontaneous ReBoots of OS9?
Message-ID: <436@chinet.UUCP>
Date: Fri, 4-Apr-86 00:43:03 EST
Article-I.D.: chinet.436
Posted: Fri Apr  4 00:43:03 1986
Date-Received: Sat, 5-Apr-86 11:29:30 EST
References: <16500@rochester.ARPA> <3500139@uokvax.UUCP>
Reply-To: draco@chinet.UUCP (Kent D. Meyers)
Organization: chi-net, Public Access UN*X, Chicago IL
Lines: 46


In article <775@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes:
> Under what conditions, if any, should RS CoCo OS9
> version 1.1 decide to reboot itself?

> I have three theories (notice how OS9 has restored
> the spirit of scientific research and philosphy to
> home computing :-] ):
> (1) Microware's code can detect certain error situations as
> being so hopeless that the best thing to do is reboot.
> ................  Could it be that OS9 realizes its
> kernel is corrupted?  That would justify a reboot.

The kernel is NOT reloaded on a warm boot!! Module OS9 is just restarted.
If the kernel were corrupted, it would not be possible for the system to
reboot and it would crash. Except if OS9 itself were damaged. The OS9
module is the only one in the system that is not verified before it is
executed. The other modules in the kernel must be linked to and if they
were corrupted they would not appear in the module directory. You can tell
if the OS9 module is correct by doing an mdir after the system reboots. If
it appears in the listing it is all right.

> I'd like to hear from some heavy hackers who can confirm
> the existence of deliberate reboot code in OS9.

There is no code in R/S OS9 to reboot the system. The code that does the
reboot is at the beginning of the kernel track and has no connection with
OS9 when OS9 is running. The warm boot code is located at D.CBstart ($0071)
and is put in place by Sysgo. This is why the double reset returns to BASIC.
Until Sysgo has executed, the byte at D.CBstart is $00 and the BASIC reset
routine will be forced to do a cold start. The actual entry point to the
warm start code is at $0074. There is no direct connection to this code
from within OS9. It is vectored to by the R/S BASIC reset routine.

So it would appear that your errant programs are somehow executing the 
reboot code at either $0074 or directly at $F00C. The code that precedes
the actual kernel on the kernel track loads at $F000.

Interestingly enough, there are two places where OS9 attempts to abort by
using JMP [$FFFE]. One is in OS9p2 and the other is in IOMan. Unfortunately,
this does not work on the CoCo without going back to the ROM mode. And OS9
does not do this. This is why the system hangs when you do something silly
like forgetting to put SCF in your bootfile.


Kent D. Meyers ihnp4!chinet!draco