ac@utgpu.UUCP (03/27/87)
I have run into another problem with OS9 Level II for the COCO. The system crashes whenever I try to use CHD. At first I though any use of CHD would cause it to die but now it seems that CHD works as long as the disk is not write protected i.e. no write protect tab. It seems odd to me that CHD would even know if the disk was write protected. Does this imply that CHD writes on the disk or is it possible for the software to know if a disk is write protected without writing on it. In any case, why should the system crash if it is? As I mentioned in an earlier posting, I had to zap out several instructions in the kernal to prevent it from trying to run at 2MHz. Perhaps my zap is at fault? One other oddity. Issuing EX from the lowest level shell hangs the system. On level I, I thought SYSGO would restart things. -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
pete@wlbreng1.UUCP (03/31/87)
In article <1987Mar27.123438.23604@gpu.utcs.toronto.edu> ac@gpu.utcs.toronto.edu (Mark Acfield) writes: > > > I have run into another problem with OS9 Level II for the COCO. The >system crashes whenever I try to use CHD. At first I though any use of >CHD would cause it to die but now it seems that CHD works as long as the >disk is not write protected i.e. no write protect tab. It seems odd to me >that CHD would even know if the disk was write protected. Does this imply >that CHD writes on the disk or is it possible for the software to know if >a disk is write protected without writing on it. In any case, why should >the system crash if it is? .... [text deleted] CHD will attempt to update the last modified date of the directory that you CHD to. If it fails (i.e. for reasons of write protect, or possibly attributes), it *should* give up gracefully. > One other oddity. Issuing EX from the lowest level shell hangs the >system. On level I, I thought SYSGO would restart things. On coco3 there is no 'sysgo'. The CC3Go is the startup job, and it does not respawn shells if I recall. I believe this was partially the reason for adding the 'i' option ('i'mmortal) in the new Shell. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete !wlbreng1!pete !wlpx!pwl Compuserve: 76703,4230 (OS9 SIG Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Phone: (818)-706-5693 (work 9-5 PST) ----------------------------------------------------------------------
ac@utgpu.UUCP (04/08/87)
I was talking with someone at my local RS store and he claimed that many people with COCO 3's have upgrade their disk controllers. I guess they all tried running at 2MHZ some time ago and found out the problem then. The cost of the replacement controller is about $120 CDN. Now that I have had some time to play with OS9 level II I have a few observations. First, the combination of windows and multitasking is really impressive. And if I,m not mistaken keyboard input is much less susceptible to character loss while the disk drives are in use. For the most part I have never found the idea of doing background compiles and the like much use on such a limited resource as the COCO but being able to display a file, a directory or some other useful information in one window and then use that information while editing in another window, now that I can really appreciate. There are a number of restrictions on windows which you might not expect if you are thinking in terms of Macintosh windows. Windows may not overlap i.e. a corner of window 2 may not obscure part of window 1. This restriction applies to windows that appear simultaneously on the same screen. It is however possible to define windows that overlap or in fact occupy exactly the same part of the display as one another as long as they are on different 'screens'. This is much like the multiple graphics buffers you could set up on the basic COCO. You can for example setup 2 fullscreen windows each with a shell and then flip between these 2 'session' with the CTL-CLR key. I find this very useful. About 8k of utilities are locked into storage along with the shell. This saves alot of disk access time for common disk management chores. Dump, save and debug are missing (along with the assembler). I believe that dump and save can be copied from level I and work fine. Debug has a problem. It issues a link to find the module you want but then immediately issue unlink. In level I this was a good idea. In level II the module vanishes from your address space in a poof of orange smoke. There was a patch posted for this problem. The assembler works I believe BUT we need a level II defsfile. The increase in memory is useful. Backup #40k works quite nicely. I'm not sure that BASIC09 can be convinced to use more than 32k. Most commands are the same as level I but those involved with memory produce different output. Indeed the whole concept of available memory is different. The link command and system service also imply quite a bit more than they did in level I. Basic09 is included in the package (instead of the assembler). It is essenitally unchanged from level I except it 1.00.01 instead of 1.00.00. Since both pieces of code are the same length I think they just patched something. They have added to extra subroutines to the previous GFX and INKEY. They are GFX2 and SYSCALL. GFX2 gives you access to all the new window and graphics stuff. SYSCALL allows you to call any OS9 service from BASIC09. I don't believe they enhanced GFX to include the few extra features that got added at version 2.00.00 of level I. There are new device descriptors for those with 40 track and double sided drives. I've heard there are problems with mixing drive types. SSC support is gone though. I beleive that the problem with the Speech systhesizer is that it won't run at 2MHZ so it should be possible to rework the level I drive to change speeds just as I have done woth my disk driver. The manual is quite extensive but it is too big to put in the binder. I heard rumours that it was even bigger to start with. There are quite a number of typos in it and some info is missing. There are no descriptions for the MODPATCH and MONTYPE commands. The section describing device descriptors and i/o subroutines which they included in the 2.00.00 update document has not been include for level II. This is particularly annoying since so much change has occurred in this area. Finally, I am anxiously awaiting the Multi-Vue and Program Development packages. I hear they will be in in a few more weeks. If the high level window support is as impressive as the low level support this will give us quite a machine. I think the asm package comes with a fullscreen editor and a ramdisk. -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet