Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdahl!nsc!voder!wlbr!pete
From: pete@wlbr.EATON.COM (Pete Lyall)
Newsgroups: comp.sys.m6809
Subject: Re: homebrew coco serial port problems
Message-ID: <1117@wlbr.EATON.COM>
Date: Fri, 21-Aug-87 19:09:44 EDT
Article-I.D.: wlbr.1117
Posted: Fri Aug 21 19:09:44 1987
Date-Received: Sun, 23-Aug-87 06:36:37 EDT
References: <822@sask.UUCP>
Reply-To: pete@wlbr.UUCP (0000-Pete Lyall)
Organization: Eaton IMS, Westlake Village, CA
Lines: 56
Keywords: 6551

In article <822@sask.UUCP> clay@sask.UUCP (Clay Cederstrand) writes:
>
>and since /T2 is interrupt driven, it looks on the surface as though there
>could be lost data problems with the disk controller masking interrupts at 
>at high baud rates. Anyone have any knowledge of, or experience with the
>rs232 pak and its operation at high baud rates, especially with programs
>such as kermit ?
>
>The pain in the rear problem occurs when I use kermit to download files,
>when the file is downloaded the stinking drive it was accessing continues
>to be selected and runs constantly. You can exit kermit and use OS9
>normally as before, even access any drives, but when a disk access is done
>the drive that kermit used will be reselected and continue running. Any
>idea's what is happening here?  It can't be a hardware problem since the
>drives can still be accessed after and otherwise function normally.

The drives running continuously is a problem with the way VIRQ's are
handled... Tandy really munged up the code, and as a result it's not
really all that reentrant. Kent Meyers (who is on the net here at
..!chinet!draco) has done some significant work in that area.. I
believe he discovered it. Also, there may be a piece in Kevin
Darling's book INSIDE OS9 LII (available from Frank Hogg). There might
already be a fix for this.

Your best overall fix is to toss the VIRQ driven MODPAK driver, for
the following reasons:

a) It's no good for anything medium to high speed, as you can see.
Design limitation.

b) Yes you CAN lose characters (also, see below)

c) The VIRQ implementation is not clean.

The Rs-232 pak can also lose characters, if the disk drive gets
control. He (controller) actually HALTs the CPU.. worse than
interrupt lockout. They still keep the CART/FIRQ portion of the
multipak select latch set to slot 1 (rs-232 pak) most of the time, but
they do toggle the SCS line between slots (scratching old memory cells
here). I just installed a hard-wired IRQ line and passed it to the
CPU. I believe this is pin 8 on the cartridge slots, and pin 3 of the
CPU chip (again, from memory).

If you are using the standard os9 UG kermit (version 1.6, I think)
there is a flag for compiling it for COCO's... this flag inhibits
overlapped I/O.. It does the disk write first, then sends back the
ACK. This method of flow control will work with the floppy lockout
problem. Also, Xmodem implicity does the same kind of flow control.



-- 
                                                   Pete Lyall

Usenet:     {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)