clay@sask.UUCP (Clay Cederstrand) (08/19/87)
I recently added a homebrew UART cct (6551 ACIA) to my coco3, specifically to the disto disk controller on the coco3. It works basically OK except for two teeny tiny problems, OK OK you dragged it out of me, one teeny tiny problem, and one that is a real pain in the rear. Because I did not as yet hook up the interrupt line from the 6551 I can only use 300 baud operation through a modified /t3 descriptor ( only the address of the device was changed ) and the modpak driver which uses the virtual interrupt handler routine. The 300 baud is a limitation imposed by the VIRQ handler, the clock interrupts every 16 msec, any speed higher than 600 baud would result in lost data. This brings me to the teeny tiny problem, since the NMI is the only interrupt line brought out the cart port 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. Any info greatly appreciated. Clay Cederstrand Technician at large ( or is it a large technician..I can never remember!) University of Saskatchewan
rms@frog.UUCP (Bob Santy, Software) (08/21/87)
I have also had "funny" behavior on the part of the ACIA chip in the RS232 pack. Upon having a discussion with Kevin Darling (one of the CIS OS9 COCO experts on CompuServe), I started experimenting with slowing the COCO III down to 1 Mhz inside the ACIA driver with some success. The experiment was not completely successful because the interrupt handler slowed the system down upon receipt of control. The upshot of it is that some ACIA chips don't seem to like the E clock running above 1 Mhz. Slowing the clock down via a poke with the debugger gives the most success, but there must be something else I'm not doing because the behavior still exists but less frequent. The loss of characters on input which gets worse as the baud rate is increased is my main problem. Of course, I could be way off base with this assement of the problem. Comments appreciated. Bob Santy .
ronald@csuchico.EDU (Ronald Cole) (08/21/87)
In article <822@sask.UUCP>, clay@sask.UUCP (Clay Cederstrand) writes: > Anyone have any knowledge of, or experience with the > rs232 pak and its operation at high baud rates, especially with programs > such as kermit ? 4800 baud is the maximum I could get out of kermit and actually have it work reliably. Although I didn't use the best shielded cables and could definately say that it wasn't a noise problem, it looked like the overhead of using the FIRQ line (massaging the rest of the registers on the stack and making OS-9 think that it was really an IRQ) kept it from going faster on input. Output to 19200 baud has been no problem, however. -- Ronald Cole | uucp: ihnp4!csun!csuchic!ronald AT&T 3B5 System Administrator | PhoneNet: ronald@csuchico.edu @ the #_1_ party school in the nation: | voice (916) 895-4635 California State University, Chico "It's O.K." -Hal Landon Jr., Eraserhead
pete@wlbr.EATON.COM (Pete Lyall) (08/22/87)
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)