Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!C.ISI.EDU!Info-IBMPC From: Info-IBMPC@C.ISI.EDU.UUCP Newsgroups: comp.sys.ibm.pc.digest Subject: Info-IBMPC Digest V6 #56 Message-ID: <8708190509.AA10923@ucbvax.Berkeley.EDU> Date: Tue, 18-Aug-87 18:59:30 EDT Article-I.D.: ucbvax.8708190509.AA10923 Posted: Tue Aug 18 18:59:30 1987 Date-Received: Fri, 21-Aug-87 04:54:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: INFO-IBMPC@C.ISI.EDU Distribution: world Organization: The ARPA Internet Lines: 1363 Approved: info-ibmpc@b.isi.edu Info-IBMPC Digest Tuesday, 18 August 1987 Volume 6 : Issue 57 This Week's Editor: Billy Brackenridge Today's Topics: MSC Large Model Problems Microsoft C 4.0 Large Models nroff troff (2 Msgs) SIMTEL20 Archive Server Extended Memory for Zenith 158 Cheap Modems Compuscan Warning Real vs Protected Mode (3 Msgs) OS/286 and OS/386 from A. I. Architects, Inc. Interrupts When Mode Switching (2 Msgs) IBM MASM 2.0 bug 12Mhz 0 Wait State Memory Expansion VP Planner is Cheap Lotus Clone Word List Drive Tables Deleting files QUICKLY (a solution) Finding Path Name of Executable Program Access Time for ROM/RAM on IBM-PC/xt BIOS.ASM update! MSDOS from TP Matlab not Mathlab CPU Speed Independent Time Delays and Waiting for Interrupts INT 3DH from Turbo Today's Queries: EGA Toolkit MS-DOS DISK RETRIES RATFOR for AT WP for Science and the Real World How Does PC-PAINT Get an Undocumented CGA Palette? TI PC+ Help Needed INFO-IBMPC BBS Phone Numbers: (213)827-2635 (213)827-2515 ---------------------------------------------------------------------- Date: Sat, 15 Aug 1987 00:32:03 EDT From: "James H. Coombs" Subject: MSC Large Model Problems I didn't see the original query about MSC 4.0 Large Model, but I believe that I can add some to the insights offered in Info-IBMPC V6 #56 by Darryl Okahata. First, if you had no problems with the code size under the small model, you can use the compact model instead of the large model. Your program will run somewhat faster under the compact model. (Compact model is "small code, large data.") The only disadvantage is that third-party libraries forget about the compact model, but it is easy enough to recompile them. Second, in ALL models, you must ensure that the compiler knows the size of the objects that are returned. This is similar to the problem that Darryl talks about with 0 and 0L. I had problems with strcpy(), for example, which returns a pointer to a char (char *). The program worked fine in the small model, but a char pointer in the compact model is 4 bytes instead of two. The problem was aggravated by the fact that I was using the returned pointer directly instead of assigning it to a pointer variable. (I can't recall the exact code.) Solutions? 1) Always include headers that declare functions with complete prototypes. Use the /DLINT_ARGS switch so that the compiler can check for "bad" assignments. 2) Avoid the "unstructured" compact method of coding, whereby the results of an operation are used directly instead of assigned to an "intermediate" variable. A is bad; B is better. A. char *s, string[80]; s = "Now is the time." strchr(strcpy(string,s),'.'); B. char *s, *t, string[80]; s = "Now is the time." t = strcpy(string,s); strchr(t,'.'); I hope that this example is not too artificial to convey the point. Also, it seems to me now that, with proper function prototyping, the compiler will not err with A; but I know that I have become more conservative because of these problems. So, now I can be more specific. If the return type of a function is not declared, the compiler assumes that it returns an int. An int in MSC 4.0 is two bytes. One gets away without function prototypes in the small model; but under compact and large models, char pointers are four bytes and the compiler needs to know that four bytes are being returned (really, it needs to know that it is a char *). Also, one gets away without function prototypes with style B because the compiler warns that one is trying to assign an int to a char pointer (well, at least the error is caught and one then provides the proper declaration). The moral of the story is that coding for the non-small models is not significantly more difficult, but debugging is if one does not provide the proper function declarations. It also helps considerably to use the function prototypes. --Jim ------------------------------ Date: Mon Aug 17 08:42:41 EDT 1987 From: Dave Sill To: Info-IBMPC Digest Subject: Microsoft C 4.0 Large Models >From: darrylo@hpsrlc.HP.COM (Darryl Okahata) > The BIGGEST problem (in my opinion) of transporting code from UN*X to >MSDOS is the usage of 0 (in UN*X) for NULL. This is NOT a UNIX convention, it is a part of the C language. See Kernighan and Ritchie pp. 97 and 192. > : > #include /* IMPORTANT!!!!! */ > > bomb(ptr) > char *ptr; > { > if (ptr != NULL) > *ptr = 'X'; > } > > foo() > { > bomb(0); /* this blows up in the large memory model */ > bomb(NULL); /* this works fine */ > } Of course passing 0 doesn't work. Bomb() expects an argument which is a character pointer, not an integer. The correct way to call bomb() is with the use of a cast: bomb((char *)0); or bomb((char *)NULL); > : > Why does NULL work instead of a "0"? Well, when is included > (this is included, isn't it?), NULL is either set to a "0" or "0L" ("0" for >small memory models, and "0L" for large ones), which takes care of the >problem quite nicely (and transportably, I might add). Transportably? No way! This topic has been beaten to death on info-c (comp.lang.c) recently. The only correct definition for NULL is 0. Period. Defining NULL as 0L is a poor attempt at fixing bad code, i.e. function calls with uncast constant parameters. A better way to do this is through the use of function prototypes as defined in the draft proposed ANSI standard for C. The best way, of course, would be to properly cast the parameters. -Dave Sill dsill@nswc-oas.arpa The opinions expressed above are those of the author and do not necessarily reflect those of the Department of Defense or the U.S. Navy. ------------------------------ Date: Sat, 15 Aug 87 01:16:34 EDT From: "James H. Coombs" Subject: nroff troff M&T Books markets *NR: An Implementation of the Unix NROFF Word Processor* by Allen Holub. Comes with source. $29.95. Originally discussed in Dr. Dobb's Journal of Software Tools in several spring issues of 1987. It's an enhanced nroff, with -ms and some support for proportional spacing. Call 800-533-4372. (In CA, call 800-356-2002). Haven't had a chance to look at it. I have heard loud complaints about bugs in Holub's shell (another product), but I can't say for sure that the complaints were justified. If you are a C hacker, you will probably want NR. If you want a polished, mature product, you may want to look elsewhere. --Jim [Thanks to several others who pointed out this package. -wab] ------------------------------ From: hsi!tankus@uunet.UU.NET (Ed Tankus) Subject: nroff troff Date: 17 Aug 87 11:38:50 GMT Organization: Health Systems Intl., New Haven, CT Here's something I picked off another group. Enjoy! Net : uunet!hsi!tankus Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511 Bell : (203) 562-2101 From: kg@elan.UUCP (Ken Greer) NROFF KIT for MS-DOS -------------------- Our NROFF for MS-DOS package includes: o The *new* NROFF, AT&T release 2.0, with user configurable printer tables. (They're in ASCII format now.) o TBL for formatting tables and charts. o NEQN for equations. o CHECKMM for "linting" documents. o COL utility for use with TBL. o MM and MAN macros (again, the latest version 2.0) o Complete (over 300 page) user manual and installation guide. The "summer special" price is $99. Our normal price is $295. The price is valid until Sept. 21, 1987. Shipping: U.S. ground - free!, U.S. 2nd Day Air - $10, Canada/Mexico - $30, Overseas - $50 (Sorry!) Terms: prepaid by U.S. check, Visa, Master card, or C.O.D. No P.O.s please. This is the *real thing*, folks. It ain't a rewrite (except for changes needed to run under MS-DOS.) All tools are derived from the new release 2.0 of AT&T's Documenter's Workbench. For purchasers who write their own new fancy Nroff tables for new printers and send them in, we also offer free upgrades to our Eroff Typesetting System (worth $795). Elan Computer Group, Inc. 410 Cambridge Avenue, Suite A Palo Alto, CA 94306 (415) 322-2450 ------------------------------ Date: Sat, 15 Aug 1987 11:42 MDT From: Keith Petersen Subject: SIMTEL20 Archive Server The SIMTEL20 netmail archive server is no longer available. SIMTEL20 is still accessible via standard anonymous FTP by Arpanet and Milnet users. The message below explains. --Keith Petersen Date: Friday, 26 June 1987 08:58-MDT From: Frank J. Wancho Several changes to the Archive Server have been made in the past few weeks to improve service for replies sent through intermediate hosts. One of the requested changes was to reduce the size of the messages by half so that these messages don't hog the single-stream mail channels, particularly on BITNET, for extended periods of time, and thus give other mail a chance to get through in a timely manner. Unfortunately, this has resulted in the SIMTEL20 mail queue to rapidly grow way beyond all expectations: the Server was now generating twice as many messages and our dedicated mailer for this service now had to establish twice as many connections for the same number of replies. That mailer could not keep up with the queue, and for the second time in as many weeks, we have had to shutdown the Server because we were running out of disk space. Because the disk space is at a premium for our regular users, and because the resources required by both the Server and the mailer have now reached a point well beyond the capabilities of our present system configuration, the Server has been shut down until further notice and for an indefinite period of time. New requests will be returned unanswered, and both present requests and replies will be flushed. In the meantime, we are examining other possibilities to provide access to our collections. Because the great majority of requests have come from BITNET users, we are looking for one or more BITNET hosts willing to provide the disk space and BITSERV facilities for one or more of our collections of public domain software. --Frank [I have run this message before, but it hasn't sunk in. BITNET people get your act together! If we are to share resources over various networks you have to lobby the political administrata types at your site for a files gateway as well as a mail gateway. This is a political problem not a technical problem. Similarly there hasn't been much $$$$ support from the BITNET side of the net for the continued support of info-ibmpc. We only have about $10,000 of the $50,000 figure we need in pledges for Columbia. None of this has come from the BITNET side of the fence. Again this is a BITNET political problem. One of the reasons we chose Columbia is that it is a major BITNET node and can provide services directly on BITNET as well as the internet. I will post messages, but you have to arrange this among yourselves. Judging from the quality of submissions to INFO-IBMPC, there seems to be a lot of talent out there. Lets get it coordinated so we can keep these services available to the world community. -wab] ------------------------------ Date: Sat, 15 Aug 87 13:59 EDT From: (Chris Gorman) Subject: Extended Memory for Zenith 158 In the last issue, the question was raised as to whether memory over 640K on the Zenith 151 or 158 can be used. Technical people at Zenith maintain that this memory is not accessible from the hardware level let alone from DOS. Above board memory (as opposed to on board memory) should be accessible for Ramdisks, etc. No one at Zenith seems to know WHY there are two rows for 256K ramchips on the 158 motherboard even though 128K sits idle if you fill them both. I haven't played with a 151, so there might be a different story there. Chris Gorman 201-377-3000 [x 205] BITNET: CGORMAN@DREW BBS: 201-377-8245 (IBM) 201-377-8193 201-377-7861 (300/1200/2400 baud) ------------------------------ Date: Friday, 14 August 1987 14:21-MDT From: ihnp4!inuxc!iuvax!iucs!bobmon@UCBVAX.BERKELEY.EDU Subject: Cheap Modems Compuscan Warning I recently posted a request for info about a company offering a modem for $122 (at least two other people posted similar queries). I've since seen the following bulletin, which I am passing along... Message #1951 To ALL 08-11-87 From STEVE LEON (SYSOP) Subject WARNING There is an ad appearing in BYTE, INFO WORLD, Compuserve's ONLINE and perhaps other places (it may be scheduled for PC WORLD). It is a full page ad by an outfit in Beverly Hills California called Compuscan. Prices are absurdly low - in fact - they are below wholesale. To make a long story short - the whole thing is a scam. We have the postal authorities on it. INFO WORLD will have a front page story next week on it. In the meantime, don't fall for it. If you already have - RUN to the bank and stop payment on the check. (Get to the bank in person and get it from them in writing that you told them.) If you already sent money and your check was cashed - next time remember the old -but true fact - that if sounds too good to be true - chances are it is not true. Please pass it on through the BBS networks. STEVE LEON ------------------------------ Date: 17-Aug-1987 0912 From: lichtenberg%colors.DEC@decwrl.dec.com (Mitch Lichtenberg) Subject: Real vs Protected Mode Richard, OS/2 MUST switch between real and protected mode in order to run one MS-DOS task. There is no VM/86 mode on the 286, or at least none that is documented and supported by Intel. The 386 was the first processor to include the VM/86 mode, and products like Softguard's VM/386 are able to make use of it. Perhaps OS/2 uses VM/86 mode on a 386. I doubt it, but it would seem logical that it might in the future. There is an undocumented instruction LOADALL on the 286 which loads the entire machine state from a fixed region of memory. This could be used to "fake" the chip into preserving the relationship between segments that you see in real mode, but in protected mode. Unfortunately, you'd have to take care of a protection trap every time you change a segment register, and that would be much too slow to be usable. Mitchell Lichtenberg Digital Equipment Corporation Personal Computing Systems Group 30 Porter Rd. Littleton, MA 01460 ------------------------------ Date: Mon, 17 Aug 87 10:27:35 PDT From: Richard Conner Subject: Real vs Protected Modes > OS/2 is a poor example of an operating system that switches between > modes; if well written, it needn't ever switch, but simply use the > VM/86 feature of both the 80286 and 80386 for MS-DOS emulation. Hmm... Half right. The 80386 has a VM/86 mode but the 80286 does not. If the 80286 had VM/86 mode you would be correct about not ever needing to switch, but alas even mythical OS/2 must switch on an 80286. > [... > I can't agree with you that OS/2 is poorly written. It is not so trivial > as you allege to be able to emulate a DOS environment in protected > mode on an AT. > ... -wab] (I think the "is not" should be captilized... (and underlined) :-) ) Richard Conner Locus Computing Corporation lcc.conner@LOCUS.UCLA.EDU Merge286/386 division lcc.conner@UCLA-CS {ihnp4,trwrb}!lcc!conner {randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!conner ------------------------------ Date: Tue, 18 Aug 1987 12:33 EDT From: SOLEY@XX.LCS.MIT.EDU Subject: Real vs Protected Modes My apologies for a badly mistaken point in my previous note re executing real DOS under 80286 protected mode; as anyone without his foot wedged neatly in his mouth knows, the 80286 does NOT have the VM/86 feature of the 80386. I find myself constantly using the '386, not the '286, and let this slip past me in my discussion of real vs. protected modes. I would not be surprised to find MicroSoft using the VM feature of the '386 for OS/whatever for the '386. -- Richard Soley [The editor also apologizes for letting this slip by with a comment rather than sending it back for a rewrite. Many messages on the subject have been exchanged opening up some interesting discussions which follow. It seems many programmers are attacking the mode switch problem and there are many approaches. I encourage more discussion of this subject. -wab] ------------------------------ Date: Tue, 18 Aug 1987 12:33 EDT From: SOLEY@XX.LCS.MIT.EDU Subject: OS/286 and OS/386 from A. I. Architects, Inc. Overview: OS/286 and OS/386 (trademarks of A. I. Architects, Inc.) are extensions to DOS 3.x which take full advantage of the 80286 and 80386 by letting normal DOS programs run in protected mode. They support quite high DOS compatibility; they do this by running on *top* of DOS, instead of *instead* of DOS, extending and preserving the well-known and documented interface. The result is a comfortable and familiar environment for development or for porting of existing code. In addition, developer's kits for OS/286 and OS/386 are equipped with special debugging facilities, and tools for easing conversion efforts. OS/286 runs on IBM-AT (100%) compatible machines, and offers the '286 16-bit protected mode in a DOS compatible fashion. OS/386 runs on Compaq 386 and Chips & Technology 386 Chipset machines or 100% compatibles, and additionally offers access to the '386 32-bit protected mode and 32-bit data manipulation. OS/386-HB runs on the A. I. Architects HummingBoard, an XT-and AT- compatible card offering a '386, optional '387, 12Kbyte cache, and up to 24 megabytes of parity-protected RAM. The HummingBoard runs in parallel with the host processor, allowing OS/386-HB to offer parallel execution of CPU and I/O operations. Details: Instead of taking the tack of inventing a new O/S interface or simply running multiple DOS tasks, OS/x86 (i.e., OS/286 and OS/386) add protected-mode capabilities to DOS itself. The result is an operating system which looks like DOS to the user, runs all the old DOS programs, provides a completely familiar environment for the developer, but offers the performance and flexibility that a large address space gives. Programs can be ported to OS/x86 by several paths: (1) Many existing C programs can be ported (without recompilation!) simply by relinking with OS/x86 libraries. Using this approach, up to 15MB can be accessed without changing the program, and leaving the entire 640K of "low" DOS memory free for network programs, TSRs, device drivers, and so forth. (2) Programs that currently use EMS or other bank-switching strategies can simply run in protected mode, directly accessing memory instead of performing mapping calls before each access. (3) Existing 8086 assembly language programs can generally be easily ported to 286 protected mode, supported under OS/386 as well. (4) Programs written in C, Pascal, or Fortran can be recompiled to run in 16-bit or 32-bit protected mode with compilers supplied by A. I. Architects. On the '286, these compilers take advantage of the '286 instructions; on the '386, these compilers will generate true 32-bit code and take advantage of the huge (32-bit) "small" memory model. (5) Programs that directly manipulate hardware resources (e.g., direct screen writing) can be partitioned so that most of the program runs in protected mode, while the hardware- and real-mode specific portion runs in real mode directly. Under OS/386-HB on the HummingBoard, this solution also offers parallel processing between the CPU-intensive portion of the program and the I/O intensive portion of a program. The system call convention in OS/x86 is just like DOS; values are placed in registers and a software interrupt (INT 21h) is issued. The registers passed are the same. There are differences caused by the underlying hardware (paragraphs versus segments and segment descriptors) but the interface is the same. All DOS operating system services - file system, input/output, information, memory management, processor management - are provided. Device drivers and terminate-and-stay-resident (TSR) interrupt handles written for DOS run under OS/x86. DOS and BIOS services provided: (*) Complete INT 21h support for DOS 3.x. (*) DOS call convention extended to 32-bit registers under OS/386. (*) Direct communication to real-mode installable device drivers. (*) All BIOS services (INT 10h - INT 17h) provided. Interrupt and other communication services: (*) Protected mode applications can issue interrupts to real-mode handlers. (*) Protected mode applications can be set up to *handle* real-mode interrupts. (*) Applications can intercept and handle any protected-mode trap or exception. (*) Protected mode applications can install and call "Real Procedures" running under DOS in real mode without invoking an interrupt; in addition, such real mode applications can signal back to the protected mode application. Memory management services: (*) DOS INT 21h memory management deals with segments rather than arbitrary memory blocks; however, units are still paragraphs. (*) Segment aliasing (data/code overlays) supported. (*) Segment windowing supported (segments within segments). (*) Mapping of segments onto any portion of physical memory supported. (*) Page mapping of regions of segments onto any portion of physical memory supported. (*) Optimized block memory moves (inter- or intra-segment) supported. (*) File mapping supported, permitting direct addressing of data structures within a file ("persistent segment") as in Multics or DEC-20's. Languages supported: (*) 16- and 32-bit High-C from Metaware. (*) Various 16-bit 8086 C compilers (including Microsoft C). (*) Professional Pascal from Metaware. (*) 386 Macro Assembler and Linker from Phar Lap. (*) Fortran 77 from Lahey. (*) All Common Lisp systems from Gold Hill Computers. The developer's kit includes the OS/x86 kernel and linker and a combined symbolic debugger/command processor. Options include the 16- or 32-bit compilers, the 32-bit assembler, and the 32-bit 386 HummingBoard for development. Some benchmarks have circulated lately on the 386 HummingBoard; here're some more to whet your appetites. Below are Dhrystone benchmarks: Machine Configuration Microsoft C High C & OS/386 IBM AT @6MHz 793 Compaq 386 @16MHz 2,380 5,837 HummingBoard @16MHz 2,777 6,718 HummingBoard @20MHz 3,571 8,470 and for comparison purposes: Vax 8600 (Unix 4.3 BSD, cc) 6,423 Sun 3/160 (Sun 4.2 3.0A, cc) 3,246 IBM 4381-2 (VM/SP 3.18, Waterloo 1.2) 5,681 DEC MicroVax (Ultrix 1.1, cc) 1,394 For further information on A. I. Architects or its products, as well as price lists, please contact A. I. Architects, Inc. 1 Kendall Sq, Suite 2200 Cambridge, MA 02139 (617) 577 - 8052 -- Richard Soley, CEO A. I. Architects, Inc. ------------------------------ Date: 18 Aug 1987 12:08:17 PDT Subject: Interrupts When Mode Switching From: Billy To: SOLEY@XX.LCS.MIT.EDU I am concerned about how interrupts are handled in OS/2 and other DOS extensions and operating systems which run in mixed modes. This is very important for those of us where Ethernet/IP/TCP communications is our reason for existence. It looks to me that under OS/2 interrupts get lost. IBM, 3Comm and Microsoft have been pretty cavalier about losing interrupts in the past. Many is the IBM seminar I have gone to and expressed my concerns as a real-time programmer over BIOS's ability to disappear for 30 seconds or so on a disk retry or VDISK's ability to lose interrupts entirely. We have a comm package in the library, COM_PKG2.ASM. Many commercial and public domain terminal emulators etc. are based on this package. It works under OS/2 as long as the DOS emulation window is running, but switch to protected mode and no more interrupts. How do you guys handle this problem? What is the right way to do this? ------------------------------ Date: Tue, 18 Aug 1987 16:48 EDT From: SOLEY@XX.LCS.MIT.EDU Subject: Interrupts When Mode Switching We have heard that other protected-mode solutions have this problem, but we'll leave the aspersion-casting to others and hand you our solution. OS/x86 *does not lose interrupts*. Plain and simple. OS/386-HB, for the HummingBoard, of course does not have this problem at all. It never switches modes; the host processor runs the real-mode DOS, and the HummingBoard's '386 processor handles the protected-mode program. Since plain old DOS is running on the host (motherboard) processor, and the host processor never needs to switch modes, there's no problem. On the other hand, in both OS/286 and OS/386, we need to be careful on transitions into and out of protected mode. The solution is to disable interrupts and NMI's before the switch, and enable interrupts after the switch, *without resetting interrupts*. Several protected-mode applications we've seen, including the AT BIOS, reset interrupts after the mode switch (and reinstatement of the interrupt vector, IDT) because they wish to remap several interrupts. The need for remapping is caused by the collision of Intel and IBM in the "reserved interrupts;" IBM used several interrupts which were Intel reserved, which Intel later used for hardware faults (bounds check, general protection fault). By remapping interrupts, all pending interrupts are lost. In contrast, we do not remap the overlapping interrupts; instead, our handler decides at run time whether the interrupt was an "Intel" or "IBM" interrupt. We use the fact that the hardware exceptions ("Intel" interrupts) push error codes after the flags, while the software interrupts ("IBM" interrupts) do not. It appears that several other protected-mode programs on the market copied the BIOS' style of clearing pending interrupts, with the disastrous result you mentioned. Our solution avoids this problem. -- Richard Soley, CEO A. I. Architects, Inc. 617/577-8052 ------------------------------ Subject: IBM MASM 2.0 bug Date: Mon, 17 Aug 87 09:18:24 EDT From: Joe Morris (jcmorris@mitre.arpa) I ran into a gotcha in the IBM version of MASM (IBM's version 2.0) recently: it seems that INCLUDE statements have the nasty habit of truncating the filespec of the file to be included to 30 characters without bothering to warn the user. A statement of the form: include level1\level2\level3\level4\abcdef.h ; ^--this is col. 30 would (hopefully) result in a diagnostic about MASM's inability to find a file named 'ab' in the specified directory. If such a file does exist, it might be interesting to debug the assembly since MASM doesn't tell you that it's doing something other than what you told it you wanted. IBM's response was "yes, you're right, but that's Microsoft's responsibility and not IBM's." Another reason not to buy the IBM-logo version of a Microsoft product. ------------------------------ From: hsi!tankus@uunet.UU.NET (Ed Tankus) Newsgroups: comp.sys.ibm.pc.digest Subject: 12Mhz 0 Wait State Memory Expansion Organization: Health Systems Intl., New Haven, CT There are a couple of boards you can try. I believe one of the BOCA RAM boards has the 12MHz/0 wait states you need. If not, try one of the Elephant Memory boards from American Micronics (?). You can purchases either, and get some additional info on these types of boards, from Microway, Inc., Kingston, MA. These boards are NOT cheap so remember that when ordering from Microway or anyone else. Try Cheetah, Int'l. I believe they also have a board that will run at 12MHz. Call 1-800-CHEETAH. Cheers! -- Ed. Net : uunet!hsi!tankus Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511 Bell : (203) 562-2101 ------------------------------ Date: Mon, 17 Aug 87 08:05:44 EDT From: hsi!tankus@uunet.UU.NET (Ed Tankus) Subject: VP Planner is Cheap Lotus Clone David, I have heard good things about VP-Planner and SILK. Both are under $300. SILK can import and use the Lotus macros, but can't export them (directly) back. I don't know how compatible VP-Planner is. Cheers! -- Ed. Net : uunet!hsi!tankus Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511 Bell : (203) 562-2101 [Thanks also to: Robert_Slade%SFU.Mailnet%UBC.MAILNET@MIT-Multics.ARPA -wab] ------------------------------ Date: 1987 Aug 16 13:53 EDT From: Bob Babcock Subject: Word List >>Does anyone have a program which will make a list of all the >>words in an ASCII file? I'd like to find one. It does not have >>to generate the numbers of times which the word was used. Dick Pountain has articles in the July and August '87 Byte with a program for generating such a list and removing "boring" words for the purpose of generating an index. (I haven't tried it.) ------------------------------ Date: Sun, 16 Aug 1987 22:40 EDT From: Villy G Madsen Subject: Drive Tables The following program may be used to change the drive tables so that a quad density drive (either 3.5 or 5.25") may be used as the B drive. This program also changes the skew factor of any disks formatted after it is run to have a sector skew of 2. Some systems might run slower with this skew, if so simply change it back to 6. The prior version of this program I had posted (which only formatted 12 cylinders) had an error . PAGE ,132 CSEG SEGMENT PARA PUBLIC 'CODE' ASSUME CS:CSEG,DS:CSEG SetDT PROC JMP StartOfCode A_DeviceParameters: SpecialFunctions: db 04h ; this is the new default BPB ; all sectors are the same size DeviceType: db 00h ; 320/360kb 5.25" floppy DeviceAttributes: dw 00h ; no change line support ; media is removable NumberOfCylinders: dw 80 MediaType: db 02h ; media type is dd ds 5.25" DeviceBpB: BytesPerSector dw 512 SectorsPerCluster db 2 ReservedSectors dw 1 NumberOfFats db 2 RootEntries dw 112 TotalSectors dw 80*9*2 MediaDescriptor db 0FDH SectorsPerFat dw 3 SectorsPerTrack dw 9 Heads dw 2 HiddenSectors dd 0 Reserved_1 dd ? Reserved_2 db 6 dup(0) TrackLayout: SectorCount: dw 9h SectorNumber: dw 1h ;number of the first sector SectorSize: dw 200h ; and its size etc: dw 6h ; number of the 2nd sector dw 200h dw 2h ; and the third etc dw 200h dw 7h dw 200h dw 3h dw 200h dw 8h dw 200h dw 4h dw 200h dw 9h dw 200h dw 5h dw 200h StartOfCode: MOV AH,44H ; IOCTL MOV AL,0DH ;Subfunction Generic request MOV BL,2 ; For drive B MOV CH,08H ; Major code (Category) MOV CL,40H ; Set Device Parameters PUSH CS ;DS has to point to Code S POP DS MOV DX,Offset A_DeviceParameters INT 21H mov ah,4ch ; Terminate nicely int 21h SetDT ENDP CSEG ENDS END ------------------------------ Date: Mon, 17 Aug 87 12:22:15 EDT From: marks@tekigm2.TEK.COM (Mark D. Salzman) Subject: Deleting files QUICKLY (a solution) Organization: Tektronix, Inc., Beaverton, OR. After many replies to my request, here is the one working solution that was given on how to delete a large number of files QUICKLY from within a program. That solution is to use the old DOS delete function 13H with wildcards to specify the files you wish to delete. As usual it has it's tradeoffs. This function does not understand path specifications at all. So it can only delete files in the current directory. It also gets it's speed by using wild cards since it only has to open the directory file once to do the deletions. Much thanks goes to Ralf Brown (Ralf.Brown@b.gp.cs.cmu.edu) who showed me that the DOS "del" command uses this function (along with some code to change directories if a path is given) to do it's work. Although many of you suggested going around DOS and mucking with the directory file and File Allocation Table (FAT) directly, I have not yet received enough information to do that safely. If anyone has such information, I would still love to hear it. Below is a program I wrote to test this function and determine how to use it. Enjoy! Mark D. Salzman Phone (206) 253-5542. | The more complex the mind, Tektronix Inc., P.O. Box 3500, M/S C1-937 | the greater the need for Vancouver, Washington. 98668 | the simplicity of play. {world_at_large}!tektronix!tekigm2!marks | James T. Kirk /* * DELETE.C * * This program implements the PC/MS-DOS delete function 13h. This is the * fastest function for deleting large numbers of files as long as the files * can be specified with wildcards ( *, ? ). As it stands, the program can * only delete files on the current drive and in the current directory, no * path names allowed. It will not delete files with special attributes like * read only or system. This program is donated to the public domain. * * Compile with Microsoft C V4.0 : cl delete.c -o delete * * By Mark Salzman, Tektronix Inc. */ #include #include struct FCB /* The DOS File Control Block */ { char exflag; /* Extension active flag byte, FF = active */ char space1[5]; /* Reserved space, normally set to zero */ char attribute; /* File attribute byte */ char drivenum; /* The drive number, also base address of FCB */ char filenam[8]; /* File or device name, left justified space filled */ char fileext[3]; /* File extension */ int block; /* Current block number */ int record; /* Record size */ long size; /* File size in bytes */ int date; /* File date */ char space2[10]; /* Reserved space for DOS control work */ char crecord; /* Current record (<127) */ long rrecord; /* Random record number */ } main (argc, argv) /* Set up to pass command line arguments */ int argc; char *argv[]; { int inc; if (argc < 2) usage(); /* If no arguments, print usage. */ for(inc=1; inc root_seg root_seg:0 -> DB "Environment String 1",0 DB "Environment String 2",0 . . DB "Most Recent String n",0 DB 0 ; Double null terminates environment DW Length_of_Fully_Qualified_Path_Name_String DB "Fully_Qualified_Path_Name_String",0 Thus, offset 2Ch in the PSP points to a series of null terminated ASCII strings, with a double null terminator. Immediately following this double null is the fully qualified path name of the executing program, including device, directory, filename, and extension. [Thanks also to Mary Conner 8221984%UWAVM.bitnet@wiscvm.wisc.edu -wab] ------------------------------ Date: Sun, 16 Aug 87 10:36:22 PDT From: Ya'akov_Miles%UBC.MAILNET@MIT-Multics.ARPA Subject: Access Time for ROM/RAM on IBM-PC/xt IBM supplies RAM with an access time of 200 nanoseconds, and ROM with an access time of 250 nanoseconds. We have found that RAM with an access time of 250 nanoseconds, and ROM with an access time of 300 nanoseconds will work in the standard 4.77 mHz PC. As for turbos 8 mHz will work with RAM at 150 nanoseconds and ROM at 200 nanoseconds 10 mHz will work with RAM at 120 nanoseconds and ROM at 150 nanoseconds Some 10 mHz turbo units insert wait states when accessing ROM so that you can fall asleep while Generic bios busy-waits, imprisoned in 200 ns ROM... ------------------------------ Date: Sun, 16 Aug 87 19:46:02 PDT From: Ya'akov_Miles%UBC.MAILNET@MIT-Multics.ARPA Subject: BIOS.ASM update! I have mailed a copy of the latest version of Generic BIOS, featuring: o Much improved documentation, esp. data structures o Non-Slow CRT video teletype support (INT 10h, AH=14.) I sent a BITNET copy of this BIOS to "JOHN@NCSUVM.bitnet", and you can get a copy of it from him, or from many Canadian public bbs systems... [Somebody want to send it to us? -wab] ------------------------------ Date: Mon, 17 Aug 87 14:59:13 EDT From: Subject: MSDOS from TP > with reggie do begin > ax := $3D12; > ds := seg(dastr); > dx := ofs(dastr); <---- The problem lies there: Turbo Pascal stores strings in the format length (1 byte) followed by the string. The ofs(dastr) returns the address of the length byte. That line should really read dx := ofs(dastr)+1; If you like, or anyone else for that matter, I have a small library of TP functions which do this sort of thing. Drop me a note and I'll send you a copy. (Open, close, opensharing, create, createunique, createtemp, read, write, etc.) -Richard Ward Williams College, Williamstown, Mass, USA rbw@cs.williams.edu ------------------------------ Subject: Matlab not Mathlab Date: Mon, 17 Aug 87 14:01:53 PDT From: Daniel Abramovitch The original message that I sent was: My suggestion is PC-Matlab, from the Mathworks. ^^^^^^ Somehow, it was edited to My suggestion is PC-Mathlab, from the Mathworks. ^^^^^^^ in the entire message. I am now getting flamed by everyone who owns a copy. Addendum: the net address for the company is na.mathworks@score.stanford.edu. -- Danny [The spelling corrector bit me. I can't spell and neither can most of the info-ibmpc contributors. A spelling corrector is essential, but one still must watch the beasts. I am much pressed for time now as I had expected to be rid of the digest this month and made several errors in the last digest. -wab] ------------------------------ Date: Tue, 18 Aug 87 09:26:55 PDT From: Roland McGrath Subject: CPU Speed Independent Time Delays and Waiting for Interrupts I have two questions for you folks out there: 1) Is there a good (and reasonably simple) way to delay (sleep) for a given period of time independent of the clock rate? My C library provides a sleep() function but it will sleep for a minimum of one second, which is too long. 2) Is there a good way of pausing until an interrupt happens? The problem with a simple endless do-nothing loop is that it needs to end when an interrupt is caught, and making all the interrupt handlers set some flag that is checked constantly seems to me a bad way to do it. Perhaps some kind soul with an IBM PC Technical Reference handy could look in the BIOS listing and see how it's done when a Ctrl-NumLock (Pause) is hit. Thanks, Roland McGrath ------------------------------ Date: 18 Aug 1987 12:38:16 PDT Subject: CPU Speed Independent Time Delays and Waiting for Interrupts From: Billy To: Roland McGrath Following is some timer support stuff from a large multi tasking real time system. It won't assemble but will give you an idea how to do timer support. In Pascal one calls clock_reset and then loops until clock equals some integer value in deciseconds. This loop can check for some external event such as keyboard (or as in the case of this system some event on a number of external signal processors). In any case the number of things you might want to check for in a timer loop is up to you. btod equ 1ah ; bios time-of-day call tick_len equ 55 ; milliseconds per bios timer tick ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;MS-Pascal callable routines;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; procedure clock_reset; ; reset clock origin clock_reset proc far prolog bpsav call getbrd ;Find control block for this board jnc cbok ;BX will point to this block jmp badbye ;If error exit cbok: mov ah,0 ; read clock BIOS preserves BX here int btod ; BIOS time-of-day routine mov [bx].c0_hi,cx ; high portion of clock mov [bx].c0_lo,dx ; low portion of clock cgdbye: xor cx,cx cbye: epilog 0,bpsav ; done, no args badbye: mov cx,-1 jmp cbye clock_reset endp ; function clock : integer; ; return time in deciseconds since reset_clock was called clock proc far prolog bpsav call getbrd ;Find control block for this board jnc clok ;BX will point to this block jmp badbye ;If error exit clok: mov ah,0 ; read clock BIOS preserves BX here int btod ; BIOS time-of-day routine sub dx,[bx].c0_lo ; subtract old clock sbb cx,[bx].c0_hi ; result is 55 msec tick count mov ax,dx ; prepare for mul/div mov dx,cx ; ax=lo, dx=hi mul dw_tick_len ; convert ticks div dw_mpd ; to 100 msec ticks mov cx,ax jmp cbye ;Return time in AX via CX clock endp ------------------------------ Date: Tue, 18 Aug 1987 10:55 PST From: MARY CONNER <8221984%UWAVM.BITNET@wiscvm.wisc.edu> Subject: INT 3DH from Turbo >I set up the DOS registers and call 3DH, and then I call 59H to >determine if there was an error. And I always get back error ID #8, >insufficient memory. The proper way to determine an error status with function 3Dh is to check the carry bit, and if the carry bit is set, *then* call 59h to check the extended error code. The carry bit is bit 0 (the least significant) of the flags register. Therefore you can use the following bit of code. if odd(reggie.flags) then {call 59h code goes here}; Hope this helps. Mary Conner 8221984@UWAVM.bitnet ------------------------------ Date: 17 Aug 1987 11:08-EDT Subject: EGA Toolkit From: MHARRIS@G.BBN.COM I've been told about a graphics package called the EGA Toolkit. Does anyone know wherefrom/howmuch? Thanks. -- Michael Harris MHarris@G.BBN.COM 617-497-3794 ------------------------------ Date: 17 Aug 87 09:47:01 PDT (Monday) Subject: MS-DOS DISK RETRIES From: "George_C._Burkitt.ElSegundo"@Xerox.COM In testing hard disk drives, I need to disable the normal DOS procedures for correcting bad reads from hard disk files to determine the actual read error performance of the drive hardware. I plan to use MS-DOS 3.1. Can any of you experts show me the way to do this? As an alternate, I could live with merely counting the retry attempts, but this is a distant second. The host is an AMPRO 186, which is designed to be PC/MS-DOS compatible, but it uses an ASCII (RS-232) monitor. [I wrote a real time speech application where I time the disk accesses. If any disk accesses take longer than normal, I write an error message to the log file. This isn't a portable solution but it works for long term maintenance of a system designed to run unattended for years. -wab] ------------------------------ Date: Mon, 17 Aug 87 15:06 EDT From: Zaret@MIT-Multics.ARPA Subject: RATFOR for AT I am trying to help someone else obtain a RATFOR pre-processor for an AT, and I would appreciate any leads. Thanks. ------------------------------ From: msmith@topaz.rutgers.edu (Mark Robert Smith) Subject: WP for Science and the Real World Date: 17 Aug 87 20:05:59 GMT Organization: Lipton, INC., Englewood Cliffs, NJ Can anyone recommend a word processor for both scientific work and normal, everyday letters and the like? We'd like to implement a group of Scientific workstations on IBM compatibles here and we want a set of software compatible with each other and many other people. I suppose, then, that the software should be able to interface with Lotus 1-2-3 and dBase III. Thanks. Smitty Mark Smith (alias Smitty) "Be careful when looking into the distance, 61 Tenafly Road that you do not miss what is right under your nose." Tenafly, NJ 07670 msmith@topaz.rutgers.edu, msmith@remus.rutgers.edu (Good luck getting there!) ------------------------------ Date: Mon, 17 Aug 87 20:22 EDT From: sidney%acorn@oak.lcs.mit.edu Subject: How Does PC-PAINT Get an Undocumented CGA Palette? PC-PAINT, the paintbrush program that is available with the Mouse Systems mouse, somehow gets the CGA to use one more palette than the two that are documented in the IBM literature that I've seen. I've called Mouse Systems (or whatever company owns them now) and was told by a tech support person that the software was bought from a third party who will not tell them how it was done. The third palette provides the colors green/magenta/brown (or their high intensity versions). Does anyone out there know how to get a CGA to display those colors? Thanks, Sidney Markowitz ------------------------------ Date: Tue, 18 Aug 87 16:15:02 EDT From: Brady@UDEL.EDU Subject: TI PC+ Help Needed A friend of mine is developing a not-real-big expert system (200 rules + some lisp functions) using TI's PC-plus. The system runs ok within the PC+ development environment. But the run-time module (created by using TI's "build" facility) causes the machine to freeze up, after running a while. (The freeze-up is not always at the same point; this seems to depend on what data has been entered and the path traveled by the program.) The program is running on a 640K Compaq. Anyone out there have any ideas what could be causing the freeze? Thanks in advance. joe brady ------------------------------ End of Info-IBMPC Digest ************************ -------