17-Mar-86 06:20:30-EST,5677;000000000001 Received: from CUVMA by CU20B with HASP; 17 Mar 86 06:20:28 EST Received: from USU(JRD) by CUVMA (Mailer X1.23a) id 5876; Sun, 16 Mar 86 21:36:58 EST Date: 16 MAR 86 19:39-MST From: JRD@USU To: SY.FDC@CU20B Subject: MS Kermit for non-IBM machines. Frank and Howie, Subject: MS Kermit for non-IBM machines. The list below summarizes the modules extracted last week from Columbia's Kermsrv and which have been tested with the latest MS Kermit main body code. Changes have been made to the msx modules, except for msxtek, to: 1) add the global entry point VTSTAT for use by Status in mssset.asm, this procedure just returns; 2) ensure the terminal emulation flag, flags.vtflg, is cleared at initialization time; 3) add register save/restore in procedure getbaud (things are dirty there); 4) revise name of header file from msdefs.h to mssdef.h where necessary; the same change was made to msy modules. Module msxrb, for the Rainbow, has had more extensive changes made. These are removal of the old memory management calls to malloc and replacement by calls to new procedure sbrk. The screen buffer code has been modified accordingly, but it has not yet been tested on a real Rainbow. Since malloc was used only by the Rainbow and IBM versions of Kermit it is retained for historical reasons but sbrk is used instead. Each Kermit below, again except as noted, was assembled and linked without error. Each was run on my Zenith 151 clone of an IBM PC. As the notes indicate below most Kermits caused problems when the serial port was touched due to hardware differences between machines. A few (the NEC machines AP3 and APC plus APR) are hostile to my hard disk. The Wang version had a register corruption problem which caused loss of control during a Status display; that was fixed by the register save/restore code. MSXAP3 ASM 20364 3-13-86 7:00p initialization crash, eats hard disks. MSXAPC ASM 46509 3-12-86 9:03p same comment as msxap3. MSXAPR ASM 21033 3-16-86 1:55p same comment as msxap3. MSXDM2 ASM 15475 3-12-86 8:56p works ok through part of connect mode. MSXDMB ASM 121 3-11-86 6:43p not needed. Left over from old days. MSXEZP ASM 32364 3-16-86 2:27p works in connect mode. MSXGEN ASM 15017 3-13-86 9:09p works in connect mode. MSXGRI ASM 31037 3-16-86 2:35p initialization crash. MSXHP1 ASM 10724 3-16-86 2:03p works until connect mode entered. MSXHPX ASM 16369 3-12-86 8:58p works in connect mode. MSXIBM ASM 22611 3-12-86 10:42p Old version of IBM code. Obsolete. MSXM24 ASM 31902 3-16-86 2:41p works in connect mode. MSXMBC ASM 26001 3-16-86 2:46p works until connect mode entered. MSXRB ASM 51790 3-16-86 1:36p works until connect mode entered. MSXTEK ASM 7135 3-11-86 6:57p Not touched, very non-standard. MSXTIP ASM 36342 3-16-86 2:52p initialization crash. MSXV90 ASM 32707 3-16-86 2:18p works until connect mode entered. MSXWNG ASM 14740 3-16-86 2:09p works until connect mode entered. MSXZ10 ASM 15871 3-15-86 3:53p init problem on IBM due to Bios call. MSXZ100 ASM 15429 3-12-86 9:10p init problem on IBM due to Bios call. MSYEZP ASM 48666 3-12-86 9:26p removed internal def of lnwrap. MSYIBM ASM 35433 3-11-86 8:05p Old verson of IBM code. Obsolete. MSYM24 ASM 76877 3-12-86 9:28p removed internal def of lnwrap. MSYTIP ASM 44401 3-12-86 9:31p MSYV90 ASM 14123 3-12-86 9:19p MSYV9T ASM 61582 3-12-86 9:32p not tested. update ref to mssdef.h, needs sbrk to avoid segment Graph. MSYZ10 ASM 16016 3-11-86 7:12p MSYZ100 ASM 16017 3-13-86 7:43p The updated modules being returned to you (in Howie's dir) are as follows: msxap3.asm msxapc.asm msxapr.asm msxdm2.asm msxezp.asm, msyezp.asm msxgen.asm msxgri.asm msxhp1.asm msxhpx.asm msxm24.asm, msym24.asm msxmbc.asm msxrb.asm msxtip.asm, msytip.asm msxv90.asm, msyv90.asm msxwng.asm msxz10.asm, msyz10.asm msxz100.asm, msyz100.asm Module msyv9t.asm (Victor 9000 Tek 4010) needs updating to use my sbrk procedure, in mssker, to replace their segment Graph. I did not do so because of the extensive hardware specific constructions in that module. Here is a comment added to PRTCHR in msxgen which applies to modules based upon it, and to comms difficulties in general (i.e., just after booting DOS thinks the serial port has a received char, it does not really, because of a short coming in DOS's initialization procedures). ; Note added by [jrd]: The test for char-at-input-port is int 21h function ; 44h (ioctl) sub function 6 (get input status). On many systems an FFH will ; be reported (meaning Ready) even though no char is available; the Ready ; indication is misleading. In such cases the system will wait for a char ; and will appear to be hung. A preferrable method is to use the ROM Bios ; call int 14H function 3 (get port status) and if the lsb of the returned ; 8 bits in AH is 1 then a char is availble at the port; this assumes that ; the machine emulates this ROM Bios operation. ; Lastly, if the current code is used and the system hangs then reboot ; and say ECHO Hello >COM1 before running Kermit; this should make MSDOS ; truely aware of the port's actual status. Dark grey magic. Good luck! [jrd] The updated main body code is being sent along separately. Regards, Joe D.