Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!think!mit-eddie!genrad!decvax!tektronix!teklds!midas!neals From: neals@midas.UUCP (Neal Sedell) Newsgroups: comp.sys.m6809 Subject: Re: CoCo3 OS-9 Level I Version 2 problems Message-ID: <972@midas.UUCP> Date: Mon, 5-Jan-87 22:37:17 EST Article-I.D.: midas.972 Posted: Mon Jan 5 22:37:17 1987 Date-Received: Tue, 6-Jan-87 19:05:38 EST References: <1484@lsuc.UUCP> Reply-To: neals@midas.UUCP (Neal Sedell) Distribution: na Organization: Tektronix, Inc., Beaverton, OR. Lines: 126 In article <1484@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > > A while back we had a posting of a 'co80' replacement to use the >Color Computer 3 with 80 columns under OS-9 Level I, version 2.00. >I assembled the file successfully according to the 'ident' stats (isn't >'ident' wonderful?! Unlike the almost every other major OS being used >by Netters we actually *know* when we have a good assembly or compilation. Are you sure? I had to type mine in by hand, and after checking it three times it's still two bytes too large and of course the CRC doesn't mean diddly, but it DOES work... Strange but I'll ignore it (until something else breaks). Actuall, I've spent a lot of time just getting my new COCO 3 to run OS9. It sure didn't like any of the 1.00 or .01 disks I had, so I got out the 2.00 updates I stashed a long time ago out and built a new disk for the 3. Of course that took several tries, but the co80 I had came from DELPHI or somewhere else, and was about twice the size of the co80 posted here and did all kinds of neat color things, but it got me going until I assembled the mono co80. It looks pretty good using the composite output, although the characters are really skinny. Guess they had to fit in the display RAM accesses when they could, which meant a rate much higher than necessary for 80 columns (but probably just right for 128 columns...). I assume it would be trivial to make the screen 80x25, which I am going try Real Soon Now. The whole problem I had appeared to be that using double sided disks was that the standard OS9GEN command apparently doesn't know how to keep things on one side of the disk, and of course RS-DOS doesn't pretend to know anything about double sided drives. I realized it when I looked through Dave Lewis' OS9GEN2 source, and reassembled it for version 2. Things started looking up. I also used Dave's NEWDISK which hasen't given me any problems. I managed to copy all the version 01.01 cmds disk along with the RS C complier cmds and still have several hundred sectors free on /D0, which just happens to be a 40 track double sided drive (as J. P. would say ;-) Moving on to other problems, the ramdisk for the 3 gave me lots of problems - seems that with 128K, the GIME maps the two 64K banks alternately 4 times throughout the 512K address space - and OS9 doesn't configue the TASK 0 registers for the upper 64K either - as I recall it maps 0-1FFF to the first 8K of bank 0 and the rest consecutively to the last 56K of bank 1. The TASK 1 set is configured even more strangely. I don't know if both maps are used under OS9 or not - although it's probably certain that with L1V2 they don't know anything about them. (Interesting side note - when PEEKing at the MMU registers from basic the values are different than when using OS9's DEBUG.) Getting back to the problem, the RAMDISK brought the system to a grinding halt every time I tried to use it. I finally gave up and rewrote it - the result was that it would crash when writing to sector $29. There's still some funnies going on, but that'll have to wait a few more days to reconcile. Of course I masked all interrupts by setting the CC bits, so that's not it. I guess I'll have to figure out where the screen is and which MMU registers are being used the straighten things out once and for all. Maybe at startup I could move everything into one 64K bank and put the screen at the end of the other (all 4K for chars and attributes) and end up with a huge 62K ram disk (as opposed to 56K). Is there ANYBODY FROM RADIO-SHACK PAYING ATTENTION to our plight? Sure would be nice if they would do something like what ATARI is doing for their users on the net. The reference manual that comes with the 3 doesn't say one $%#@*&*! word about the GIME! Any comments at all? Please? Pretty Please? Maybe some insight about what we can do that would be compatible with Level II? Surely everything must have been decided upon by now, since introduction was to be 4Q86 ;-) This raises a important issue - turning off all interrupts for several milliseconds while mucking with the MMU is not my idea of a Good Thing. Until Level 2 comes out I suppose we're stuck with it, but a serial port running at only 4800 baud generates an int about every 2mSec..... Using the ramdisk to get around using the NON-DMA disk controller doesn't buy you anything since ints are still masked.... Humph, just when I thought they were making the COCO into a real computer. ;-) > Do I have to buy another update for SDisk? Does the 'cobbler' patch >for Version 1.01 which was posted have to be used for version 2? Actually, >if that's the case, it probably won't help anyway if I use 'bootfix' or >would it? Like I said before, OS9GEN2 and NEWDISK work great. With such a complex OS it was amazingly painless and rewarding (for a change). GOOD JOB DAVE! Oh yes, when you do finally get V2 to boot, you get to change the SysGo module to replace the /H0 and /H0/CMDS with /D0 and /D0/CMDS so you can execute your STARTUP file and have a default cmds directory. When they said that V2 would automatically startup using the hard disk they forgot to tell you that it wouldn't startup using a floppy disk anymore ;-) Oh yes, if you have a hard disk, never mind. Speaking of hard disks, the SASI hard disk driver I talked about writing last summer is done but the results are less than spectacular. The data transfer rate is LESS than that for a floppy ;-(. Looking back this is inevitable since the floppy uses HALT and I have to poll the host adapter I built. For contiguous file copying to /nil, it's a bit slower than a floppy, but when you are seeking all over the place it does much better. I haven't tried it with the 3 yet so at 1.8MHz things may look better, but all in all I was so disappointed that I never finished putting the hard drive into a nice cabinet and my present desk doesn't allow room to lay out the controller, power supply, drive, etc. I just went back to my 512K ramdisk on my COCO2 and forgot about it. Seeing as how that ramdisk won't work at 1.8MHz things I may go at it again. What I would really like to see is the extra 62K of the COCO3 used for cache. Another project for the back burner ;-). Of course, when Level 2 comes out and/or I get the 512K upgrade, everything will probably get messed up again so why bother? Because it's there of course! Has anybody gotten they COCO3 "fattened" to 512K? Where from? And of course, how much? I looked inside the case and it looks pretty crowded for 16 256Kx1 parts but 256Kx4's must surely still cost a fortune ( >> $150 RS wants for the upgrade). Another thing is the pass transistor/heatsink run quite warm with 4 64Kx4 parts, do they include a fan with 512K? ;-) After several hours the screen develops a power supply ripple-like bend. I haven't traced it down to the monitor or the computer yet, but it happened with my COCO2 too so it's probably the monitor (Zenith ZVM-123). Food for thought - since the application/driver has to take over one of the MMU registers for their own use if they want to do things out of thei 64K address space - which one do you use? Co80 uses E000-FDFF, the ramdisk uses 0000-1FFF. I would suggest that 0000-1FFF is the logical choice since you HAVE to mask interrupts when the MMU is in an altered state and all drivers loaded at boot time are up around $A000 or so. That would remove the restriction on co80s position in the bootfile. Of course, if your code or stack lives below $1FFF you probably want to use a different page ;-). Just something to keep in mind as we utilize the new capabilities of the '3. Neal "I'm trying to have fun in spite of it all" Sedell