2-Jun-84 21:23:01-MDT,5206;000000000000 Return-Path: Received: from BRL-MIS by SIMTEL20.ARPA with TCP; Sat 2 Jun 84 21:22:36-MDT Date: Sat, 2 Jun 84 23:16:39 EDT From: Bob Bloom (TECOM) To: info-modem7@Simtel20.ARPA, northstar-users@Simtel20.ARPA cc: rbloom@Apg-1.ARPA Subject: MEX with NorthStar's TSS/C A "moderate" call for help (I'm not desperate [yet]): I have MEX running fine on my NorthStar Horizon (second serial port) w/ZCPR2 under N*'s split BIOS CP/M. It works so fine that I've been trying to do the same on my work Horizon (from HSIO card) under N*'s multi-user os, TSS/C. I had MDM730 nearly working so MEX should be easy. First, what does work: straight terminal mode, ASCII capture and ASCII file send, Christensen upload, function keys, autodialing through the Hayes SmartModem 1200, and all the local functions. What doesn't work: Christensen download and some character loss directly attributed to the band switching and interrupts of the multi-user system. Also, ^C doesn't seem to abort the call command, I have to wait for it either to connect or abort. (It occassionally does require a reset to get out of a call command when it either refuses to accept the carrier or there is no answer.) Sometimes it takes abnormally long (10-20 seconds) for MEX to report a connection after the SmartModem has raised the carrier light. (This is without other users on the machine [sleep 10 does take 10 seconds] and I have installed the MEXNEWS.003 patches.) What's weird: upon exit from MEX, the TD line (pin 2) goes high and stays high until reset by MEX on next login. MDM7 does not do this when assembled with the same overlay. As I know that many of these are overlay related I've uploaded the overlay I'm using to OFFICE-1 (imp 43 on the net) with open protection. Maybe someone else can see what I'm missing. It's in MXO-TSSC.ASM. Christensen download doesn't work in MDM7 either, although the effect is different. MDM asks to delete the file (if existing) and dies with no outgoing transmission. MEX reports waiting ..., sends the ready character and then dies. Looking at the source code to MDM and doing some ddt'ing, in the routine RCVC3 it successfully does the CALL ERAFIL (@1804h) and CALL MAKEFIL (@1807h), but never does return from the CALL WAITQ1 (@180Ah). I'm not good enough to discover why (kept getting lost in jmps and calls). As best as I can see there are no terminal/system/os dependant calls in there so I'm at a loss why. What is there in both MEX and MDM7 in the download routines that would cause this sort of action? Especially since everything else seems it work as expected. I would think that a overlay i/o error would cause problems elsewhere too. The overlay I'm using is developed from the N* HSIO MDM7 overlay and Fowler's overlay for his multi-user system. I'm doing extended BDOS calls for input status and to input a character; normal port reads for output status and to output a character to a port. (When I used entended BDOS calls for output something really weird happened - everything was transmitted, but only in pairs!. A single keystroke would not transmit, the following one transmitted both. As direct "INs" worked, I gave up trying to figure out that one.) One question on Fowler's overlay: why is 'call instat' (check status of input) in the call to input a character? Shouldn't inchar be called only if instat has already returned positive? Why do it twice? On another point, is there anyone out there familiar with NorthStar's TSS/C os? I heard a rumor that a new version (current version is 1.1.0) will soon be released with enhanced capabilities. Anyone know anything on this? I have other problems with communication programs but these are attributable to the multi-user bank switching. As the very nature of bank switching makes communication difficult does ayone know how to: . Make the 16 character "channels" larger? . Move the modem channel to an unused memory block (FPB reserved area)? . Modify the interrupt system to put the modem input somewhere else than the input channel? . Or maybe to try to drop the DTR line on the input port when that channel is full so that an EXTERNAL buffer (MicroBuffer MBIS) can catch the output? (There is some code to do this within the MEX overlay, but it doesn't really work well - it really needs to be in the os.) As the overlay is written now, and with a external buffer, very few characters are lost at 300 baud. 1200 baud works only ok - as long as no one else logs in or hits the disk hard during long input strings. I'm really shooting for 9600 baud however - there is a direct line to a local mini I'd like to grab. Any suggestions/help is appreciated. (As I'll be away for a couple weeks on a travel assignment, anything that requires a answer from me will have to wait. But then although the above problems are vexing, MEX DOES work - except download. Thanks Ron Fowler for a great program. -bob bloom 8-Jun-84 22:48:42-MDT,1683;000000000000 Mail-From: RFOWLER created at 8-Jun-84 22:48:35 Date: 8 Jun 1984 22:48 MDT (Fri) Message-ID: Sender: RFOWLER@SIMTEL20 From: Ron Fowler < RFOWLER@SIMTEL20> To: Bob Bloom (TECOM) Cc: northstar-users@Simtel20.ARPA, rbloom@Apg-1.ARPA Subject: MEX with NorthStar's TSS/C In-reply-to: Msg of 2 Jun 1984 21:16-MDT from Bob Bloom (TECOM) I think the bulk of your problem is length of interrupt-driven- input queues (is that what you're referring to by "16-character channels"?) ...For Christensen protocol to work correctly on a multiuser system, you have to be able to receive up to about 132 characters open-loop ... we have 134 character buffers on our multiuser system at work. Anything less is simply not acceptable for Christensen, and will cause received transmissions to bomb (note that transmitting will work fine unless the system is out- rageously busy)}i. My overlay calls status from data-in because it was originally written for MDM712 or thereabouts ... I wasn't sure if MDM called status first in all cases, and didn't want to take any chances hanging the system. I have to admit that our OS is tailored toward modem transfers moreso than most (except perhaps TurboDOS) ... since I wrote the OS, I made sure that it would function correctly with modem programs (rather than the other way around). By the way, with the large input buffers, we routinely do 9600 baud error-free transfers between local systems over RS232 links; only when the systems are extremely busy do we get retries (our OS does bank-switching also: one TPA per bank). --Ron 20-Jun-84 06:04:27-MDT,1179;000000000000 Return-Path: Received: from mitre-bedford by SIMTEL20.ARPA with TCP; Wed 20 Jun 84 06:04:19-MDT Date: Wednesday, 20 Jun 1984 07:56-EDT From: jrv@Mitre-Bedford To: northstar-users@simtel20 Subject: gmgradd I have uncovered a subtile bug in GMGRADD, the program that adds the graphics manager to a user program. It normally terminates with the message GRAPHICS MANAGER HAS BEEN APPENDED TO YOUR COM FILE. If the original file has length 48K or larger, you get the message YOUR COM FILE IS TOO BIG (>=48K). The interesting part is that you also get this message if the com file is exactly 32K (=128 pages or 256 records)! If the original file is exactly 16K (=64 pages or 128 records), you get the message GRAPHICS MANAGER MAY NOT BE APPENDED FOR THE REASON BELOW: WRITE ERROR (OUT OF SPACE PERHAPS). The workaround for either a 16K or 32K program is to read it in with DDT, escape to the operating system, and SAVE it, making it just one page longer. I called Northstar about the problem long ago. They didn't sound interested at the time, but may have fixed the bug by now. If so, nobody notified me. - Jim Van Zandt