Info-IBMPC@C.ISI.EDU (Info-IBMPC Digest) (08/15/87)
Info-IBMPC Digest Friday, 14 August 1987 Volume 6 : Issue 56
This Week's Editor: Billy Brackenridge
Today's Topics:
Microsoft C 4.0 Large Models
AT Model 339 Speedup
Updated XMODEM YMODEM ZMODEM Protocol Documentation
GOSSIP is Government OSI Profile
Signal Processing Routines Mathlab from Mathworks
Mathematical Scratchpad for Functions Available from SIMTEL20
VT100 and Tek401x Emulation based on CMU PC/IP Pac
PKARC Squashed ARCs Defined
Turbo C Patches
Real vs Protected Modes
Autocad .DXF File from Fortran and Turbo-Pascal
New Version of Freemacs
DECnet-DOS problems (V6 #55)
Re INFO-IBMPC Digest 30 Efficient Block Transfers
PC Packages used in Europe
Computers in Europe
Foreign Information
Today's Queries:
DOS 3.3 bug
Fontasy Fonts Wanted
An accelerator
Unix programs for IBMPC's - nroff/troff
TSR/Palette-Setting Interrupt Conflict
dBase III Data File Editor Needed
VT220 Wang 2110 Emulator
Z-151 & Z158 Memory Beyond 640K
Timing problems..
Herc Compat board
INT 3DH from Turbo
How do you determine P.C. clock speed?
Program Name in Turbo Pascal
Calendaring/Scheduling Software
12 MHz Enhanced Expanded Memory (EEMS) Available?
Yet Another Turbo C Bug
Cross Reference
Quick Directory Erase
Epson Equity I
Lotus 123 Clones
INFO-IBMPC BBS Phone Numbers: (213)827-2635 (213)827-2515
----------------------------------------------------------------------
Date: Wed 5 Aug 87 07:04:41-PDT
From: darrylo@hpsrlc.HP.COM (Darryl Okahata)
Subject: Microsoft C 4.0 Large Models
Organization: Network Measurements Div - Santa Rosa, CA
In comp.sys.ibm.pc, nwc@cucca.columbia.edu (Nicholas W. Christopher) writes:
> I wrote a language and interpreter using Lex, YACC and curses on a vax
> and am now attempting to get it to run under MSC 4.0 . The language
> is window oriented and the PC-curses windows require 4K+. My code
> bottoms out in 5 or 6 windows (I malloc space for other things as well) in
> the small model.
>
> I tried compiling under a large model and the code ran for a while and then
> froze. My question is, what are the things to worry about in large models?
> Are there special considerations when passing arguments by address? Will
> short integers behave? Where should I be looking (codeview just hangs so its
> no help) ?
>
> Thanks,
> /nwc
>
> P.S. I am really sick of seeing "Unknown Compiler Error, Contact Microsoft
> Technical Support", I hope 5.0 does not loose as much as 4.0.
>
> ----------
The BIGGEST problem (in my opinion) of transporting code from UN*X to
MSDOS is the usage of 0 (in UN*X) for NULL. In the small memory model,
this is no problem, as the size of a pointer is the same size as an
integer. However, in the large memory model, the size of a pointer (4
bytes) is TWICE the size of an integer (2 bytes). This becomes a problem
when you try to pass a NULL pointer to a function. Let's say that you have
a program fragment like:
#include <stdio.h> /* 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 */
}
Assuming the large memory model, when foo() calls bomb(0), two bytes (an
integer) of zeros are pushed onto the stack. When bomb() checks the value
of ptr, it is looking for a four-byte object (a pointer to char); the
pointer offset will be zero (this is what was pushed onto the stack), but
the pointer segment will be whatever is there on the stack and will, in all
probability, be nonzero. The conditional expression in the if statement in
bomb() will, as a result, be true (because the pointer segment is probably
nonzero), and some random location in memory will be trampled. The result?
Crash, boom, bang!
Why does NULL work instead of a "0"? Well, when <stdio.h> 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).
-- Darryl Okahata
{hplabs!hpcea!, hpfcla!} hpsrla!darrylo
CompuServe: 75206,3074
Disclaimer: the above is the author's personal opinion and is not the
opinion or policy of his employer or of the little green men that
have been following him all day.
------------------------------
Date: Wed, 5 Aug 87 18:13:52 EDT
From: Photios_Ioannou@um.cc.umich.edu
Subject: AT Model 339 Speedup
The IBM AT Model 339 crystal-cripple revisited. Some time ago I requested
information about eliminating the ROM trap that IBM has planted in
the newer AT's and which does not allow them to run faster than 8.5MHz
(by simply changing the crystal). I have implemented the following solution
which fortunately works:
(a) Download the contents of the ROM chip U27 in a file
(b) Change the following two bytes in that file:
Location Old Byte New Byte
======== ======== ========
CF F4 90
2DE 73 EB
(c) Program a new EPROM with the modified ROM file.
.
The first patch makes a HLT (halt) instruction into a NOP (no operation)
so that the POST (power on self-test) does not hang if it finds
a checksum error in the ROM modules!
.
The second patch makes a conditional jump (JAE) into a forced jump (JMP)
so that the machine always passes the speed test no matter how fast it runs.
.
This solution may not be too elegant (disabling the checksum test
is not such a good idea) but it requires changing only one of the two
ROM chips. Note: The addresses given are measured from 000 and not from
100 as debug does. If you use debug to change these bytes then increment the
given addresses by 100. Also, downloading the ROM contents using debug
or a similar utility will download both U27 and U47 (i.e. both ROM chips).
The addresses given refer to the contents of U27 alone, so if one
looks at the contents of the ROM chips as plugged into the machine (again
using DEBUG) the addresses will be double the ones given (the offset,
of course, is F000) i.e. at locations F000:019E you will find F4 and
at location F000:05B.C. you will find 73. I hope this helps.
------------------------------
Date: Thu, 6 Aug 1987 00:58 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Updated XMODEM YMODEM ZMODEM Protocol Documentation
Chuck Forsberg's latest documentation files for XMODEM/YMODEM/ZMODEM
protocols are now available from SIMTEL20...
Filename Type Bytes CRC
Directory PD:<MISC.PROTOCOLS>
YMODEM5.DOC.1 ASCII 65477 858EH (includes XMODEM)
ZMODEM5.DOC.1 ASCII 103675 9AAFH
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
------------------------------
To: "ASD.ADI" <capehart@wpafb-info2.arpa>
Subject: GOSSIP is Government OSI Profile
Date: Thu, 06 Aug 87 08:47:53 -0400
Jack - GOSIP is the "Government OSI Profile". It is an attempt by
Federal Government to specify and implement computer protocols based
on the ISO 7 layer model. The Asst. Sec. of Defense for C3I (Donald
Latham) published a memo dated 2 July which tasks various DoD entities
for handling conversion-related issues.
Bottom line is that it is DoD's intent to move away from the DoD protocols
(TCP/IP) and towards OSI. Limited operational capability is targeted
for January, 1989.
Jeff Edelheit (edelheit@gateway.mitre.org)
The MITRE Corporation 7525 Colshire Drive
McLean, VA 22102 (703) 883-7586
=-=- This note is in response to yours which follows -=-=
I have been asked to find out about a program or protocol called
GOSSIP (spelling ??) and so far have been unsuccessful in my search.
Anyone out there heard any "GOSSIP"?
Thank You
Jack Capehart
[There are other mailing lists devoted this subject. If I had known what
GOSIP was I would have referred this message to those other lists. -wab]
------------------------------
To: Anthony_Whipple@um.cc.umich.edu, INFO-IBMPC@C.ISI.EDU
Subject: Signal Processing Routines Mathlab from Mathworks
Date: Thu, 06 Aug 87 09:20:28 PDT
From: Daniel Abramovitch <danny@cappuccino.STANFORD.EDU>
My suggestion is PC-Mathlab, from the Mathworks. All of the stuff that you
mentioned is included in the basic package. The filtering and
differentiating is readily done with the filter routine. There are also
routines to produce and plot Bode plots, Nichols plots, etc.
What is Mathlab, you ask?
Mathlab was the original matrix manipulation package written by Cleve
Moler at the University of New Mexico based on the LINPACK and EISPACK
projects. The original Mathlab was public domain, and several companies
have made control and signal processing packages based upon this
original FORTRAN code, most notably CTRL-C (Systems Control Technology)
and MATRIX-X (Integrated Systems Incorporated). These packages were
originally coded to run on VAX class machines, and the basic underlying
code has not changed. (Coded meaning: slow and expensive!)
PC-Mathlab is a second generation package written by Cleve Moler and John
Little (the latter having worked on CTRL-C). It is completely rewritten
in C, and optimized for the PC. There is also an integrated set of
graphics routines and the existing code is extensible by user written
code. There are now 2 ways to extend Mathlab on the PC. The first of
these is by using "m-files" (programs written in the Mathlab language).
These can be "compiled" by Mathlab at the beginning of a run to speed
execution. The second way is to link in C or FORTRAN subroutines. The
advantage of the second method is that it allows you to use existing
routines that may run much more quickly than m-files. Currently
Microsoft C and FORTRAN are supported as well as (yeah!) Turbo-C. There
are also Postscript drivers available for making the nice plots on your
screen look like nice plots on paper.
Mathlab has also been ported to several other machines:
VAX/VMS and Sun Workstation; and ports are on the way to VAX/UNIX,
Apollo, and Mac II (probably also for a Mac with the speed up board).
University price is about 1/2 the standard price, and group orders of 10
or more are 1/2 the university price. The end result is that my PC copy
cost me $256 about a year ago and I am about to get an upgrade to
Version 3.1.
Their address is:
The MathWorks, Inc.
Suite 250
20 North Main St.
Sherborn, MA 01770
617-653-1415
Disclaimer: I am not connected with the MathWorks in any way. We do
have so many people using and extending the product,
though, that our lab has become a beta test for their
products. I personally have been extremely satisfied with
the product.
Daniel Abramovitch
Information Systems Lab
Stanford University
(415) 723-3024
------------------------------
Date: Tuesday, 11 August 1987 10:26-MDT
From: Bruce Buzbee <BUZ@KL.SRI.COM>
Subject: Mathematical Scratchpad for Functions Available from SIMTEL20
I uploaded a new Shareware program for the SIMTEL20 MSDOS archives.
It was written by a friend of mine who doesn't have access to ARPANET
and he asked me if I could post it for him. There are 2 archive
files:
SPIA.ARC contains the program, documentation, etc.
SPIADEMO.ARC contains a self running demo of SPIA.
Filename Type Bytes CRC
Directory PD:<MSDOS.MATH>
SPIA.ARC.1 BINARY 190832 D245H
SPIADEMO.ARC.1 BINARY 145448 B885H
DESCRIPTION
-----------
SPIA is a mathematical scratchpad for functions. SPIA provides an
interactive environment in which to study functions (like sin, cos,
etc.) and signal processing techniques (like Fourier transform,
convolution, etc.). The results of these functions are displayed
graphically on the user's screen.
SPIA is essentially an interpretive programming language, in which
the variables are functions (vectors) and the operators are the basic
mathematical operations with a few special ones thrown in. By taking
the supplied functions and operators (and a little ingenuity) one can
custom build an enormous array of functions upon which to experiment.
The commands which invoke these functions and operations are entered
in the command window at the bottom of the screen.
Some of the functions provided:
Fourier transform (forward and inverse), convolution, cross
correlation, derivatives, integrals, square root, smoothing,
sin, cos, exponential, delta, heavyside, lorentzian, pseudo random
noise, gaussian, notch, rectangle, sign, sinc, triangle, ramp,
absolute value, amplitude, complex conjugate, logs...
------------------------------
Date: 2 Aug 87 22:44:08 GMT
From: Markku Savela <mcvax!enea!tut!santra!clinet!msa@seismo.css.gov>
Organization: City Lines Oy, Helsinki, Finland
Subject: VT100 and Tek401x Emulation based on CMU PC/IP Pac
Knobi der Rechnerschrat writes:
>2.) If the answer to 1.) is no, ist there a PD VT-100 telnet program
> available which is based on the CMU PC/IP package (I'm neither
> willing to pay for a commercial package, nor do I like to have
> communication programs without sources.
>Martin Knoblauch
A month or two ago I was in the same situation, looking for a good
VT100 emulation in the TCP/IP world. I already had that CMU PC-IP package
and I wasn't very satisfied with the H-19 Telnet.
I also had my own VT100 emulation that was using INT14 interface
(and relied on the RS232 driver to do the XON/XOFF handshake -- my machine
is NOKIA ASC, quite close to IBM PC/AT).
I took the CMU PC-IP TN-program, stripped it down to bare bones and
interfaced it with INT14-interrupt service. When started, it just hooks
to INT14, opens the TELNET connection and spawns the MS-DOS command
interpreter. Then I just start my own terminal emulator.
My version is just a hack to test the idea, but it worked. I'm just
wondering, why hasn't this been done earlier? Is it, that INT14-interface
is not usually used in terminal emulators? Just to give you a better idea
about what is going on, I include my INT14-catcher (any comments Drew D.
Perkins?).
Markku Savela Tel.Int. +358 0 45571
Nokia Information Systems Telex 124486
P.O.BOX 780 SF-00101 HELSINKI Telefax +358 0 455 7373
FINLAND
[I14TRAP.ASM has been added to the Info-IBMPC Lending library. -wab]
------------------------------
Date: Fri, 7 Aug 1987 13:20 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: PKARC Squashed ARCs Defined
Here is Phil Katz's SQSQINFO.DOC which defines the format of squashed
ARC file members.
--cut-here--SQSHINFO.DOC--cut-here--
The purpose of this document is to detail the format of "squashed"
files created by PKARC version 2.0 or later. This document assumes
some basic knowledge of existing ARC formats and various compression
techniques. For more information consult the references listed at the
end of this document.
The general format for an ARC file is:
[[archive-mark + header_version + file header + file data]...] +
archive-mark + end-of-arc-mark
The archive-mark is 1 byte and is the value 1A hex. The file header
can be defined by the following 'C' structure, and is 27 bytes in size.
typedef struct archive_file_header
{ char name[13]; /* file name */
unsigned long size; /* size of compressed file */
unsigned short date; /* file date */
unsigned short time; /* file time */
unsigned short crc; /* cyclic redundancy check */
unsigned long length; /* true file length */
};
The name field is the null terminated file name.
The size is the number of bytes in the file data area following the
header.
The date and time are stored in the same packed format as a DOS
directory entry.
The CRC is a 16-bit CRC on the file data area based on a CRC polynomial
from the article by David Schwaderer in the April 1985 issue of PC
Technical Journal.
The length is the actual uncompressed size of the file.
The header versions are defined as follows:
Value Method Notes
----- -------- -----------------------------------------------------
0 - This is used to indicate the end of the archive.
1 Stored (obsolete) (note 1)
2 Stored The file is stored (no compression)
3 Packed The file is packed with non-repeat packing.
4 Squeezed The file is squeezed with standard Huffman squeezing.
5 crunched The file was compressed with 12-bit static Ziv-Lempel-
Welch compression without non-repeat packing.
6 crunched The file was compressed with 12-bit static Ziv-Lempel-
Welch compression with non-repeat packing.
7 crunched (internal to SEA) same as above but with different
hashing formula.
8 Crunched The file was compressed with Dynamic Ziv-Lempel-Welch
compression with non-repeat packing. The initial
ZLW code size is 9-bits with a maximum code size
of 12-bits (note 2). An adaptive reset is used
on the ZLW table when it becomes full.
9 Squashed The file was compressed with Dynamic Ziv-Lempel-Welch
compression without non-repeat packing. The initial
ZLW code size is 9-bits with a maximum code size
of 13-bits (note 3). An adaptive reset is used
on the ZLW table when it becomes full.
Note 1:
For type 1 stored files, the file header is only 23 bytes in size,
with the length field not present. In this case, the file length
is the same as the size field since the file is stored without
compression.
Note 2:
The first byte of the data area following the header is used to
indicate the maximum code size, however only a value of 12 (decimal)
is currently used or accepted by existing ARC programs.
Note 3:
The algorithm used is identical to type 8 crunched files with the
exception that the maximum code size is 13 bits - i.e. an 8K entry
ZLW table. However, unlike type 8 files, the first byte following
the file header is actual data, no maximum code size is stored.
References
----------
Source code for ARC 5.0 by Tom Henderson of Software Enhancement Associates,
usually found in a file called ARC50SRC.ARC.
Source code for general Ziv-Lempel-Welch routines by Kent Williams, found
in a file LZX.ARC. Kent Williams work is also referenced in the SEA
documentation.
Source code and documentation from the Unix COMPRESS utilities, where most
of the ZLW algorithms used by SEA originated, found in a file called
COMPRESS.ARC.
Ziv, J. and Lempel, A. Compression of individual sequences via
variable-rate coding. IEEE Trans. Inform. Theory IT-24, 5 (Sept. 1978),
530-536.
The IBM DOS Technical Reference Manual, number 6024125.
- Phil Katz, 12/27/86
------------------------------
Date: Sat, 8 Aug 87 16:44:59 EDT
From: Dave Goldblatt <bh0u@clutx.clarkson.edu>
Subject: Turbo C Patches
Regarding the set of patches on clutx.clarkson.edu:
When you go about ftp'ing these files, make SURE you have binary mode set.
The archive extracts fine here, tests ok here, etc. If you still can't get
a good copy, I have a uuencoded file I can mail you if all else fails.
The patches are in /pub/TurboC/tcpatch.arc on clutx.clarkson.edu, available
with anonymous FTP.
-dg-
------------------------------
Date: Mon, 10 Aug 1987 11:10 EDT
From: SOLEY@XX.LCS.MIT.EDU
Subject: Real vs Protected Modes
[Yes DOS runs in "real" mode vs "protected" or "native" mode. I wish
there were some sense to these names. OS/2 switches between real and
protected modes. This is non trivial! -wab]
Actually, the names make quite a bit of sense from the point of view
of memory addressing. In "real", or 8086-emulation mode, the 80286
(or 80386) accesses memory without protection: 16*segment+offset is
the REAL address of the memory location specified. In "protected"
mode, these chips use a Multics-style segmentation scheme to calculate
memory address, and furthermore PROTECT the user from (1) access to
invalid locations, (2) writing a code segment, (3) executing a data
segment, etc. The name "native" refers to the actual instruction set
and addressing scheme of the chip, as opposed to the way the chip acts
when emulating an 8086.
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.
Operating system EXTENDERS, which actually run on top of DOS, do need
to switch to support complete DOS/driver/TSR compatibility; an example
of this would be OS/386 and OS/286 from A. I. Architects, or DOS
Extender from Phar Lap.
Richard Mark Soley, CEO
A. I. Architects, Inc.
Soley@MC.LCS.MIT.EDU
617/577-8052
[I guess I am dating myself remembering the days when PDP-11s had memory
PROTECTION but ran in REAL memory as opposed to VIRTUAL memory. All these
words had meanings 15 years ago. Now they have new meanings.
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. How about some more technical description of your
products OS/386 and OS/286. -wab]
------------------------------
Date: Wed, 12 Aug 87 10:40:45 SST
From: Dieter Menne <ZOOMENNE%NUSVM.BITNET@wiscvm.wisc.edu>
Subject: Autocad .DXF File from Fortran and Turbo-Pascal
I include a Pascal and a Fortran procedure to produce graphics in
AUTOCAD data exchange format. Only 'movea' and 'drawa' (TCS- style)
are supported, feel free to add other gadgets, but I never needed more.
To make drawings for publications, I produce a '.DXF'-file of the data
in a 1x1 square without axis and lettering; then I insert the stretched
and compressed BLOCKS with data into the nicely decorated coordinate system.
Dieter Menne
Department of Zoology
National University of Singapore
Singapore 0511
Bitnet ZOOMENNE@NUSVM
[AUTOGRAF.PAS has been added to the info-ibmpc lending library. -wab]
------------------------------
Date: Wed, 12 Aug 87 13:43:08 EDT
From: Russell Nelson <bh01@clutx.clarkson.edu>
Subject: New Version of Freemacs
Freemacs is a freely copyable programmable text editor, or else it's a full
screen programming language, I'm not sure which. Freemacs is much like
Gnu Emacs, and runs on the IBM-PC and Zenith Z-100. It's written in assembly
language, so it's fast :-) and non-portable :-(. However, it's probably
a simple task to port it to other MS-DOS PC-incompatibles.
Freemacs is always available from clutx.clarkson.edu via anonymous FTP in
subdirectory pub/emacs14c.arc. However, because we are in the hinderlands
of the Internet, you might have better luck getting a copy from Simtel20,
PD:<Msdos.text-editors>emacs???.arc.
Actually, Freemacs is fairly interesting from a computer science point
of view. MINT, the language that Freemacs uses, lets you do content-
addressable memory, argument passing by [address, value, name], arguments
may or may not be evaluated, recursion (there is no iteration operator,
"just" recursion), and a few other things.
------------------------------
Date: 12-Aug-1987 2043
From: mitton%nac.DEC@decwrl.dec.com (Dave Mitton)
Subject: DECnet-DOS problems (V6 #55)
RE: From: MURRAY@wharton-10.arpa
> We've just gotten DECnet-DOS V1.1 here ...
That's too bad. V1.2 has been shipping since April.
>- IBM AT, 640K, DOS 3.1, Micom Ethernet card, color monitor with EGA card,
>connected to Ethernet through a DELNI. Installation of DECnet-DOS seems to
>go ok, but the system hangs when we run the DLL (Data Link Layer) process
>(although it does print some very pretty colored boxes all over the screen
>first)
I've never seen this simple configuration fail, so there must be something
you've left out. Is the Micom board configured correctly? Does Micom's
own diagnostics run on it?
Did you install the correct DLL? (Hint: DLLMICOM.EXE on the distribution)
>- HP Vectra (IBM AT clone), 640K, IBM DOS 3.1 (DECnet complained about HP
>DOS 3.1), 3Com Ethernet card, color monitor with EGA card, connected to
>HP's version of a DEMPR, which is connected to a DELNI, which is connected
>to the Ethernet. This one hangs at various random spots during the reboot
>after the DECnet-DOS installation ...
If you read the SPD, DECnet-DOS is only supported on IBM PC systems.
The HP Vectra is an example of why. As reported previously in this Digest,
the HP BIOS uses interrupt vectors in the 6x hex region for video support.
DECnet-DOS tries to use them too. Guess what happens?
But luckly, HP has nicely written a software workaround for the problem.
Phone up their Customer Support and ask for it. (I always have to look
up the old Info-IBMPC-Digest with their announcement in it.)
Dave Mitton, DECnet-DOS Software Engineering.
(this mail composed on a VAXmate)
------------------------------
Date: Fri, 14 Aug 87 03:43:02 PDT
From: Ya'akov_Miles%UBC.MAILNET@MIT-Multics.ARPA
Subject: Re INFO-IBMPC Digest 30 Efficient Block Transfers
Title Loop
;Demonstrate Block Transfer technique, sometimes called Transfer Vectoring
COUNT =12345 ; Number of bytes to read
BLOCK_SIZE =9 ; Bytes per data transfer block
PORT =241h ; Clock. BCD seconds/100. (341h ?)
;
BLOCK_SIZE =BLOCK_SIZE and 0FFFEh ; Force even # of bytes/xfer block
;
Code Segment ; Declare Segment before "Assume"
Assume ds:Code,ss:Code,cs:Code,es:Code ; Segment order avoids "problems"...
ORG 0100h ; Start address for .COM binary file
begin: mov di,offset DATA ; ES:[DI] --> data area
mov cx,COUNT ; Get total bytes to transfer
mov bx,BLOCK_SIZE ; Get data transfer block size, BYTES
mov ax,cx ; Get lo order transfer byte count
xor dx,dx ; ...zero hi order byte count
div bx ; AX = blocks, DX = remainder
push ax ; ...save block count
mov cx,dx ; Get bytes in partial block
mov dx,PORT ; ...load clock port
jcxz exact ; Exact number of blocks in transfer
;
fract: in al,dx ; Read BCD seconds/hundred.
stosb ; ...ES:[DI] --> (next) saved result
loop fract ; ...until done
;
exact: pop cx ; Load number of blocks to transfer
jcxz done ; ...less than one block in xfer
;
block: Rept BLOCK_SIZE/2 ; Unroll DO loop this amount, bytes
in al,dx ; Read BCD seconds/hundred
xchg ah,al ; ...save temporary in register
in al,dx ; Read BCD seconds/hundred
xchg ah,al ; ...swap bytes to IBM order. Yuk
stosw ; ...ES:[DI] --> (next) saved result
Endm ; ...end of unrolled DO loop
loop block ; ...love FORTRAN
;
done: ret ; Back to BASIC programming
data: ; ...data area after program
Code ends
;
End Begin
------------------------------
Date: 6 Aug 87 10:31:23 PDT (Thursday)
Subject: PC Packages used in Europe
From: "David_C._LaBerge.osbunorth"@Xerox.COM
I need some information to help prepare for a workshop in London. I'm
trying to find out what the popular PC packages that are running in
Europe are.
1)Spreadsheets
2) Databases
3) Word Processors (by country)
4)Communication Software and hosts
(What packages and what are they dialing into)
5)Miscellaneous (utilities, graphics, CAD etc.)
Please respond to LaBerge.OSBU_NORTH@Xerox.com
------------------------------
Date: Thu, 6 Aug 87 13:17 EDT
From: <PQW@PSUVM.BITNET>
Subject: Computers in Europe
My experience is with computer work in the Federal Republic of Germany
("West"). The people there that I know are all working with IBM PC compatibles.
No one I know shells out the money for Big Blue. Toshiba laptops with
20 Mg drives, AT compatible, with 1 Mg Ram chips are the most common.
Runs DBASE III and II like a charm.
The Siemens PC is kind of a drag on the market. People weren't too enthused
about it, and there were BIOS problems in some of the software. the
DBASE stuff seemed to run OK on it, but compilers had a bit of a problem
(like Clipper).
Keep in mind that if you are going to take a machine there "A few precepts":
The converters do in fact convert the current nicely. However, you can't
plug your video screen into this directly and get away with it. What you need
to do is plug your monitor into the power source in the back of your machine
(which does output the appropriate hertz for your monitor to scan) and you'll
be fine. I knew someone at the Pentagon who had a converter which converted
the hertz as well as the voltz, but since the above is a cheap solution
(about 8 bucks for a plug which is compatible with the back of your
IBM PC, why bother?).
You will have to fill out a shippers export declaration statement if
you are taking your PC out of the country. This makes it easy for you
to bring your PC back into the country if and when you come back. In
addition to this, have your appointment papers handy if applicable, so that
the people there can verify that you need the PC in your work. (Have your
employer put this in writing somehow). Just doing these simple things
makes life clear sailing. I had no problems at all.
Phil Wood
Human Development
Pennsylvania State University
PQW@PSUVM
------------------------------
Date: Sat, 8 Aug 87 13:23 EDT
From: <PQW%PSUVM.BITNET@wiscvm.wisc.edu>
Subject: Foreign Information
If the user going to Europe is thinking of developing bookkeeping
information for that market, he/she should be aware that the
terminology and style of keeping books for a small business
(at least in Germany, Austria, and Switzerland) involves keeping
track of transactions in a much different way than we are used to.
Really research this before trying to market a PC product for
this audience.
W.r.t word processing, there was a product in Germany called
Text-Ace which was getting good reviews for being compatible
with the intricacies of doing foreign characters within a word
processing environment. Microsoft Word was doing a good job of
changing the program over to accommodate a particular language.
In addition, at least in Berlin, the IBM stores were also marketing
a keyboard with a few of the keys changed on the keyboard, but
with the same basic keyboard layout. Be sure to familiarize yourself
with such things before merrily programming and assigning functions to
keys assuming that putting them a certain place will make the program
more "user friendly." You may be making it user hostile instead...
------------------------------
Date: Thu, 6 Aug 1987 13:43 EST
From: Rich Stillman <26-324@HARVBUS1>
Subject: DOS 3.3 bug
I ran across this bug as soon as I put DOS 3.3 up on my system. I have an IBM
AT 319 with a 2M Rampage EGA from AST, 128K of which is used to fill low
memory to 640K. The system also has 512K of IBM extended memory, set up as a
ramdisk. When I ran Lotus 1-2-3 with large spreadsheets that had worked for
me before, I started getting the message "Formula computation error" and
instructions on how to call Lotus customer support. This happened even with
simple spreadsheets, like a multiplication table I built as a test, if the
spreadsheet was large. Continuing to work on the spreadsheet after that was a
recipe for disaster. I once had to power off to stop 1-2-3 from writing to my
hard disk for a couple of minutes of straight disk I/O. Fortunately, no harm
was done.
The only thing different about my setup was DOS 3.3. I rebooted the system
from floppy with DOS 3.2 and my hard disk CONFIG.SYS and ran Lotus. Everything
worked fine. I rebooted DOS 3.3 with the EEMS driver removed from CONFIG.SYS.
Once again, everything was fine. The only combination that causes the problem
seems to be DOS 3.3 and the EEMS memory, implemented through REMM.SYS.
Has anyone else seen this problem? I have not tried to reproduce it with other
brands of EEMS, or EMS. I have been running DESQview 2.0 for the last two
weeks with no trouble at all, using the EEMS heavily. In fact, if I tell
DESQview not to let Lotus use any expanded memory, it will work under 3.3.
This must be the equivalent of removing the driver from CONFIG.
Is there any comment from Lotus or IBM? If this is a general problem, it seems
that disaster looms on the horizon for users of large Lotus spreadsheets.
Rich Stillman
Bitnet: 26-324 at HARVBUS1
Arpa/Edunet: 26-324%harvbus1 at wiscvm.wisc.edu
------------------------------
Date: Thu, 6 Aug 87 14:09 EDT
From: <ERIC@UOFT02.BITNET>
Subject: Fontasy Fonts Wanted
Hello, I am sending this request to see if anyone knows of any "Public Domain"
FONTASY fonts. I am looking for any that you might know of, on another
system, on a BBS (I will need the number), etc.
Thank you,
Alan
cscon102@uoft02 (BITnet)
------------------------------
Date: Thu, 06 Aug 87 14:37:09 EST
From: John <JOHN%NCSUVM.bitnet@wiscvm.wisc.edu>
Subject: An accelerator
Hello,
I'd like to tap some experience if I may. I'm thinking of buying
an accelerator for my XT and am curious as to what problem I may
encounter. i.e: what functions of DOS will be affected due to the
decreased amount of time spent in "timing" loops and the like?
If anyone has one or knows anything about them, the board is
a PC-Bandit, and ALL it does is increase my clock rate...
Thanks,
John
Any comments on other boards are welcome. You may want to reply
directly to me so we can keep the volume of mail down... :-)
------------------------------
Date: Thu, 6 Aug 87 13:46:38 pdt
From: wcwells%opal.Berkeley.EDU@jade.berkeley.edu (William C. Wells)
Subject: Unix programs for IBMPC's - nroff/troff
Does anyone know of a nroff/troff clone that will run under MSDOS?
Bill Wells
wcwells@ucbvax.berkeley.edu
------------------------------
Date: 6 Aug 87 22:00:29 GMT
From: carsontr@utcsri.UUCP (Carson T. Schutze)
Subject: TSR/Palette-Setting Interrupt Conflict
Organization: CSRI, University of Toronto
Hi. I need some help with memory-resident utilities and interrupts.
I have four TSR programs I want to have loaded all the time. One of them,
an EGA palette setting program, allows me to specify which interrupt I want
it to use [that's all I know about it, BTW; no source or detailed doc].
Its default interrupt, 09, does not work properly -- palette settings only
take effect when I hit the Ctrl key, and they do not survive screen mode
resets.
Fortunately, the only other 'recommended' interrupt for this program,
1C(Timer) works perfectly -- color settings are immediate, and survive
any program which tries to change them. Unfortunately, when this mode
is loaded, and I then try talking to another machine via modem on my
serial port, characters sent from the remote host are randomly lost
(at least one every line, which is too much!).
Using the recently-posted interrupt listings, I tried other interrupts
for the palette program (paletcon.com), but with no success. Either
they don't work at all, or they get messed up by my other TSR's. HELP!
How can I get this set-up to work? My work-around has been to use
TSR-utility's MARK.COM and RELEASE.COM to remove the palette program
when running Qmodem, and put it back after. Not very satisfying, though.
My Hardware: IBM PC-AT, ATI EGAWONDER card (could be different from genuine
IBM card)
My Software, and its interrupts, listed as 'hooked vectors' by MAPMEM.COM:
NEWFONT: 10, 7E
WAITASEC: 09, 10, EF, FD, FF
DOSEDIT: 21
PALETCON: whatever I want, default 09
Any hints would really be appreciated.
Carson T. Schutze Dynamic Graphics Project
Computer Systems Research Institute
(416) 978-6619 University of Toronto
Toronto, Ontario, Canada
M5S 1A4
carsontr@toronto.CSNET
carsontr@csri.toronto.edu
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!carsontr
------------------------------
Date: 6 Aug 87 12:55:44 EDT (Thu)
From: zeeff%b-tech.UUCP@umix.cc.umich.edu (Jon Zeeff)
Subject: dBase III Data File Editor Needed
Organization: Branch Technology Ann Arbor, MI
I'm looking for a dBase III data file editor. Something like the browse
command, but with things like insert record and search functions. Has
anyone heard of one?
Jon Zeeff Branch Technology,
uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
------------------------------
Date: Thursday, 6 August 1987 08:12-MDT
From: sundc!hqda-ai!cos!howard@SEISMO.CSS.GOV (Howard C. Berkowitz)
Subject: VT220 Wang 2110 Emulator
Source code is needed for a simple VT220 (or, ideally, Wang 2110)
emulation package which can be/is already modified to support 32
function keys. This emulator will run under MS-DOS, and ideally would
be written in BASIC or C.
Most available VT200 emulators only support 10 function keys.
We need to extend the package to support additional function
keys through shifts, etc., and have this keyboard-to-code mapping
available to the terminal user (for redefinition).
howard(Howard C. Berkowitz) @cos.com
{seismo!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [ofc] (703) 998-5017 [home]
DISCLAIMER: I explicitly identify COS official positions.
------------------------------
Date: 08/07/87 08:27:25 EST
From: MARIA%SERVAX.BITNET@wiscvm.wisc.edu (MARIA=DRAKE)
Subject: Z-151 & Z158 Memory Beyond 640K
Several of our Zenith Z-151 and Z-158 systems have 768K memory.
Do you know of anyway that we may use the memory beyond 640K?
We would like to use that memory for a print spooler or a
RAM disk, but we don't know how to access it.
Thanks
Maria Drake
Florida International University
BITNET: MARIA@SERVAX or
MARIA%SERVAX.BITNET@WISCVM.WISCVM.WISC.EDU
------------------------------
Date: Sat, 08 Aug 87 22:19:45 EST
From: John <JOHN%NCSUVM.BITNET@wiscvm.wisc.edu>
Subject: Timing problems..
Hello,
A question related to my last posting that I'd like to ask is:
If I put an accelerator in my PC that does nothing but increase
the clock rate, will I have problems reading and writing to
floppies and my hard disks? If so, does anyone know approximately
where I should look to change these values in the ROM? ( Thanks to
the people who gave suggestions on how to reburn the ROM on my
HD controller so my second HD would work.. Simple once you know
what your doing. :-) ). If I can figure out all the places that
need changing, and what to change the values to, I'd consider
reburning the ROM.. I'm assuming that there wouldn't be any other
timing problems..
Also, does anyone know what clock rates correspond to what access
times for memory chips, and are there any other chips (ROM?) that would need to be replaced do to the increased clock rate?
Well... Thanks for listening.. and any pointers anyone may have..
If responses are posted directly to me, I'll summarize them and post
them in case anyone else is curious....
John W. DeBoskey
John@ncsuvm.bitnet
"I don't play moria... IT plays ME!"
------------------------------
Date: Mon, 10 Aug 87 00:16 CDT
From: <KRANTZ%VUCTRVAX.BITNET@wiscvm.wisc.edu>
Subject: Herc Compat board
I recently purchased a herc compat board. The only documentation that
came with it stated the 'formulae' for address a pixel on the screen
and the address of the ports on the card. I've seen the sample pascal
code recently submitted for putting the board text or graphic mode.
What I would like is some routines or pointer to documentation for
writing routines to plot 'characters' and to do other sort of graphics
(draw line, polygon fill and so fourth). I realize that there are
basic routines for doing the lines and polygon using a set pixel routine,
but I was hoping for routines which were optimized for the herc board.
ALso, with respect to plotting characters, the idea is to display text of
variable size (such as in a tektronix emulator) on the screen so these
routines would have to be very efficient.
The only access I have to the net is via bitnet, so if there is pd software
which can be ftp, could you include a US mail address for sending a floppy
to get such software.
Thank you,
Alan Krantz
Ps, please CC all replies to me since we sometime miss issues of INFO-IBM.
Also, this is a plain monochrome herc compatible board - no ram font
or color....
[The library is full of examples of such programs and is accessible from
bitnet. -wab]
------------------------------
Subject: INT 3DH from Turbo
Date: Mon, 10 Aug 87 09:15:52 -0800
From: davef@portia.Stanford.EDU
I'm writing an application that is going to run on a 3com network.
The program logs information about each workstation in a central log
file. As such, I need to open the file in a mode that denies write
access to subsequent opens. So I'm trying to open the file with the
DOS function 3DH. If the open is successful, I write my information;
if not, I delay for a while and try again.
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.
Here is the code that I'm using:
type regpack = record
ax,bx,cx,dx,bp,si,di,ds,es,flags : integer;
end;
asciiz = array[1..namelen] of char;
procedure openfile (var hand : integer);
var reggie, reggie2 : regpack;
dastr : asciiz;
closed,count : integer;
begin
for count := 1 to fnamelen do dastr[count] := logfile[count];
(* note: logfile contains the name of the central logfile *)
dastr[namelen] := chr(00); (* null byte at end of asciiz string *)
repeat
with reggie do begin
ax := $3D12;
ds := seg(dastr);
dx := ofs(dastr);
end;
msdos(reggie);
hand := reggie.ax; (* handle to file, if there's no error *)
with reggie2 do begin
ax := $5900;
bx := $0000;
end;
msdos(reggie2);
closed := reggie.ax; (* closed -> no error; code = 0 *)
if not (closed = 0) then wait;
until closed = 0;
end;
I'm fairly new to IBM PC programming, so it's possible that I'm doing
something horribly wrong. If I am, could someone please show me the
error of my ways? Does anyone out there have any idea why I
consistently get an error id of 8? (Above, closed = 8.) Does anyone
have any sample code that accomplishes what I'm trying to do? Since
I might be completely wrong about my error checking as well as/instead
of my open function, could I get samples of the correct error checking
procedure as well?
Thanks very much for any help you can give me; I've already exhausted
the pool of local knowledge in search of an answer.
Replies to davef@portia.stanford.edu.
David Finkelstein
AIR Systems Development
Stanford University
davef@portia.stanford.edu
(415) 723 1055
[DOS allocates all available memory to a task in order to be
compatible with DOS 1.0. Subsequent calls to DOS memory allocation
routines always result in "insufficient memory" unless you de allocate
some memory. In assembly language programming this is quite simple. I
don't know how Turbo Pascal handles this problem as there is probably
some conflict between Turbo Pascal dynamic memory allocation and DOS. -wab]
------------------------------
From: psivax!polyslo!abell@seismo.CSS.GOV (Alan Bell)
Subject: How do you determine P.C. clock speed?
Date: 10 Aug 87 18:25:52 GMT
Organization: Cal Poly State Univ,CSC Dept,San Luis Obispo,CA 93407
Is there a way, under program control, to determine the clock speed of an
IBM P.C. or compatible? The only method which I could come up with would
be to make a system call to get the system time, execute a loop a fixed
number of times (say a million), then call for the system time again.
Then, knowing how long it takes on another P.C. and its processor speed,
you can figure the approximate speed of the machine being tested.
The problem with this approach, is that I want to run this program at the
start of an application, and of course it will take time to run it. What
I am looking for is a method which is instantaneous, or better yet, the
source code. Thanks in advance for your help. If there is enough interest,
I shall post the result.
Alan Bell
Cal Poly State University
San Luis Obispo, CA 93407
...ihnp4!csun!polyslo!abell
[A not very good solution would be to use an environment variable and ask
the user to set the speed of the CPU. -wab]
------------------------------
Date: Tue, 11 Aug 87 15:10:56 MEZ
From: Erich Neuwirth <A4422DAB%AWIUNI11.BITNET@wiscvm.wisc.edu>
Subject: Program Name in Turbo Pascal
I have a question:
Is there an easy way for a program written in Turbo Pascal to find
out under what name it has been invoked. The command line parameters
only contain everything after the program name. I think my UNIX friends
told me in UNIX normally the first accessible parameter is the programs
name itself. In MS-DOS the PSP does not contain the programs name.
Erich Neuwirth
------------------------------
Date: 11 Aug 87 12:53:00 EDT
From: "DAVID_CHAPMAN" <zn0chapman@nardacva.arpa>
Subject: Calendaring/Scheduling Software
Does anyone out there know of any good(!) local area network packages that
do calendaring and scheduling?
We already have an electronic mail program we are more than happy with, so
a program like Higgins would be a bit of an overkill. What I would like to
do is have a LAN-wide personal scheduling system that would allow for
organization-wide coordination of meetings.
It'd be nice if it was TSR type of program, too! Also, the ability to
handle departmental file servers would be a plus. Not asking for much, eh?
The target LAN would be a Novell's Advanced Netware/286 based IBM Token
Ring (with later additions to a bridged 3Com).
If I get sufficient responses, I will summarize and post.
David Chapman
NARDAC Norfolk
(804) 444-1190
"I'm not asking for the world; Mars will suffice."
------------------------------
Date: Tue, 11 Aug 87 18:08 PDT
From: <DBELL%SCU.BITNET@wiscvm.wisc.edu>
Subject: 12 MHz Enhanced Expanded Memory (EEMS) Available?
Is there an add-in card for PC ATs that will run Enhanced Expanded Memory
(EEMS) on a 12 Mhz AT clone (no wait states)? I called AST today about
the speed on their AST RAMpage EEMS card. Their customer support says
that this card runs at 8 MHz with one wait state. They say that the bus
on the AT will slow down to the 8 MHz rate for all memory calls.
Is that the last word? Thanks in advance to you speed demons out there.
------------------------------
Date: Wed, 12 Aug 87 17:46 CDT
From: <COLEMANM%UMKCVAX1.BITNET@wiscvm.wisc.edu> (Michael Coleman)
Subject: Yet Another Turbo C Bug
I've been following the discussions about Turbo C bugs and was
wondering if anyone else has had this problem. When using the
interactive environment and trying to do a MAKE with a project file,
compilation is aborted because .C files cannot be opened, even though
the files are where they are supposed to be (all of the directories
are set correctly and CONFIG.SYS is ok). So I tried loading the
offending file into the editor (which was no problem), and compiling
that way. Apparently the compiler came down with an extreme case of
cognitive dissonance, because it bombed completely out (i.e., "Please
contact Borland, exit error = 555, winerror = 0"). Any ideas anyone?
Mike Coleman
COLEMANM@UMKCVAX1
P.S. Has anyone considered writing PC-specific graphics libraries?
------------------------------
Date: Thu, 13 Aug 87 9:55:28 MDT
From: John Shaver Modernization Office <steep-mo-m@HUACHUCA-EM.ARPA>
Subject: Cross Reference
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.
Thanks
John
[Try C or Pascal Tools by Kernighan & Plauger a cross reference program
is one of the program exercises for the student. -wab]
------------------------------
Date: Thu, 13 Aug 1987 13:59 CDT
From: Fred Seaton <MUCM000%ECNCDC.BITNET@wiscvm.wisc.edu>
Subject: Quick Directory Erase
We have an application that creates a subdirectory and then adds about 1000+
files (each containing about 1000 bytes) until the application has finished.
At the start of the next day, this directory must be erased, removed, and
re-created.
The problem is that the erasing process takes upwards of 25 minutes. Does
anyone know of a method for speeding up this process?
One idea I had was to partition our hard drive into two smaller drives and
then use one half of the drive for these "data" files (and maybe have the
root directory FAT increased to 1500 or 2000 file entries so all entries
could be in the root as opposed to a slower sub-directory) and then just
reformat that half of the drive when we need to erase all the data files.
Does this sounds like a good idea?
Does anyone have a better suggestion?
Thanks in advance... Fred Seaton
------------------------------
Date: Fri, 14 Aug 87 15:47:47 EDT
From: David Kirschbaum <kirsch@braggvax.arpa>
Subject: Epson Equity I
NetLandians,
If anyone has any experience in upgrading or working with the MS-DOS Epson
Equity I, I'd appreciate your messaging me. (Not the net, please .. probably
limited interest in this old slug.)
Questions concern:
Upgrading (memory, power supply)
Adding hard drive
PC and PC-DOS compatibility
Reliability
Thanks in advance,
David Kirschbaum
kirsch@braggvax.ARPA
------------------------------
Date: Fri, 14 Aug 87 15:57:41 EDT
From: David Kirschbaum <kirsch@braggvax.arpa>
Subject: Lotus 123 Clones
NetLandians,
Would appreciate any feedback on highly-compatible 123 clones (low price,
PC-compatible, preferably with macro enhancements and efficient memory
management, preferably v2.0 compatibility).
Thanks in advance,
David Kirschbaum
kirsch@braggvax.ARPA
------------------------------
End of Info-IBMPC Digest
************************
-------Info-IBMPC@C.ISI.EDU.UUCP (08/19/87)
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" <JAZBO%BROWNVM.BITNET@wiscvm.wisc.edu>
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 <dsill@NSWC-OAS.ARPA>
To: Info-IBMPC Digest <Info-IBMPC@C.ISI.EDU>
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 <stdio.h> /* 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 <stdio.h> 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" <JAZBO%BROWNVM.BITNET@wiscvm.wisc.edu>
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 <W8SDZ@SIMTEL20.ARPA>
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 <WANCHO at SIMTEL20.ARPA>
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: <CGORMAN%DREW.BITNET@wiscvm.wisc.edu> (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 <bilbo.conner@CS.UCLA.EDU>
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 <BRACKENRIDGE@C.ISI.EDU>
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) <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 <PEPRBV%CFAAMP.BITNET@wiscvm.wisc.edu>
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 <VMADSEN%UALTAVM.BITNET@wiscvm.wisc.edu>
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 <stdio.h>
#include <dos.h>
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<argc; inc++)
delete(argv[inc]);
}
int delete(fname)
char *fname; /* File name and extension */
{
union REGS ir, or;
struct FCB tmp;
int i;
tmp.drivenum = 0; /* use current drive */
for(i=0; i<8; i++) tmp.filenam[i] = '\040'; /* Clear FCB name entries */
for(i=0; i<3; i++) tmp.fileext[i] = '\040';
/* Place file name (with wildcards) into FCB */
i = 0;
while((i<8) && (*fname != '\0') && (*fname != '.'))
{
tmp.filenam[i] = *fname;
fname++; i++;
}
if(*fname == '.')
{
fname++;
i = 0;
while((i<3) && (*fname != '\0'))
{
tmp.fileext[i] = *fname;
fname++; i++;
}
}
/* Call DOS to remove the file(s) */
ir.x.ax = 0x1300; /* DOS delete function 13h */
ir.x.dx = (unsigned)(&tmp.drivenum); /* FCB base address */
intdos(&ir, &or); /* Delete all matching file names */
return(or.x.ax); /* Return errors if any */
}
/*
* Print a program usage message, and exit.
*/
usage()
{
printf("\nUSAGE: delete file_name(s)\n\n");
exit(0);
}
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
--
aka : Peter Lauterbach
BITNet : USEREZ8Y@rpitsmts.bitnet
Internet : pbach@itsgw.rpi.edu
Internet : lauterbach@rpitsmts.rpi.edu
------------------------------
Date: Sat, 15 Aug 87 22:43:44 PDT
From: Ya'akov_Miles%UBC.MAILNET@MIT-Multics.ARPA
Subject: Finding Path Name of Executable Program
According to my PC-DOS 3.1 "Technical Reference Manual", page 7-7,
the path name of the executing program is contained AFTER the
environment strings. Specifically, the environment area is as follows
PSP:2Ch --> 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: <rbw@cs.williams.edu>
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 <danny@cappuccino.STANFORD.EDU>
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 <roland@lbl-rtsg.arpa>
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 <BRACKENRIDGE@C.ISI.EDU>
To: Roland McGrath <roland@LBL-RTSG.ARPA>
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 <sidney%acorn@oak.lcs.mit.edu>
------------------------------
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
************************
-------