Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (02/28/86)
Info-IBMPC Digest Thursday, 27 February 1986 Volume 5 : Issue 28 This Week's Editor: Richard Gillmann Today's Topics: Time and Date from Turbo Pascal (4 msgs) Kermit+Lightning = Rubbish NANSI.ASM (2 msgs) Connecting to NBI Machines (2 msgs) QUICK-BASIC Comm Files Experience with QNX Operating System Thanks to MicroSoft Compiling Really Large Programs With Microsoft C V3.0 Color & Mono Cards in AT FAT City Blues - and how I fixed my hard disk ProComm Re: Lotus printer problem More SIG/M and PC/BLUE Volumes Available Today's Queries: QuicKey.asm Wanted Microsoft MASM Assembler Wish List Problem with 27 Lines on the EGA Cluster Size Query Prolog Query TRS Model 100 to IBM XT Connection Wanted XT-clone motherboard query Color Attribute Query Problem with MS-DOS command line length Intel 80186 Assembler Query Query: PCnet <--> 3Com Ethershare "Gateway" Window Package for Xenix Wanted dBASE File Format Query ---------------------------------------------------------------------- Date: 23 Feb 1986 22:09-EST Subject: Turbo Date/Time Code From: ABN.ISCAMS@USC-ISID.ARPA To: info-ibmpc@USC-ISIB.ARPA, bschaar@USC-ISIF.ARPA The request was for pointers to articles (or code) on date-time manipulation in Turbol Pascal. DEC-MARLBLRO (aka MARKET) has some excellent routines (for generic MS-DOS systems, supposedly) in the following files, available via ANONYMOUS FTP: TURBO:D_T_MANI.LBR TURBO:DATETIME.LBR Source code, of course, in squeezed files within a standard .LBR file. I'll be sending the requestor some extracts of documentation separately. Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID.ARPA ------------------------------ Date: 24 Feb 86 12:25 PST From: Ghenis.pasa@Xerox.COM Subject: Date and Time from Turbo Pascal To: info-ibmpc@USC-ISIB.ARPA To get date and time from Turbo Pascal, use the MSDOS function to execute the appropriate BDOS call. If you have Turbo 3.0 or later, on the distribution diskette there is a file called DOSFCALL.DOC which has the source for precisely this function. ------------------------------ Date: Sun, 23 Feb 86 19:26:56 PST From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA To: info-ibmpc@USC-ISIB.ARPA Subject: Time of Day Function for Turbo Pascal Function Secnds:Real; { This function returns the seconds past midnight as Real number Input None Output Secnds Seconds past midnight as a Real number Strategy (1) Call DOS to get the time (2) Convert to floating point seconds past midnight } Type Result=Record Ax,Bx,Cx,Dx,Bp,Si,Di,Ds,Es,Flags:Integer; End; Var Sys:Result; Begin SYS.AX:=$2C00 { AH is get time }; Intr($21,Sys); If Odd(Sys.Flags) then Begin Writeln('Error getting the time'); Halt; End; Secnds:=Lo(SYS.DX)/100.+Hi(SYS.DX)+60.*(Lo(SYS.CX)+60.*Hi(SYS.CX)); End; ------------------------------ Date: Wed, 26 Feb 86 09:11 EST From: MKATZ%UMDA.BITNET@WISCVM.WISC.EDU Subject: Time and Date from Turbo Pascal To: BSCHAAR@USC-ISIF.ARPA, INFO-IBMPC@USC-ISIB.ARPA I saw a message on VMBBOARD@WEIZMANN asking about Time and Date from Turbo Pascal. I have used Bdos calls from Turbo in CPM86 to get the date and time. No assembly language is needed. In MS-DOS the procedure should be similar. Set up the registers like it says in the Turbo manual (you have to declare a record for it). For date do an interrupt 21h (there is a Turbo function to do interrupts but I don't have the manual here so I am not sure what it is called - probably Intr) with AH (thats the high byte of AX) = 2Ah. For For time AH = 2Ch. Date is returned as CX = year, DH = month, DL - day. Time is returned as CH = hours, CL = minutes, DH = seconds, DL = 1/100 seconds. This should all work the first time, however I have found more than a few typos in the Assembly book I am using so I can't guarantee it. Manasseh Katz ------------------------------ Date: Thu, 27 Feb 86 00:21:05 -0100 From: gaffney@nta-vax.arpa (Patrick Gaffney CMI) To: info-ibmpc@usc-isib Subject: Kermit+Lightning = Rubbish When I use kermit to download a file to my PC that is running Turbo Lightning the resultant file contains rubbish. If I remove Lightning and repeat the process the file is ok. Has anyone else encountered this effect? Pat Gaffney ------------------------------ Date: 23 Feb 1986 15:22:56 CST Subject: Re: Snowy Mode with NANSI.ASM From: HUNEYCUTT@GUNTER-ADAM.ARPA I'd suggest an 'extended' mode-set sequence to allow the programmer to set the NANSI driver for two different kinds of CGA...those that snow and those that don't. To avoid snow on some cards (like IBM's), you have to put in some code to test the retrace status..if the card is retracing (and the signal therefore blanked), you can update the screen memory. If not, and you update screen memory anyway, you'll get snow because of conflicting access to video RAM. Newer designs (such as on the ZDS Z-15x and 2xx machines) do this checking in the video interrupt handler code or in the hardware of the card itself. If you check retraces on the newer style card, you'll unnecessarily slow down screen displays (but be guaranteed of no snow!). I realize that adding 'nonstandard' sequences is a nasty thing to do in a standard environment, but this is one case I feel the user should be given the option. Doug [This is the joy of access to source code. This seems like a perfect case for a conditional assembly. Any volunteers? -wab] ------------------------------ Date: Tue 25 Feb 86 14:30:35-EST From: Paul G. Weiss <PGW@XX.LCS.MIT.EDU> Subject: DOS Console Handling Query To: info-ibmpc@USC-ISIB.ARPA I have uploaded NANSI from the program library and it raises some questions about DOS console buffering that I hope some DOS maven can answer. I noticed that when raw mode is turned on there is no processing of escape sequences or tabs if I used the DOS write function call to STDOUT. My question is how do device drivers, buffering, int 29h, raw mode and BIOS teletype interface all work together? In light of this, what is the difference between using DOS function calls 3f and 40 to do console I/O and using the console-specific calls. ------------------------------ Date: Tuesday, 25 February 1986 13:26:19 EST From: Paul.Birkel@k.cs.cmu.edu To: info-ibmpc@usc-isib.arpa Subject: Query: Exchanging files with an NBI Machine Here's an interesting problem. I need to exchange files with an NBI Word Processing "machine". Don't ask me why anyone would actually buy one of these beasts instead of a CHEAPER (!) PC-AT or CP/M machine, but here's the situation. They have one or two 5 1/4 inch floppies, no hard disk, are probably 8 bit machines, and drive a multiple port letter-quality printer. We've been told that to connect another brand machine to one of the "extra" LQP ports will void the warrenty. Heaven forbid! The better solution would be able to read/write to NBI disks, if possible. Since there are the appropriate software packages to transfer between CP/M formats and PC-DOS formats, it would be nice to do the same with the NBI format. And seemingly reasonable, too. Although our current machine is a CP/M, we have access to a PC-AT as a potential intermediary. The question is, how to get from one of them to the NBI? Assuming that files are ASCII (am I assuming too much?), and that a standard floppy controller chip is used, this should be possible. Unfortunately, NBI has been very unhelpful (as you can gather from the above comment). I guess they just want to sell more of their machines rather than to talk with the rest of the world. Can anyone help me with additional information, technical data, a word of advice, solace? Also, if you know of any other forums than info-cpm and info-ibmpc in which such a question could be addressed would you please direct this message there? My sincere thanks. paul.birkel@A.CS.CMU.EDU (412) 268-3074 Carnegie-Mellon University Dept. of Computer Science Pittsburgh, PA 15213 ------------------------------ Date: Wed, 26 Feb 86 08:09:15 -0500 From: Jeff Edelheit <edelheit@mitre.ARPA> To: paul.birkel@cmu-cs-k.ARPA Cc: info-ibmpc@usc-isib.ARPAC, info-cpm@amsaa.ARPA Subject: Re: Connecting to NBI Machines Paul - We use a lot of NBIs here. My first comment is that they do not talk very well to anything! There is a Canadian company (the name escapes me at the moment) that manufactures a box that hooks-up to your PC/AT. This box has, if I remember right, one 8" drive & one 5 1/4 drive. You put their conversion floppy into the AT and your source/destination floppies in and the conversion box attempts to translate from one wp disk to the other. It will also do a wp to ascii conversion. The big problem is that this box & software supposedly costs BIG $$$ ($7k+). For the money, though, it is supposed to work well. If you want to go that route, get back to me and I'll try to dig-up some details. The "cheap" way to go is to connect a pc to the NBI's serial port and "transmit" or "receive" documents from/to the NBI. We have found the fastest speed that really works is 4800 bps. Generally, the screen shows a loss of characters, but the characters really do show up. If you transfer a document from the NBI, anything that is underscored gets transferred as just the underscores. (It looks like NBI handles underscoring by typing the word, backspacing and underlining.) Our search for a file transfer protocol for the NBI was unsuccessful. BTW, the VT100 emulator for the NBI doesn't work if you try to use it going into a UNIX host and want to do vi. NBI's response was "Yes, we know of that problem; no, we're not going to fix it; and you should realize that our VT100 emulator doesn't do anything really sophisticated like true cursor addressing." One more thing. NBI makes a board for the PC that allows you to do NBI word processing on an IBM PC. Perhaps that will allow you to read NBI disks on the PC. Since I don't have one of those boards, I can't really tell you much. Maybe NBI can (ha!) Regards, Jeff Edelheit (edelheit@mitre) ------------------------------ Date: Sun, 23 Feb 86 12:55:34 PST From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA To: info-ibmpc@USC-ISIB.ARPA Subject: QUICK-BASIC Comm Files Excerpts from a Local BBS From: BILL ANGUS Date: 23-Feb-1986 11:55:36 I understand from the people at microsoft that the feature which allows one to open COM1 as if it were a file, will only work if the com1 port does not receive a ctrl break character from the remote station which may be communicating via this com1 port. The woman at Microsoft who explained the problem to me said that DOS interupt 14h which is used by the basic compiler to facilitate the opening of communications, does a continuous check for ctrl break. If ctrl break is encountered, then the program attempts to halt (!) processing. She also referred me to the book PROGRAMMING THE IBMPC by NORTON (which I don't have unfortunately). MY QUESTION IS... Does anybody out there know if the following is the easiest way to prevent <ctrl break> from getting through and crashing my program? 1) open com1 .... 2) execute a com off command 3) whenever input output is desired, check for a character from the remote user at the com port using the inp function.... 4) if a character is sent and if it is ctrl break, then disallow it else pass the character along to an input buffer in the program..... From: SYSOP Date: 23-Feb-1986 12:31:03 From the description of the bug by Bill Angus, I would recommend that you write an Assembler procedure for Quick-Basic which grabs the contents of INT 14h (ie saves the four bytes at 0:50h and loads its entry there) and then proceeds to clear the error bits out of the COM1 status at port 3FDh, before passing control onto the BIOS com INT 14h handler, by PUSHing the four bytes (saved from 0:50h) on the stack, then IRET. This will guarantee that the BIOS never sees a communications error! ------------------------------ Date: 23 February 1986, 14:36:02 EST From: Peter Allsop (Chemical Eng., UofW) <ALLSOP%WATACS.BITNET@WISCVM.WISC.EDU> To: info-ibmpc@usc-isib.ARPA Subject: Experience with QNX Operating System This is in response to a recent query by Tom Helbekkmo concerning the QNX operating system. I have been using QNX on an IBM-PC (576K RAM, 5M Davong, 1 floppy) for 4 or 5 years (I started with a pre-release version), and on a DEC Rainbow for about 2 years (off and on). The majority of my work involves real time process control, were speed and efficiency at run time are more important than ease of software development. I am not a Unix expert, nor any other kind for that matter, and cannot comment on how Unix-like QNX is (Quantum claims 4.something compatibility). Neither do I have any experience with the networked version of QNX, although I have a few friends who use (and like) it. Weigh my comments accordingly. >>> The Operating System: Basically I am very satisfied with the operating system, now that I know how to use it. The user is given a great deal of control over the environment, and the device interface proceedures are very easy to use (eg: much better than Venix on the Pro-350). A number of useful (to me) utilities are included, such as: -Device independant graphics utilities, which allow you to define your own devices after writing (and compiling) the program. -User tasks can "adopt" devices, effectively replacing the device administrator for that device. -Define your own memory resident shared libraries. -Intertask signalling and message handling proceedures. -The basic utilities to allow the user to manage resources independantly of the OS (semiphores, etc). -An auto-answer modem control program, so you can sign on from home. -Drivers for several different hard disks, and a RAM disk utility. -A windows handling routine, allowing up to 4 windows on the console. -A full screen editor that makes XEDIT on VM/CMS (KEDIT on IBM-PC) look sick, both in speed and power. -A whole bunch of other stuff that I rarely (never) use. These allow system accounting, debugging, and ??. The C compiler is very standard, and comes in two flavors: shared library math (SLM) and inline 8087 math (IM). The SLM uses one of two memory resident shared libraries (both supplied), one using the 8087 and the other ignoring it. The advantage of this version is that you can move programs between computers without having to worry about an 8087, but it is *slow*. The IM version generates (you guessed it) inline 8087 code, and is about 10 fold faster than the shared lib 8087 version. I think that Quantum is going to merge the two compilers, the user supplying a compiler flag to select SLM or IM. The code generated by the IM C compiler (the one I use) is very efficient. I rarely get even a 2 fold speed increase when I re-code in assembler, and most of my software involves a lots of iteration! In fact I don't even bother using assembler any more, unless it is a very heavily used math routine. There are several other QNX compilers available, including BASIC, Pascal, and Fortran (I think). Quantum claims that you can mix (link) program segments coded in different languages together, but I've only used C. There are also several "extras" available, including a word processor, a spellin checker, a database manager, and a utility which allows a DOS program to run under QNX. QNX does have a few drawbacks. My major complaint is that the manuals don't have an index!! This isn't a great hassle once you get to know them, but in the interm ... it's hell! Another annoyance is the size of the system itself, you only get about 40K of user space out of a 256K machine! Finally, the C compiler (at least) will only allow 64K of code and 64K of data. This doesn't bother me, since I can always request a chunk of memory from the OS and manage it myself (utilities are provided), but if you don't want to ... >>> The Company (Quantum): This is were QNX falls down the most. Quantum is a technically oriented company, and they aren't too swift at marketing. This means that they tend to be a bit slow on delivery, and don't understand user's complaints about the manuals (see above). Their technical support, however, is excellent. Quantum includes two types of support with every system: a telephone hotline and an on-line update service. The hotline puts you in touch with a systems programmer, who has access to a duplicate of your OS. (Quantum maintains an on- line database which tells them which version of each module you have). I find these people very helpful, and their turn around on OS fixes is rarely greater than 24 hr. Even better, though, is the on-line update system. The on-line update system allows you to phone Quantum and sign-on to their database system. This system maintains bug reports, explanatory notes (eg: recovering erased files), current versions of the OS and utilities, and a mail system. Using this you can download system updates directly over the phone, or submit questions/bug reports with examples. They are even talking about connecting this to DATAPAC (thus TYMENET, ...). The update service is so good, in fact, that I can almost forgive them their manual! Peter Allsop <ALLSOP@WATACS.BITNET> Dept. of Chemical Engineering University of Waterloo (The usual disclamers: I have no connection with Quantum except as a (usually) satisfied user. The opinions expressed above are those of the author, and do not (necessarily) reflect the opinion of the Department, the University, or anyone else with any authority.) ------------------------------ Date: Sat 22 Feb 86 15:56:31-PST From: Bob Knight <KNIGHT@SRI-NIC.ARPA> Subject: Thanks to MicroSoft To: info-ibmpc@USC-ISIB.ARPA I want to express my thanks to the following people at MicroSoft: Dan Newell, Cindy K, and Lori Zeebe Through INFO-IBMPC, Dan knew of my problems with Quick Basic and passed them to Cindy. Cindy apprised me of the availability of version 1.02 to registered owners. Lori expedited my receipt of same today. Having downloaded my application to New Mexico, preliminary results indicate that 1.02 has fixed our problems. It is rare that one finds such quick response to a customer problem in a (relatively) large corporation. I find it gratifying to find same in Microsoft. I wish them every success in the future. Bob Knight ------------------------------ From: cramer%kontron.UUCP@BRL.ARPA Subject: Compiling Really Large Programs With Microsoft C V3.0 Date: Thu, 20-Feb-86 11:25:33 PST This is a helpful hint to those of you building really big programs on the IBM using Microsoft C V3.0. We have a large piece of C that we are developing simultaneously on a VAX and IBM AT -- roughly 40,000 lines of C, all linked together, no overlays. Unlike a lot of commercial products, our program has very large quantities of static data. (Your average spreadsheet has know problem gobbling up to and beyond 640K, but most of the memory is allocated -- not static.) If you don't read the Microsoft C manual in excruciating detail, you would think that compiling in large model (/AL on the command line) would be adequate for the largest program that will fit into the address space. Not so! From section 8.1.1.2 of the Microsoft C Compiler User's Guide: All segments with the same group name must fit into a single physical segment, which is up to 64K bytes long. This allows all segments in a group to be accessed through the same segment register. The Microsoft C compiler defines one group named DGROUP. The NULL, _DATA, CONST, BSS, c_common, and STACK segments are grouped together in the data group, called DGROUP. This allows the compiler to generate code for accessing data in each of these segments without constantly loading the segment values or using many segment overrides on instructions. DGROUP is addressed using the DS or SS segment register. DS and SS always contain the same value except when the "u" or "w" option of the /A option is used. As you can see by table 8.1 that follows in the same manual, even a large model program will try to put all the global and static data into one group, and that one group will be entirely in a 64K segment. The symptom is "fixup overflow near <address> in segment <name> in <file>.OBJ(<file>) offset <offset>" messages from the linker. The section quoted above might tempt you to use an option like /Alfu to allocate different segments for the stack and the data segments. In fact, this is what I tried first, and for reasons that are not immediately obvious, our program stopped dead in its track, looping endlessly. What does work is to use the options /AL and /Gt. From section 7.12 of the User's Guide: /Gt [<n>] By default, the compiler allocates all static and global data items to the default data segment. The /Gt option causes all data items greater than <n> bytes to be allocated to a new data segment. The effect is to create separate segments AND GROUPS for each module's static and global data. This doubtless requires more setting of segment registers -- but I can't see any obvious slowing of our program after recompiling with the /Gt option. One other item: a very large program will quickly exceed 128 segments, which is the default number of segments the Microsoft Linker likes to work with. Use the /SEGMENTS:<nbr> option on the link to deal with this. ------------------------------ Date: 24 Feb 1986 13:31:48-EST From: mlsmith@NADC To: Ghenis.pasa@Xerox.COM, info-IBMPC@USC-ISIB Subject: Color & Mono Cards in AT I have had both an IBM Monochrome and Color Graphics Adapter plugged in for about four months on an AT. I do not use either of the programs you mentioned. Despite appearances of simultaneous operation, the AT only talks to one display at a time.I use the monochrome display as a menu tablet, and then go to the color monitor for my programs. This leaves the menu up. More elaborate schemes are certainly possible. Two Adapters of the same type _is_ a problem, but I'm not sure about the EGA. Does anyone know if you can have two EGA's one in Monochrome mode and one in Color mode? ------------------------------ To: info-ibmpc@usc-isib.arpa Subject: FAT City Blues - and how I fixed my hard disk Date: Tue, 25 Feb 86 12:32:50 -0500 From: Mark Colan <mtc@ATHENA.MIT.EDU> I sent a report a few weeks ago about having trashed my hard disk AGAIN, and how I suspected that it was a software problem, not a hardware problem. I had been working with a large model Lattice C program, and tried to use an invalid pointer. Since DOS has no memory protection, it is possible to write over DOS, and whenever I do this, it always seems to be the disk driver database I hit. The disk failed badly after one particular execution of a program with a bad pointer, and I deduced that I had written over the driver in such a way that instead of writing a data block into a file, it wrote it in a random, and particularly wrong, block on the disk. The symptom was a lot of trashed files, and CHKDSK barfed badly. Various raw disk manipulation tools hung or refused to run. I ran the Advanced Diagnostics, Conditional Format, and it started from track 305, rather than the expected 610. When the diagnostics completed, it complained that there was less than 10 MB useable on the hard disk. The theory was that there was a place on the disk that told the world, even Adv Diags, about the disk, and that Formatting did not touch that area. Setup correctly identified the disk as Type 2, and the interleave was correctly set to 3, yet I had only a 10 MB disk. I tried to delete and restore the DOS partition, but after the DOS format, DOS thought it was a 10MB disk. It worked, but missing half the capacity. That theory seems to have been proven correct. I was able to restore my hard disk to relative normalcy by using the "Change Interleave Factor" function on the "Format Menu" of the hard disk diagnostics. The interleave factor is normally set to 3; I instructed the program to "change" it to 3. My guess was that it might, as a side effect, reinitialize other disk characteristics in the correct way. It worked! The Advanced Diagnostics Conditional Format now counts down from track 610, which means I again have a 20 Mb disk. Interesting that at least some of the problems I formerly attributed to bad hard disks on the AT were in fact software problems that resulted of the missing memory protection in DOS. Mark Colan MIT Project Athena ------------------------------ Date: Tue, 25 Feb 86 08:44:44 CST From: C346595%UMCVMB.BITNET@WISCVM.WISC.EDU (Bruce Barkelew) To: info-ibmpc@usc-isib.arpa Subject: ProComm PIL Software Systems PO Box 1471 Columbia, MO 65201 (314) 449-9401 I am the co-author of the communications program ProComm. I noticed our program mentioned here, so I thought I would let you know some more information. ProComm is a user supported product. We have just released version 2.2 (02/21/86). Version 2.2 has many improvements and additions. We now emulate 10 popular async terminals. The VT-100 emulation has been greatly improved. We support XMODEM, YMODEM, TELINK, MODEM7 and KERMIT file transfer protocols. Our KERMIT implementation has been completely re-coded from the ground up, and now supports all the latest features such as data compression, file attributes, and the new Sliding Window (full duplex) extension. Our script command language has been expanded also. ProComm runs under MS-DOS 2.0 or greater, and requires 128k of RAM. We a 24 hour support BBS running at (314) 449- 9401. The latest version is always available there. I don't mean this to sound like a commercial, but I saw messages here inquiring about us, so I thought I would supply the information. I can be reached at the above address or at C346595 at UMCVMB. -Bruce Barkelew ------------------------------ Date: 26 Feb 1986 13:18:30 EST Subject: Re: Lotus printer problem From: ABN.20E-27@USC-ISID.ARPA To: INFO-IBMPC@USC-ISIB.ARPA In regards to GARY SWALLOW's response to the problem of LOTUS and the inherent ability to talk to the WANG PM012 DIABLO type impact printer, I thank you! I did finaly get ahold of the LOTUS Tech rep and they were not the most reassuring of supporters. The end result of that phone call was that LOTUS prefers to talk at 300 baud not 1200, it needs 8 bits set on, no parity with one stop bit. This done they still didn't seem real positive of the results as the informed me that if that didn't work to delete the serial driver. All said and done it didn't have any new results in any form! BLEAH- My next idea is to think about changing the config.sys (shell=) to better talk to the system with LOTUS. I really would be greatful for further help on both getting the printer to work with LOTUS through switch changes and/or optimizing the config.sys file. THIS LOTUS vs PM012 (DIABLO) IS BEATING ME SEVERELY AROUND THE HEAD AND SHOULDERS. Reply: KURT A. NEUMAIER ABN.20E-27 FT BRAGG, NC ------------------------------ Date: Wed, 26 Feb 1986 23:51 MST From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA> To: INFO-CPM@AMSAA.ARPA, INFO-MICRO@BRL.ARPA Cc: INFO-IBMPC@USC-ISIB.ARPA, INFO-HZ100@RADC-TOPS20.ARPA Subject: More SIG/M and PC/BLUE volumes available SIG/M volumes 210 to 251 are now available in PD:<SIGM.VOLnnn>. PD:<SIGM.VOL000> and PD:<SIGM>SIGM.CRCLST have also been updated. PC/BLUE volumes 125 to 175 are now available in PD:<PC-BLUE.VOLnnn>. PD:<PC-BLUE.VOL000> and PD:<PC-BLUE>PC-BLUE.CRCLST have also been updated. All files were uploaded using MEX for the SIG/M disks and MEX-PC for the PC/BLUE disks. Check your CRC values against our list in the *.CRCLST files. For the PC/BLUE files, use CRCK4.COM. The CRCs of the files in the PC-BLUE directories should match our values regardless of whether you use MODEM or KERMIT protocols to download the files. The CRCs of the ASCII files may not necessarily match, but should be correct copies nonetheless. If any files appear trashed, be sure to check the file type in the CRCLST file to make sure you are not trying to display a binary file as if it were ASCII, especially on other TOPS-20, TENEX, or ITS mainframes. If the file is truly trashed, please let me know and I will get correct copies re-uploaded. --Frank ------------------------------ Date: 24 Feb 1986 15:49:11 PST Subject: QuicKey.asm From: Billy <BRACKENRIDGE@USC-ISIB.ARPA> To: info-ibmpc@USC-ISIB.ARPA The March 11 PC Magazine has published a program called program called quickey.asm this speeds up the typomatic on the PC keyboard. If anyone has downloaded the .ASM source files, would you please send it to us. I'd like it for the library. ------------------------------ Date: Mon, 24 Feb 86 10:41:38 PST From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA To: info-ibmpc@USC-ISIB.ARPA Subject: Microsoft MASM Assembler Wish List Wish List for Microsoft MASM Assembler ______________________________________ (1) Provide an option to allow for "worst-case" resolution of undefined forward references in pass 1, dealing with them the same way in pass 2. Although specifying this option would generate bigger code, it sure would speed programming, and avoid those annoying "PHASE ERRORS" in pass 2 (see page 95 of MASM 4.0 reference manual) (2) Provide an option which DISABLES STRONG TYPING for MEMORY OPERANDS. It seems that 30% of my code contains the PTR override operator. (see page 83 of MASM 4.0 reference manual) (3) Provide an option to shell CREF.EXE from MASM automatically. (see page 31 in MASM 4.0 user`s guide) (4) Allow KEYWORDS in MACRO calls, for example GET_TIME MACRO HOURS=A,MINUTES=B,SECONDS=C,HUNDREDTHS=D MOV AH,2Ch INT 21h .IFNB <A> MOV BYTE PTR A,CH .ENDC .IFNB <B> MOV BYTE PTR B,CL .ENDC .IFNB <C> MOV BYTE PTR C,DH .ENDC .IFNB <D> MOV BYTE PTR D,DL .ENDC GET_TIME ENDM (see page 121 and 108 in MASM 4.0 reference manual) (5) Allow definition of LOCAL symbols outside of MACROS. Ideally these local symbols would be "remembered" only within a given procedure. For example FOO PROC NEAR 10$: JCXZ 20$ LOOP 10$ 20$: FOO ENDP BAR PROC NEAR 10$: LOOP 10$ BAR ENDP would be legal, and not result in "Redefinition of Symbol" errors. ------------------------------ Date: Sun, 23 Feb 86 09:09:40 PST From: Lawrence_Anthony_Smith%UBC.MAILNET@MIT-MULTICS.ARPA Subject: Problem with 27 Lines on the EGA I am having difficulty in displaying 27 lines of character data instead of the normal 25 lines. I am using a PC/AT with the Enhanced Graphics Adaptor (EGA). I'm writing the program in Microsoft Assembler V3.0. Does anyone have any useful ideas about how to go about this task? Lawrence Anthony Smith%UBC.MAILNET@MIT-MULTICS.ARPA TRIUMF, U.B.C ------------------------------ Date: Sun 23 Feb 86 22:27-EST From: Ed Barton <EB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU> Subject: Cluster Size Query To: Info-IBMPC@USC-ISIB.ARPA I have a poorly documented generic PC-compatible with a 20meg hard disk. Unfortunately, disk space is allocated in 8K blocks leading to a great deal of wasted space. I would appreciate hearing from anyone who can explain what I can do to reduce the allocation size (and who doesn't mind explaining it). Please reply to EB%MIT-OZ@MIT-MC; thanks. ------------------------------ Date: 24 Feb 1986 04:57-PST Subject: Prolog Query From: BSCHAAR@USC-ISIF.ARPA To: info-ibmpc@USC-ISIB.ARPA A friend of mine needs a pointer to the developer's name, address, and phone number of Prolog. Also, any pointers to available sources for Prolog on the IBM PC/XT. Thanks. Brian Schaar ------------------------------ Date: Mon 24 Feb 86 11:50:06-EST From: Thomas.Finholt@C.CS.CMU.EDU Subject: TRS Model 100 to IBM XT Connection Wanted To: info-ibmpc@USC-ISIB.ARPA I am interested in software that allows me to use the XT hard disk as a remote disk for a TRS Model 100 portable computer. Thanks! ------------------------------ Date: Mon, 24 Feb 86 16:10:32 pst From: Ivan Reid <ivan%dac.triumf.cdn%ubc.csnet@CSNET-RELAY.ARPA> To: info-ibmpc@usc-isib.ARPA Subject: XT-clone motherboard query A friend recently acquired a Megaboard-type motherboard for an XT clone. The board is silk-screened with IC identification, but came without a circuit diagram. The only identification is 'MBE-XT'. Any help in tracking down the manufacturer or a circuit diagram would be greatly appreciated. Ivan Reid, TRIUMF, Vancouver, BC. ------------------------------ Date: Tue, 25 Feb 86 10:56:54 est From: John Pezaris <pz@mit-vax> To: info-ibmpc@usc-isib Subject: Color Attribute Query The recent discussions on setting colors have brought back an old query I was never able to resolve: is there any way to *read* (not write) the current attribute that dos will use in writing to the screen? Clearly, this information must be kept within dos, and is accessible through some venues, for ansi.sys and various other packages are able to modify it. However, I have not seen any hooks for retrieving the information. - John Pezaris (pz@mit-vax) ------------------------------ Date: Tue, 25 Feb 86 16:08:34 EST From: Andy Adler <andya@bbnccp.ARPA> Subject: Problem with MS-DOS command line length To: Info-IBMPC@usc-isib.arpa I am having problems with the MS-DOS limitation on command line length. The version of the MS C compiler that comes in the Windows Toolkit combines p0.exe and p1.exe into one new p1.exe. Thus the command line for the new p1.exe gets long since it receives switches for "two programs". If I want to keep my include files in more than one directory the multiple -I switches will overflow the command line. I can work around the problem by keeping all my includes in one directory with a relatively short path. However, this is not the REAL solution. Is there any way to lengthen the command line length limit? Has anyone come up with a better work around for this problem? Thanks, Andy Adler BBN Communcations. ------------------------------ Date: 25 Feb 86 11:27:56 PST (Tuesday) Subject: Intel 80186 Assembler Query From: Kadifa.osbunorth@Xerox.COM To: INFO-IBMPC@USC-ISIB.Arpa I need some pointers for an Intel 80186 compatible assembler, linker, locater written in C. This needs to understand Intel Macros and other assembly operations, and I am not looking for a Microsoft assembler. Abdo Kadifa Xerox US Mail: 2400 Geng Rd Palo Alto, CA 94303 ------------------------------ Date: Wed, 26 Feb 86 02:14:02 est From: tom allebrandi <edison!ta2%virginia.csnet@CSNET-RELAY.ARPA> To: info-ibmpc@usc-isib.ARPA Subject: Query: PCnet <--> 3Com Ethershare "Gateway" We are currently installing a 3Com EtherShare network between our AT's and our VAXCluster. We are also looking at a printer that only hangs off of PCnet (the new IBM pageprinter). Does anyone know if there is a good way to nail PCnet and EtherShare together? Current plan is that the VAX is our 3Com server - we won't have a PC based server in the EtherShare net. If we have to - we will put in a PC based 3Com server and run the pageprinter off of it. Tom #-} ta2@edison.uucp edison!ta2%virginia@csnet-relay.arpa (804) 978-5566 ------------------------------ Date: Wed, 26 Feb 86 10:52:41 est From: mjgold@mitre-bedford.ARPA To: INFO-IBMPC@USC-ISIB.ARPA Subject: Window Package for Xenix Wanted Does anybody out there possess any knowledge about a window package that will run on the IBM PC/AT under the XENIX operating system. I am aware of the packages that will run under DOS such as Microsoft's WINDOWS but I am unaware of any software windows packages for UNIX on the AT. Any Help would be greatly appreciated. ------------------------------ Date: Wed, 26 Feb 86 16:31 CST From: "Mark L. Ahlstrom" <Ahlstrom@HI-MULTICS.ARPA> Subject: dBASE File Format Query To: info-ibmpc@USC-ISIB.ARPA Can anyone point me to a reference that clearly describes the internal file formats used for dBASE II and dBASE III "dbf" files. I am interested in being able to have a program that writes files that can be read as dBASE database files. Thanks, Mark ------------------------------ End of Info-IBMPC Digest ************************ -------