jimomura@lsuc.UUCP (01/01/87)
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.
Those guys in MS-DOS land don't know what they're missing), but after
building an 80 cylinder double sided system floppy with SDisk using
'bootfix', I found it wouldn't boot. It would load a few tracks, pause,
load a few more tracks and stop with the drive light on and the screen
showing the 'OS-9 Boot' message in 32 columns. I tried it a couple more
times and it got further. The drive stopped and the screen turned to 32
column garbage as if it were trying to show 80 columns, but missed.
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?
The drives are OK (brand new and checked with my old CoCo and OS-9\
with WordPakII and SDisk).
Cheers! -- Jim O.neals@midas.UUCP (Neal Sedell) (01/06/87)
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
dml@loral.UUCP (Dave Lewis) (01/07/87)
In article <972@midas.UUCP> neals@midas.UUCP (Neal Sedell) writes: > >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! I thank you, my CoCo2 thanks you... >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 ;-) > >Neal "I'm trying to have fun in spite of it all" Sedell That is due to a bug in NewDisk. I posted a debugged version here last September; looks like you missed it. It seems that OS9p2 sets up the initial /D0 and /D0/CMDS paths very soon after it runs Init, and BEFORE SysGo starts up the Clock. This causes an access to NewDisk. When the DSKSTART subroutine runs, the F$VIRQ call returns an error because the clock is not running, and that error gets sent back to the caller. The /D0 and /D0/CMDS paths don't get established, so SysGo can't find Startup. When things work normally, OS9p2 sets up these paths, then SysGo TRIES to chd and chx to /H0. IF IT FAILS, SysGo ignores the failure and uses the already established /D0 paths. The secret is in DSKSTART. First, throw out the BCS immediately following the OS9 F$VIRQ call. Then, insert a test-and-branch near the end of DSKSTART so it looks like this: IFEQ VERSION-2 TST VI.VAR+1,U Is the Virtual Interrupt active? BEQ RETURNOK Leave it alone if not LDD #DISKRUN Restart the Virtual Interrupt STD VI.VAR,U counter ELSE LDB #DISKRUN Restart the Virtual Interrupt STB >D.DSKTMR counter ENDC Or send me a good Email path and I'll send you the complete source. Of course, my offer of a disk full of programs in both source and object form for $10.00 is still open to everybody. Mail orders to: Dave Lewis 4417 Idaho apt 4 San Diego CA 92116 Now, a couple of questions for everybody out there: 1. How can a program running on a CoCo3 (or a CoCo2 for that matter) tell if the SAM/GIME is running in the high speed (1.8 Mhz) clock mode? Something quick and short if possible. 2. What features would you like to see in another completely new OS-9 disk driver I'm writing? (Sorry, this one won't be shareware. I don't regret releasing NewDisk under those terms, but it wouldn't be a good return on the work I'm planning to put into this new one. I'll continue to support and distribute NewDisk and the others I've released.) Here are some features I've thought of; I'd like some feedback on how important you would consider each of them (like, "I WANT it!" or, "Nice, but I can do without" or "If you put THAT in I'll patch it out with Debug!"). The ones I consider most important/desirable are listed first. If you can think of any more features, tell me about them. - All the features of NewDisk for starters - OS-9 Level 2 support - High-speed mode: determine and save current E clock rate, set to normal speed (.89 Mhz) for disk access, restore former speed on exit - Support the "other" Setstat codes: SS.FRZ, SS.SPT, etc. - Double-step 96tpi drive to read 48tpi disks - Compensate for ticks missed while interrupts are disabled, so the real-time clock doesn't lose time - Support single-density, so it can read standard (Gimix format) OS-9 disks Mail replies to: ------------------------------- Dave Lewis Loral Instrumentation San Diego hp-sdd --\ ihnp4 --\ sdcrdcf --\ bang --\ kontron -\ csndvax ---\ calmasd -->-->!crash --\ celerity --->------->!sdcsvax!sdcc3 --->--->!loral!dml (uucp) dcdwest ---/ gould9 --/ "Hot diggity damn, I'm in the nut hatch and the head looney has come to talk to me" -------------------------------
dibble@rochester.ARPA (Peter C. Dibble) (01/07/87)
In article <972@midas.UUCP>, neals@midas.UUCP (Neal Sedell) writes: > > 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. ;-) What are you masking interrupts for MILLISECONDS for?!?? That's order of a thousand instructions. In any case masked interrupts aren't a problem unless you hold the mask for a long time (several milliseconds might be long enough). The processor will keep one interrupt pending if it comes in while it's masked. The disk driver cripples the CoCo by halting the processor, not by masking interrupts. Almost every device driver masks interrupts at least briefly. The 6809 itself turns on the interrupt mask every time it gets an interrupt. If you are concerned about missing interrupts you might try flipping back to the main task and enabling interrupts, then disabling and flipping back every few hundred instructions. Peter Dibble
neals@midas.UUCP (Neal Sedell) (01/09/87)
>What are you masking interrupts for MILLISECONDS for?!?? That's order of >a thousand instructions. In any case masked interrupts aren't a problem >unless you hold the mask for a long time (several milliseconds might >be long enough). The processor will keep one interrupt pending if it >comes in while it's masked. ... > >If you are concerned about missing interrupts you might try flipping >back to the main task and enabling interrupts, then disabling and flipping >back every few hundred instructions. Good to know I'm not just talking to myself, I was beginning to wonder! Actually, I was referring to the fact that to scroll the COCO3 screen you have to move 80*24*2 bytes which takes over 25 mS at 1.8MHz using the LDD 160,X STD ,X++ CMPX #XXXX and BLO loop. The ideas of switching the MMU back and reenabling interrupts every so often (like maybe every line) sounds good. > >The disk driver cripples the CoCo by halting the processor, not by masking >interrupts. Almost every device driver masks interrupts at least briefly. >The 6809 itself turns on the interrupt mask every time it gets an interrupt. Well, it has to do both, since you don't want the CPU going off to service an interrupt when it gets unHALTed. At 1.8MHz the halt becomes unnecessary since there is enough time to poll the floppy controller status register. Now for a new question - what is the Multi-Pak ghost referred to in the GIME posting? As a matter of fact, does anyone have the definitive definition of the M-PAK slot select register? I lost my instructions long ago and just put the disk controller in slot 4 and the RS232 PAK in slot 1. I took it apart one time and verified that along with the CTS and SCS outputs, the interrupt and another input get muxed to/from one and only one slot. I've been working on a dual RS-232, parallel printer port and battery backed up clock card so all my interrupts can fit in one slot. I just wish they had provided an "all slot interrupt enable" bit in the control register. If someone could mail me the above info to me it might be better than posting. Neal Sedell