Date: 10 Oct 85 From: JAFW801 at CALSTATE (Jack Bryans 213-498-4569) To: SY.FDC at CU20B Subject: Kermit for the intel RMX OS I'm releasing RMXKERMIT this week. I'll get a tape off to you as soon as I can get DP to do it. Our campus bookstore will send out 5 1/4" DSDD RMX format disks for $6/disk. Disk 1 contains the executable program & documentation. Disk 2 contains source code for those who want it. Orders can be sent to: University Bookstore Computer Shop 6049 E. 7th St. Long Beach, CA 90840 Here's the list of changes I promised you, starting with module MSKERM. First, the only substantive change I've made is the SETINT routine: SETINT PROC NEAR push ds ; Don't forget this. [25] mov ax,geti23 ; get interrupt vector 23h [26a] int dos ; [26a] mov in3ad,bx ; save original values [26a] mov in3ad+2,es ; [26a] mov ax,cs mov ds,ax ; Access code are. mov dx,offset intbrk mov al,23H ; On ^C, goto above address. mov ah,25H int dos pop ds ret SETINT ENDP where geti23 in the data segment is: geti23 equ 3523h ; get interrupt vector for level 23h [26a] In the following, numbers in parentheses are approximate V2.26 line numbers. @spath9+2 inserted "mov ax,bx" following "call isfile" (1391) to fix a bug. MSKERM contained 3 references to "seg datas" & 5 to "seg stack". They were changed to "datas" & "stack". (167) "in3ad dd 0" changed to "in3ad dw 2 dup(0)" (234) "mov ax,es[2]" " "mov ax,es:word ptr[2]" (263) "mov ax,es:[env]" " "mov ax,es:word ptr[env]" (683) "mov cl,es:[cline]" " "mov cl,es:byte ptr[cline]" (830) "mov es:2,ax" " "mov es:word ptr[2],ax" (836) "mov word ptr es:[terma]. . ." " "mov es:word ptr[terma]. . ." (837) "mov es:[terma+2],cs" " "mov es:word ptr[terma+2],cs" (864) "mov word ptr cs:[doit+2],ax" " "mov word ptr doit+2,ax" (868) "jmp cs: dword ptr [doit]" " "jmp doit[0]" (879) "doit dd 100h" moved between "DELETE ENDP" & "CHKDSK PROC" (or anywhere in the code segment that makes it a backward reference) (1212) "mov ax,es:[env]" changed to "mov ax,es:word ptr[env]" MSFILE had commas at the end of 5 "public" lines (1-5). They were deleted. Also: (235) "lea ax,outbuf" changed to "mov ax,offset outbuf" (428) "gthcr0: lea bx,inbuf" " "gtchr0: mov bx,offset inbuf" Fianlly in MSSET: (434) "lea di,defkw+1[bx]" changed to "lea di,defkw[bx+1]" The code segment card in all modules was changed to: code segment public 'code' The following bugs were noted, but left untouched: MSSERV's srvini doesn't set ax before calling spar; neither does srvsnd. MSSEND's SPAR doesn't set temp4 before the jmp to sparx2, which uses it. MSFILE when setting the fcb to "PRN" following gofil7a, should use "mov cx,12" instead of 11. I haven't chased it down, but when MSKERMIT is the remote KERMIT & you delete a file, the next file sent to it will have the name of the deleted file. Suggestions: If MSCOMM bypassed calling dconio following inchr1 when remflg is set, I could pull some kludge code out of my dconio emulation routine. If MSCOMM's outpkt routine is moved to the MSX module, systems that are hurt by character-at-a-time I/O would be benefited. I can BITNET the submit file that converts .ASM modules to .A86, if you'd like. Date: 15 Oct 85 From: JAFW801 at CALSTATE (Jack Bryans 213-498-4569) To: FDCCU at CUVMA Subject: Kermit problems There are problems in running MSKERMIT, V2.26,in SERVER mode, especially in 1 port systems. In this situation, MSKERMIT is running as the "remote" system, and is usually directly connected to another computer opertating as the local system. In most cases the highest common baud rate would be chosen. In SERVER mode, KERMIT should be "quiet" on the CRT. When there are errors, though, either a retry or error count is being thrown up on the screen. In a 1 port configuration, this goes out the COM port & compounds the transmission error. Prob'ly one of the screen outputs snuck by w/o checking flags.remflg. In MSCOMM, INPKT's subroutine, INCHR, after label inchr1, dconio is called right after prtchr. In a 1 port system, dconio & prtchr are competing for input from the serial communication port. This leads to intermittent timing problems, especially at higher baud rates. If INCHR were to check flags.remflg before calling dconio, the 1 port problem would be fixed, but then you couldn't ^C out of server mode when you have an active terminal on the "remote" system. The problem here is that SERVER sets flags.remflg. (Doesn't this make SET REMOTE ON superflous?) If it didn't, then in SERVER mode w/REMOTE OFF, a whole mess of displays would probably start showing up on the "remote" system's CRT. Maybe thats not so bad, since it's under user control. What do you think? I'm guessing that running MSKERMIT as a slave in SERVER mode has hardly ever been used. There are a lot of INTEL System 310's with only 1 port, especailly at universities. The only way they can use KERMIT is in SERVER mode, w/the other computer acting as the INTEL system's terminal as well as SERVER master. MSKERMIT isn't fully paramaterized for dmasiz. MSFILE has a mess of refs to 80h still in it. They are: line # label 415 bufhex dw 80h 723 outbf1: add tfilsz+2,80h 955 inbuf1: sub filsiz+2,80h 957 "+2 add tfilsiz+2,80h 963 "+8 mov al,80h Changing these 80h's to dmasiz would paramaterize up to 255. To allow for 256 & up, the following additional changes would do it: In MSFILE, that mov al,80h becomes mov ax,dmasiz. Also, at inbf21, the mov ah,0 is deleted and its predecessor, dec al, becomes dec ax. In MSKERM, at gcmdl2+10 instr. (~#1238), the mov [bx].takchl,cl becomes mov . . . ,cx. In MSSET, at docom2+11 instr. (~#1305), the same change is made. In MSDEFS.H's takinfo structure, takchl becomes a dw instead of a db. Big deal, in experimenting w/these changes & using a 1024 disk buffer only a few % throughput improvment was found on my system. Since I went through the excercise, I thought I'd pass on what I learned. The next message I send will be the contents of the document that supplements yours for RMXKERMIT. It should give you a better idea what it is. I started sending RMXKERMIT out last week. By the way, our BITNET coordinator tells me that CU20B is a node on another network that we can't access yet. 14-Feb-86 21:10:48-EST,2542;000000000011 Return-Path: Received: from WISCVM.WISC.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 14 Feb 86 21:10:33-EST Received: from (JAFW801)CALSTATE.BITNET by WISCVM.WISC.EDU on 02/14/86 at 17:28:21 CST Return-Path: Date: Friday February 14, 1986 3:27 PM PST. From: Subject: RMXKERMIT To: We're finally able to use KERMSRV. I notice my RMX porting of MSKERMIT is still in AAWAIT.HLP. Here's an AAFILES.HLP format notice for floppy orders. INTEL SYSTEM 86/3XX UNDER RMX OS: -------------------------------- (A) UNIVERSITY BOOKSTORE COMPUTER SHOP 6049 E. 7TH ST. LONG BEACH, CA 90840 213-498-6258 ELECTRONIC CONTACT (INFO ONLY): JAFW801@CALSTATE DISK#1 IS EXECUTABLE & DOCUMENTATION. DISK#2 IS SOURCE & SUBMIT. BOTH ARE 5 1/4" DSDD RMX FORMAT. $6.00/DISK, POSTAGE INCLUDED. DOMESTIC ORDERS DESIRING UPS 2ND DAY DELIVERY ADD $3.00/ORDER. INTERNATIONAL ORDERS ADD $2.00/ORDER. Did you get my 1/27/86 msg on Microsoft/Intel assembler compatability? Did giving you the name af the person @Columbia with an Intel 310 help any? If not, would BITNETing me current 2.29 source to try out on Intel assembler be any help? A problem w/communicating w/VAX exists in released version. The following is the content of a msg describing fix I'm sending w/all orders since 2/10, and to anyone who asks via BITNET. VAX peppers its dialog w/NULs, which hangs up RMXKERMIT. The following changes to RMXKERMIT change the buffer fill to RUB from NUL. Make sure your HOST doesn't send or echo RUBOUT when using these changes. Changed instructions are in upper case. MSXRMX, PROC PRTCHR . . . PRTCH1: mov si,savsi cld lodsb CMP AL,0FFH JE PRTCH6 PRTCH2: . . . MSXRMX, PROC CLRBUF CLRBUF PROC NEAR push es mov ax,ds mov es,ax cli cld mov di,savsi mov cx,offset source+size source sub cx,di MOV AL,0FFH repne scasb . . . RMXKERM, PROC SREAD sread proc mov ax,ds mov es,ax mov bx,srcptr mov di,bx MOV AX,0FFFFH mov cx,bufsiz/8 . . . Please acknowledge receipt, as this end of BITNET doesn't always let us know when mail is undelivered. Jack Bryans