Info-IBMPC@B.ISI.EDU.UUCP (07/15/86)
Info-IBMPC Digest Monday, July 14, 1986 Volume 5 : Issue 69
This Week's Editor: Richard Gillmann
Today's Topics:
Patches to PC-DOS 3.1 and 3.2
Environment Space in DOS 3.1 and 3.2
MSDOS 3.2 Fact Sheet
Calling DOS from an Interrupt
How to find Disk Free Space from BASIC (2 msgs)
IBM BASIC COMPILER V2.01 and other BASIC goodies
Accelerator Boards
Experience with GEM & MS-C
ASMGEN (2 msgs)
GRAPH Executables Available
PC TeX from Personal TeX, Inc.
Re: 8-Mhz AT, Wait States
DAK BSR X10 Powerhouse Interface
MIDI Software Query
----------------------------------------------------------------------
From: brown@nicmad.UUCP
Subject: Patches to PC-DOS 3.1 and 3.2
Date: 28 Jun 86 19:00:32 GMT
Brian Shapiro writes:
>I am looking for any patches to the PC-DOS 3.1 or higher FORMAT command that
>will prevent users from formatting their Fixed Disks.
>
>Any other patches to DOS would also be greatly appreciated.
PC-DOS 3.20 does exactly what you want. Well, kind-of! You can
still format the hard drive, but now it asks you for the volume-id
name. So, if you get it wrong you have to look it up. Another
safety step. If I remember correctly PC-DOS 3.20 asks you if you are
sure you want the format the drive. But, if you want to make it so
that you can never format a hard drive, that patch is not around.
Besides, that wouldn't stop somebody anyway. They would just get
another copy of the format program and use it instead.
But I can give you the other patches that I have. They follow below.
For others of you who have PC-DOS 3.20, the 10MB 2K cluster patch
still works.
As a little aside, I tried to make 1K clusters on my hard drives
(20MB) and everything went along just fine, ie FORMAT works, Norton's
Utilities works, the PC-Tech Journal's SHOW and INFO works, but
PC-DOS 3.20 CHKDSK locked up. So, I guess 1K clusters are out.
Mike Brown
The CompuServe IBMPC SIG Users Group
PATCHES FOR IBM DOS 3.1
Note: In the patches which follow, it is assumed the user is familiar
with the use of DEBUG. The notation "xxxx" means "anything is ok".
The notation <cr> means press Enter.
FIXED DISK CLUSTER SIZE
If you have a 10 Meg hard disk, the following information collated by
Bill Higgins, provides for 2K clusters instead of the standard 4K
clusters. Typically, you will free up about 10% of the disk space you
are currently using.
2K Cluster Size for 10MB Fixed Disks under DOS 3.1
Standard 10mb fixed disks formatted under DOS 3.1 utilize 4k clusters
(i.e., the minimum space allocated to any file is 4096 bytes), while
drives 20mb and larger utilize 2k clusters. I use a PC with twin 10mb
drives under DOS 3.1. Since I have a multitude of small files on these
disks, the smaller allocation unit's space saving advantage far outweighs
any theoretical disadvantage of additional overhead for DOS to handle the
added allocation units.
With the help of Bob Morse, SysOps Jim Gainsley, and Conrad Kageyama,
and the DOS Technical Reference, I was able to make the changes necessary
to use 2k clusters on both of my 10mb drives. By following the
step-by-step instructions below, you will be able to make the switch to
2k clusters yourself.
NOTE: THE FOLLOWING PROCEDURE WILL DESTROY ALL DATA ON THE FIXED DISK!!!
You will need the following:
(1) IBM PC-DOS version 3.1 (3.0 appears NOT to work).
(2) A disk utility such as DISK REPAIR (a part of the IBM PROFESSIONAL
DEBUG FACILITY), or DISMOD (a USS program, available on many BBS's),
or equivalent. Note: You will not need this, if you use the
Alternate Method in #4a below.
Most critical to the process is the sequence in which this procedure is
attempted. Here is the 4k to 2k cluster procedure:
(1) Do a complete backup of the fixed disk, using your current version
of DOS.
(2) Cold boot DOS 3.1, run FDISK to create or be sure that a DOS
partition exists on the Fixed Disk.
(3) Format the fixed disk using the DOS 3.1 FORMAT.COM program. Do NOT
use any parameters (no /s or /v).
(4) Using your disk utility, select the boot sector and view it.
See below for an explanation of the pertinent info in this sector.
At location AA below, you should see a value of 08 which is the
number of sectors per cluster. Change this to 04.
At location BB below, you should see a value of 0800 which is the
number of sectors per fat (in hex Word format). Change this to 1500.
The results should appear as in CC and DD below.
All changes to the fat sectors required for 2k clusters will be
accomplished by the subsequent format in instruction 6 below. No
other manual changes are required.
Example of first few bytes in the Boot Sector of the fixed disk,
displayed in hex format, after formatting with DOS 3.1, and prior
to 2k cluster size changes: (The bytes of interest are located at
Boot sector Offsets 0Dh = Sectors per cluster, and 16h = Sectors
per FAT.)
EB299049 424D2020 332E3100 02080100 020002F3 50F80800
^^ ^^^^
AA BB
After the 2k cluster size changes:
EB299049 424D2020 332E3100 02040100 020002F3 50F81500
^^ ^^^^
CC DD
Where the data elements directly above AA are sectors per cluster,
and above BB are sectors per FAT.
(4a) Alternate Method:
If you would rather, and if you are familiar with the operation
of Debug, the following method can be used.
Under DOS 3.1, do:
DEBUG
-L 0 n 0 1 <cr>
-E 0D <cr>
xxxx:0D 08.04 <cr>
-E 16 <cr>
xxxx:16 08.15 <cr>
-W 0 n 0 1 <cr>
-Q
where, n = the fixed disk drive as follows:
If fixed disk is drive B then n=1
" C " n=2
" D " n=3
" E " n=4
NOTE: Be *really* careful when you do the L and W commands in
the foregoing sequence. Would be best to check your
work by doing DEBUG, then
-L 0 n 0 1 <cr> then doing
-D 0D L1 <cr> and
-D 16 L1 <cr> making sure that the results
are 04 & 15 respectively.
Then exit by doing
-Q
A more detailed explanation of these two changes:
The number of sectors per cluster would change from 08 to 04, since
that's what this is all about. The sectors per FAT will change, in
order to accomodate (1) the increased number of possible FAT
entries, and (2) the increased size of each fat entry which will be
in 16-bit format instead of the former 12-bits. The value to use for
a 10 meg & 2k clusters would be 21 sectors, or 1500 in hex word
format. (In this case the 15 is all that counts. 15 hex = 21 decimal.)
(5) Exit the disk utility and do a cold boot with DOS 3.1. This is
critical, since the boot sector is read by DOS only once, at boot
time, in order to build the BIOS Parameter Block. Having different
info in the boot sector than what's in the memory-resident BPB will
give UNPREDICTABLE RESULTS.
The following is safest way to preceed. Please use it.
(6) Reformat the drive using the DOS 3.1 FORMAT.COM,
FORMAT C: /S
(You may also include /V, if you wish to include a volume label.)
DOS 3.1 FORMAT will NOT affect your changes to the boot
sector. (This a change from DOS 3.0 FORMAT, which re-writes
the boot sector.)
(7) Restore your files, BEING SURE TO USE the RESTORE parameter, /P
which prompts before restoring system files.
**** WARNING ****
YOU MUST NOT ALLOW THE TWO SYSTEM FILES, IBMBIO.COM AND IBMDOS.COM
TO BE RESTORED, EVEN IF THEY ARE DOS 3.1 !!! IF YOU DO, THEY WILL
NOT BE PUT IN THE PROPER LOCATIONS AND YOUR FIXED DISK WILL NOT BE
BOOTABLE AND YOU WILL HAVE TO REFORMAT !!!
Avoid restoring an earlier version of COMMAND.COM, but if you do
restore an earlier version, nothing is lost, just be sure to copy
a 3.1 version over it afterwards. You should now be operational
again, with 2k clusters.
Further info on the entries in the boot sector entries used to build
the BIOS Parameter Block can be found in the DOS 3.1 Technical
Reference, Page 2-28. Of course, I cannot warrant that this change
will work for all controller/disk combinations, particularly for
controllers and drives which are not 'XT clones' though it 'should
work' for all drives compatible enough to work under DOS 3.1.
Comments to: ** Bill Higgins [70575,307] CIS, IBMPC SIG **
ENVIRONMENT SIZE
Thanks to Bob Morse, the environment size can be patched as follows:
DEBUG COMMAND.COM
-E 0D11<cr>
xxxx:0D11 0A.1E<cr>
-W<cr>
-Q<cr>
(1E is for a 544 byte nominal size. Use 3C for a 1K size.)
SCREEN SCROLLING
From Ward Christensen, the ANSI.SYS scrolling patches to disable the
wait for retrace and the screen blanking have new addresses but they
work just fine. Using DEBUG, proceed as follows:
DEBUG ANSI.SYS
-E 02E3<cr>
xxxx:02E3 74.90 FB.90<cr>
-E 02EA<cr>
xxxx:02EA EE.90<cr>
-W<cr>
-Q<cr>
DISABLE EDLIN AUTOMATIC .BAK FILE CREATION
On a BBS I found the patch from an unknown author to disable the
automatic .BAK file when using EDLIN. Using DEBUG proceed as follows:
DEBUG EDLIN.COM
-E 0CD5<cr>
xxxx:0CD5 56.41<cr>
-W<cr>
-Q<cr>
AUTOMATIC INSTALLATION OF PRINTER FOR DOS PRINT
Also on a BBS I found the patch by an unidentified author to PRINT.COM
to obviate the need to type the desired printer port. If the printer
port is LPT1, then using DEBUG proceed as follows:
DEBUG PRINT.COM
-E 1788<cr>
xxxx:1788 E8.90 CB.90 02.90<cr>
-E 179A<cr>
xxxx:179A CD.90 21.90<cr>
-W<cr>
-Q<cr>
If the printer port is LPT2 then the following address must ALSO be
modified as follows:
-E 10CA 4 "LPT2"
DISABLE AUTOMATIC HEADER IN FIND.EXE OUTPUT
The FIND program puts an automatic header ********** filename in the
output listing. To disable this header, patch FIND.EXE as follows:
REN FIND.EXE FIND.TMP
DEBUG FIND.TMP
-E 0424<cr>
xxxx:0424 03.2C<cr>
-W<cr>
-Q<cr>
REN FIND.TMP FIND.EXE
PERMIT MORE THEN 10 MISMATCHES IN COMP.COM
I have patched COMP.COM to permit 50 mismatches as follows:
DEBUG COMP.COM
-E 08E2<cr>
xxxx:08E2 0A.32<cr>
-E 0BF8<cr>
xxxx:0BF8 31.35<cr>
-W<cr>
-Q<cr>
ECHO OFF
I have patched COMMAND.COM to set the default to echo off to
to obviate the need for the ECHO OFF and CLS statements at the beginning
of a batch file.
DEBUG COMMAND.COM
-E 1967<cr>
xxxx:1967 01.00<cr>
-W<cr>
-Q<cr>
Note 1: The default for AUTOEXEC.BAT files will still be ECHO OFF.
Note 2: If the last thing done in a .BAT file is to do ECHO ON, then
you will get two prompts at exit.
The following is from Calvin R. Shields as reprinted in PC Mazazine Vol. 4
No. 4, p. 235 and will set ECHO OFF in your AUTOEXEC.BAT file.
DEBUG COMMAND.COM
-E 105B<cr>
xxxx:105B 03.02<cr>
-W<cr>
-Q<cr>
BLANK LINES FROM ECHO
This patch from Calvin R. Shields in PC Magazine Vol. 4, No. 4, p. 235
enables the ECHO command followed by two spaces to produce a blank line
instead of returning the ECHO status.
DEBUG COMMAND.COM
-E 3878<cr>
xxxx:3878 E8.83 20.F9 00.02 74.72<cr>
-W<cr>
-Q<cr>
FORMAT: Add BEEP at completion of formatting
Stephen Berg provided a patch to FORMAT.COM in DOS 2.1 to produce a
BEEP when FORMAT completes. The patch adapted to DOS 3.1 is shown
below. The patch is most easily made with a disk editor. Using a disk
editor look for the exact string:
Format another (Y/N)?
It begins at offset 142Fh (Note: This NOT a Debug address!) If you
are using DISMOD, the address is record 0014 byte 2Fh
Enter the following exact string (omit quotes), ^G means Ctrl-G:
"Do another (Y/N) ?^G " (Note that one blank space follows ^G)
If you wish to use Debug then:
DEBUG FORMAT.COM
-D 152F L20<cr> ;Displays "Format another..."
-E 152F "Do another (Y/N) ?",07," "<cr> ;Quotes must be included
-D 152F L20<cr> ;Displays your entry.
-w
-q
The 07h (^G) does the BEEP.
Below is what you should see after the first D command above.
DEBUG FORMAT.COM
-D 152F L20
xxxx:1520 46 F
xxxx:1530 6F 72 6D 61 74 20 61 6E-6F 74 68 65 72 20 28 59 ormat another (Y
xxxx:1540 2F 4E 29 3F 00 AF 0E 0D-0A 00 C7 0E 49 6E 76 /N)?........Inv
^^ ^
NOTE: THE 00H MUST NOT BE DISTURBED!!!
CORRECTION OF CLS COMMAND ERROR
This patch from Calvin R. Shields in PC Magazine Vol. 4, No. 4, p. 235
corrects an error in the CLS command which presently clears 26 lines
rather than the standard 25 lines on a display screen.
DEBUG COMMAND.COM
-E 263B<cr>
xxxx:263B 19.18<cr>
-W<cr>
-Q<cr>
COMMAND.COM ** SOME UNDOCUMENTED FEATURES
The following is from Bob Smith, author of 'Tall Screen'.
EXPANDING THE PCDOS ENVIRONMENT AREA:
A recent forage into DOS 3.1 COMMAND.COM uncovered the following
seemingly supported, but undocumented feature:
/E:NN Set size of Environment area to NN paragraphs. Range
is 10 to 62 Numbers outside that range are ignored.
The default is /E:10.
This feature is most useful when used in conjunction with the
SHELL= OPTION in CONFIG.SYS. In particular, my usage is as follows:
SHELL=C:\DOS\COMMAND.COM C:\DOS /P /E:20
Other options include:
/D Don't execute AUTOEXEC.BAT
/F Skip response to ABORT, RETRY, IGNORE question in the System
default INT 24h handler. (Quite likely this feature is
named /F for 'FLAKY'.)
A NOTE ON THE 'SHELL' COMMAND, ABOVE...
The sample 'SHELL=' CONFIG.SYS command, above, shows several
undocumented options available. In particular, the first parameter
shows where the initial copy of COMMAND.COM is to be found (in the
above example, on the '/DOS' subdirectory on the 'C:' disk). This is
as documented by IBM. The second parameter indicates the drive and
subdirectory from which COMMAND.COM is to be reloaded. Here again,
the '/DOS' subdirectory on 'C:'.
The '/P' parameter indicates that the substitution should be permanent.
Note that in the DOS 3.10 REFERENCE MANUAL, the above two parameters
are described for the 'COMMAND' command. What IBM doesn't tell you is
that they also work on the 'SHELL=' command in CONFIG.SYS
My thanks to Bob, Ward, and others for their patches.
Comments to: ** Ted Eyrick [72446,317] CIS, IBMPC SIG **
Edited by:
Jim Gainsley [76703,1007]
(SysOp) IBMPC SIG
CompuServe
8-9-85
9-2-85
======================================================================
2/20/86
IBM PROVIDES THE FOLLOWING PATCH FOR DOS 3.0 AND DOS 3.1
DESCRIPTION: This patch corrects a condition where DOS is doing a
test on bit 8 to determine if an error code returned from INT 13h
should fall into the DMA boundary violation handler. This test is
causing error codes other than DMA (09h) to fall into this handler.
The patch changes this test to a direct compare.
The patch corrects the same problem with each version of DOS 3.
The patch is made to the System file IBMBIO.COM.
NOTE: The safest method of doing this is given in the last paragraph
of this document. However, for those who feel sufficiently competant,
and who don't wish to follow that course, the following method is
presented.
It will first be necessary to remove the Hidden/System/Read-only
attribute, thus making the file a 'normal' file. AFTER you have
completed the patch process, you MUST RESET this attribute to
Hidden/System/Read-only.
To work with the attibute, you can use the PD program CHMOD, or the
Norton Utility Ver 3.1's FA.COM, Morgan Computing's DISKTOOL, or IBM's
DISK REPAIR, a part of the PROFESSIONAL DEBUG package. You cannot use
the DOS utility ATTRIB.COM.
(Just for information, a 'normal' file attibute is either 00h or 20h,
while a Hidden/System/Read-only attribute is either 07h or 27h. The
attribute is one byte and is located in the Directory entry for the
file, immediately following the last character in the filename
extension. In this case, after the 'M' in COM.)
See the documentation for whichever program above you've chosen to
determine the procedure to be used.
* * * * * * *
NOTE: YOU ARE PATCHING THE HEART OF THE OPERATING SYSTEM... BE VERY
CAREFUL!!! IF YOU THINK YOU MAY HAVE MADE A MISTAKE, EXIT
BEFORE WRITING THE CHANGES AND START OVER AGAIN.
Format a floppy using the command, FORMAT /S. Set the attribute for
IBMBIO.COM to 'normal' as given above.
Use the DOS utility DEBUG.COM, (or MicroSoft's SYMDEB), to make this
patch. It is assumed that you are familiar with its use.
Curiously, the patch changes only 4 bytes, though IBM indicates a
5-byte patch.
PATCH NUMBER: PATCH31.001
Use this patch if you have DOS 3.1:
DOS LEVEL: 3.10
FILE PATCHED: IBMBIO.COM
OFFSET OF PATCH: 09BB (Note: DEBUG address = 0ABB)
NUMBER OF BYTES: 5
OLD CODE: F6 C4 08 75 0F
NEW CODE: 80 FC 09 74 0F
In what follows, Do not type the hyphens. The 'xxxx' mean 'don't care'.
At the DOS prompt type:
DEBUG d:\IBMBIO.COM <cr> where d: = drive containing IBMBIO.COM
-D 0ABB L5 <cr>
xxxx:0AB0 You should see OLD CODE given above starting at 0ABB.
-E 0ABB 80 FC 09 74 0F <cr>
-D 0ABB L5 <cr>
xxxx:0AB0 You should see NEW CODE given above starting at 0ABB.
-W <cr>
Writing xxxx bytes
-Q <cr>
Patching complete. Reset the attribute to Hidden/System/Read-only.
(At this point, you should consider bringing up the file again and
and doing -D 0ABB L5, just as a final check).
PATCH NUMBER: PATCH30.001
Use this patch if you have DOS 3.0
DOS LEVEL: 3.00
FILE PATCHED: IBMBIO.COM
OFFSET OF PATCH: 0964 (Note: DEBUG address = 0A64)
NUMBER OF BYTES: 5
OLD CODE: F6 C4 08 75 04
NEW CODE: 80 FC 09 74 04
In what follows, Do not type the hyphens. The 'xxxx' mean 'don't care'.
At the DOS prompt type:
DEBUG d:\IBMBIO.COM <cr> where d: = drive containing IBMBIO.COM
-D 0A64 L5 <cr>
xxxx:0A60 You should see OLD CODE given above starting at 0A64.
-E 0A64 80 FC 09 74 04 <cr>
-D 0A64 L5 <cr>
xxxx:0A60 You should see NEW CODE given above starting at 0A64.
-W <cr>
Writing xxxx bytes
-Q <cr>
Patching complete. Reset the attribute to Hidden/System/Read-only.
(At this point, you should consider bringing up the file again and
and doing -D 0A64 L5, just as a final check.)
TO UPDATE IBMBIO.COM ON YOUR HARD DISK:
IMPORTANT!!! DO NOT USE DEBUG TO PATCH IBMBIO.COM ON A HARD DISK.
1. Complete the above, creating a floppy with the patched
IBMBIO.COM, with attibute reset to Hid/Sys/Read-only. Then: Copy
the DOS utility SYS.COM onto the floppy. Set the default drive to A:
and put the floppy in it. Then type SYS C:<cr> (assuming your HD is
Drive C:). You should then see the message 'system transferred'.
YOU CANNOT SIMPLY USE DEBUG TO PATCH AN IBMBIO.COM THAT RESIDES ON A
HARD DISK, BECAUSE DEBUG WILL NOT WRITE THE FILE BACK TO THE SAME
SPACE ON A HARD DISK. IBMBIO.COM MUST RESIDE IN A SPECIFIC PLACE ON
A DISK, and while DEBUG will write it back to the same place it came
from on a floppy, it will not do so on a hard disk.
* * * *
If you're patching a hard disk and have a problem, you can always put
your DOS System disk in Drive A:, boot it, and type SYS C:<cr>, which
will replace the system files on the HD, provided of course that you
haven't written anything to the hard disk before doing this.
If you are not familiar with DEBUG, or simply don't want to monkey with
it, then you may obtain the DOS 3 Patch Disk No. 1, from your dealer at
no charge, (ask them to get it from Dealer Support if they don't have it).
That disk contains an IBM program PATCH.COM, which will make the patch
automatically. Since that program is not PD, we cannot post it.
ihnp4------\
harvard-\ \
Mr. Video seismo!uwvax!nicmad!brown
topaz-/ /
decvax------/
------------------------------
From: bill@hpcvlo.uucp
Subject: Environment Space in DOS 3.1 and 3.2
Date: 16 Jun 86 15:02:00 GMT
First line in your config.sys becomes something like this:
SHELL=C:\COMMAND.COM /P C:\ /E:20
^^environment size in paragraphs
Note that if you move up to DOS 3.2, you specify environment size using
the same "/E:" switch, but the size is then in BYTES rather than paragraphs.
bill frolik
hp-pcd!bill
------------------------------
From: jim@hpcvla.uucp
Subject: MSDOS 3.2 Fact Sheet
Date: 2 Jun 86 04:25:00 GMT
As you have probably heard, IBM PCDOS 3.2 is now available. It
was introduced along with the IBM PC Convertible and revised
versions of the PCXT and PCAT. Here are some details cribbed
from IBM's April 2, 1986 Programming Announcement:
o Upwardly compatible from IBM Personal Computer DOS
Version 3.1.
o Supports IBM PC Convertible (DOS 3.2 3.5-inch version).
o Supports IBM Token-Ring Network.
o Supports IBM Personal Computer 3.5-inch External Diskette
Drive (DOS 3.2 3.5-inch version).
o Supports all members of the IBM Personal Computer
family.
o Provides full support for 720 Kb 3.5-inch diskette
drives.
o Provides a new command. REPLACE, to replace all occurrences
of a file on a disk to facilitate installation of new
versions of DOS or application programs.
o Provides a new command, XCOPY, to allow copying of files
from more than one subdirectory where the source and target
drives are of different densities, making complete or
periodic backups easier. Options allow prompting for
selective copying of files, verify after write, copying of
lower level directories even when empty, copying of files
modified after a specified data, and copying of archived
files only (with or without modifying the archive bit).
o Provides logical drive support. Allows a physical drive to
be referenced by more than one device letter. Example:
A user can copy from one 720Kb 2.5-inch diskette to another
720 Kb 3.5-inch diskette using only one 3.5-inch diskette
drive.
o Removes default drive capability on FORMAT. When the
FORMAT command is executed, the drive letter must be specified,
to prevent accidental reformatting of a disk or diskette.
o DOS environment area can now be reserved. A new option of the
SHELL command allows this area to be expanded to 32Kb. This
allows the user to specify more extensive PATH commands,
PROMPT commands, and SET commands without running out of
environment space.
(Note: See the SHELL page (4-34) or the COMMAND page (7-53) in the
**DOS 3.2*** manual for a description on how to set the environment
size. Please note that the environment size parameter is in BYTES in
3.2, which is a change from PARAGRAPHS in 3.1. If you specify an
environment size parameter less than 160 in 3.2, you will get
complaints.)
o Utilization of the BIOS parameter block: The BIOS parameter
block is used to obtain media-type information to remove
dependencies on the File Allocation Table ID for the media-
type information.
o I/O control subfunctions: DOS 3.2 implements subfunctions
that enhance device independence. These subfunctions allow
querying and changing of device parameters as well as
logical device support. These subfunctions are:
- Get device parameters
- Set device parameters
- Read track on logical drive
- Write track on logical drive
- Format and verify track on logical drive
- Verify track on logical drive
- Get logical drive number (determine if a device has
more than one letter)
- Set logical device number (suppress diskette change
request messages)
Jim Andreas
hplabs ---->\
harpo ----> \
orstcs ----> >--!hp-pcd!jim
microsoft ----> /
textronix ---->/
(503) 757-2000 x2860
Portable Computer Division
Hewlett-Packard
1000 NE Circle Boulevard
Corvallis, Oregon 97333
------------------------------
From: waters@mosaic.dec.com
Subject: Calling DOS from an Interrupt
Date: 9 Jun 86 15:44:21 GMT
The answer is: you can't do it (easily).
The problem that you are having is that MS-DOS (PC-DOS) is NOT
re-entrant. By re-entrant, I mean that you cannot interrupt
DOS while it is doing something and make another DOS call.
You may be sitting idle and apparently doing nothing, but DOS
is still busy (i.e., the timer tick goes into DOS to update the
time, waiting for keyboard input, etc.).
There is a flag called the "INDOSFLAG" which you can test to see if
you can make a DOS call. When the flag is set, you should not make
ANY DOS calls. When it is clear, you can make a DOS call. The flag
is NOT a supported feature and is not fullproof (though many people
have used it successfully). The location and availability of the flag
is also very version dependent. You program should check the DOS version
number before making itself resident (and issue an error if it is run
under a different version of DOS).
There is an undocumented DOS call which you can use to determine the
location of the INDOSFLAG.
MOV AH,34h
INT 21h
Now ES:BX points to the location of the flag. The flag does not move,
so your program can save the pointer away (i.e., it is not necessary to
make this call every time you need to check the INDOSFLAG -- just make
it once when your program is first run.
Now, there is a problem: what do you do if the flag is set (indicating
that DOS is busy)? You can't just loop waiting for the flag to change
since DOS needs to get some run time so it can finish what it was doing
(when it was interrupted). The only way to do that is to return from
your ISR.
Yep, this means that you may want to SCHEDULE an event to
take place (namely, to make your DOS call). So, you may
write a second ISR, which hangs off of the timer tick interrupt 1Ch
(see your systems Tech reference). Then, your ISR can set a flag
indicating that you want your DOS call to be made (asynchronously to
what you are doing). The timer tick ISR will check this flag, and
if set, look at the INDOSFLAG. If the INDOSFLAG is clear, it can then
make your DOS call. If the INDOSFLAG is still set, just wait till the
next clock tick and try again.
When writing a clock tick ISR for interrupt 1Ch, remember to chain the
old vector (because there may be other processes hooked to the 1Ch
vector). What I mean is, instead of doing an IRET from your routine,
do a JMP FAR to the old address contained in the vector before you
hooked the interrupt.
In general, it is not a good idea to make DOS calls from ISR routines.
The INDOSFLAG is very version dependent, NOT SUPPORTED, and not the
most reliable thing (though, as I have said, many people have used
it successfully).
Lester Waters
...!decvax!decwrl!dec-rhea!dec-viking!waters (UUCP)
WATERS%VIKING.DEC@DECWRL.COM (Arpa)
Disclaimer: These views do not necessarily represent the views
of Digital Equipment Corporation.
------------------------------
Date: Sun, 13 Jul 86 17:34:53 EDT
From: Brent W Baccala <baccala@USNA.ARPA>
To: atswaf%uoft01.bitnet@WISCVM.ARPA
cc: info-ibmpc@USC-ISIB.ARPA
Subject: How to find Disk Free Space from BASIC
> Does anyone know of a way from a BASIC program to determine the amount
> of space available on a disk?
I'm sending a copy of this question's answer to the distribution list,
for those interested in such things.
First, a little bit of background:
DOS provides an interupt structure allows a graceful interface between
a user program and the operating system. Some interupts handle error
conditions (divide by zero, impossible instruction) in an intellegent
fashion (i.e. without hanging up the system). Others allow a user to
control system facilities such as the video display, disk drives etc.
One interupt, numbered 21 hex (33 decimal), is a sort of "escape code"
that allows a user to make "function requests" by placing the number
of the function request in a register (AH), and activating interupt
21H. These function requests are designed to perform relatively
complex tasks without bothering the user with details.
Now, the good stuff:
Function request 36H (54 decimal) is called "Get Disk Free Space".
Actually, it gets a lot more than that, but we'll need just about
all of it. To use it, you run a machine language program like this:
MOV AH,36H (The function request number)
MOV DL,0 (The drive number, 0=Current, 1=A, 2=B etc.)
INT 21H (Actually performs the interupt)
Now we have the needed information. It is placed into the machine
registers as follows:
AX - sectors per cluster
BX - available clusters
CX - bytes per sector
DX - clusters per drive
The next step is to write an interface between the machine language
program and the BASIC program. BASIC does its math in what is called
the Floating Point Accumulator (FAC). Actually, this is a bit of a
misnomer, because the FAC holds integer as well as floating-point
data. Anyway, we can't (easily) access the FAC directly, but then
we don't have to. Routines have been provided for us to take the
data in the FAC and place it into register BX, and take the data
in register BX and place it back into the FAC. The BASIC USR call:
USR[n](arg)
will place its (optional) argument into the FAC, call the machine
language routine (we) associated with it, and then assume the value
of the FAC after the machine language routine returns. In this fashion,
we can pass data back and forth between machine language programs and
BASIC programs.
Armed with this information, we are now ready to write a BASIC program
that will generate the required machine language routine, and then
run it.
The first thing to decide is where to put the machine language routine.
This depends heavily on how much memory your system has. Check Appendix
C, BASIC reference manual, for more information, but suffice it to say
that if you have less than 96K, you will have to do some funny business
with the CLEAR statement in BASIC. If you have much more than this (I
have 512K) than you don't have to worry about running into BASIC. Just
place the routine high enough in memory that it doesn't interfere with
anything. For this example, I'll use segment 1700H. This is low enough
to work on most computers. Note, however, that if you load in enough
printer buffers, RAMdisk drivers etc., BASIC may be forced to move
high enough in memory to interfere with this routine. The "right" place
to load a machine-language routine is very site-dependent.
Next, we will write a simple machine language routine to obtain the
number of available clusters on a given drive. It looks like this:
9A 0300 00F6 CALL FRCINT (This puts BASIC's FAC data into BX)
8A D3 MOV DL,BL (This puts the low byte of BX into DL,
where Function 36H expects the drive
number)
B4 36 MOV AH,36H (Same as above)
CD 21 INT 21H
90 NOP (NO Operation - these two commands do
nothing, and are here as place
holders. We'll see what to put here
later.)
90 NOP
9A 0700 00F6 CALL MAKINT (This puts BX back into the FAC)
CB RET (Returns to BASIC)
The hexadecimal numbers down the left column are the machine language
codings that have to be put into memory. We can write a BASIC program to
do this task like so:
10 DEF SEG=&H1700
20 ADDR=0
30 READ BYTE:IF BYTE<>-1 THEN POKE ADDR,BYTE:ADDR=ADDR+1:GOTO 30
40 DEF USR=0
50 PRINT USR(0)
60 END
70 DATA &H9A,&H03,&H00,&H00,&HF6,&H8A,&HD3,&HB4,&H36,&HCD,&H21
80 DATA &H90,&H90,&H9A,&H07,&H00,&H00,&HF6,&HCB,-1
The DEF SEG on line 10 set the segment address for the rest of the program.
The loop on lines 20 and 30 read data from lines 70 and 80 and write them
into memory, starting at offset 0 (into segment 1700H). The "&H" introduces
a hexadecimal number, so I just copied numbers from the machine language
program to the BASIC data statements. The -1 signals the end of the data,
which breaks the loop. Line 40 sets USR0 (the 0 is implied) to offset 0.
Line 50 calls the machine language routine with argument 0 (current disk)
and prints the return value, which is the number of clusters available on
the disk.
OK, now we have a program to show us the number of free clusters on a disk.
So what's a cluster?
A cluster is the basic unit of disk allocation. Each file on a disk
is assigned an integral number of sectors. If the files does not fit
evenly, the last cluster is partly unused. So it might seem at first
that by multiplying the number of free clusters (returned by that routine
we just wrote) by the size of a cluster, we can determine just how many
bytes are available on a disk. Well, not quite. The directory entry
itself takes up space (32 bytes to be exact), and the extra entry just
might cause the directory to grap another cluster. So to find out
how many space is actually available for your file, we must multiply
the number of clusters MINUS 1 by the size of a cluster.
So how big is a cluster?
That varies from drive to drive. There are tables to determine such
things, but for portability considerations, the program should determine
this for itself. Checking back at the function definition for 36H, we
see that it also returns the number of sectors in a cluster, and the number
of bytes in a sector. The product of these two return values is the
number of bytes in a cluster. All we have to do is get them back to BASIC!
Now a MOVe instruction from one register to another takes up two bytes
in the program. A No OPeration instruction takes up one byte. Remember
those two NOPs I put in the machine language? They can be replaced by
a MOV from some register to BX, which is what gets sent back to BASIC.
Register AX contains the number of sectors per cluster, and CX has
the number of bytes per sector. The corresponding MOVs are:
8B D8 MOV BX,AX (Sectors per cluster)
8B D9 MOV BX,CX (Bytes per sector)
They can just be POKEd into the NOP slots. In fact, since the first
byte is the same, the second substiution requires only one byte. So
the complete program is:
10 DEF SEG=&H1700
20 ADDR=0
30 READ BYTE:IF BYTE<>-1 THEN POKE ADDR,BYTE:ADDR=ADDR+1:GOTO 30
40 DEF USR=0
50 FREE=USR(0)
60 POKE 11,&H8B:POKE 12,&HD8
70 SECTS=USR(0)
80 POKE 12,&HD9
90 BYTES=USR(0)
100 PRINT "Free bytes: ";((FREE-1)*SECTS*BYTES)
110 END
120 DATA &H9A,&H03,&H00,&H00,&HF6,&H8A,&HD3,&HB4,&H36,&HCD,&H21
130 DATA &H90,&H90,&H9A,&H07,&H00,&H00,&HF6,&HCB,-1
If you need any other hacker-type questions answered, just drop me a line
and I'll be glad to attempt an answer.
- BRENT W. BACCALA -
Aerospace Engineering Department
U.S. Naval Academy
Annapolis, MD
<baccala@usna.arpa>
------------------------------
Date: Sun, 13 Jul 86 19:27:16 PDT
From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA
To: info-ibmpc@USC-ISIB.ARPA
Subject: How to find Disk Free Space from BASIC
100 REM * This program finds bytes free on default disk
110 '
120 ' CALL FREE(free_clusters,sectors/cluster,bytes/sector)
130 '
140 DIM FREE%(13)
150 FREE%( 0)=&HB455:FREE%( 1)=&H3236:FREE%( 2)=&HCDD2:FREE%( 3)=&H8B21
160 FREE%( 4)=&H8BEC:FREE%( 5)= &HA76:FREE%( 6)=&H1C89:FREE%( 7)=&H768B
170 FREE%( 8)=&H8908:FREE%( 9)=&H8B0C:FREE%(10)= &H676:FREE%(11)= &H489
180 FREE%(12)=&HCA5D:FREE%(13)= &H6
190 '
200 CLUSTERS%=0:BYTES%=0:SECTORS%=0:FREE=0 ' Do this so array won`t move
210 '
220 FREE=VARPTR(FREE%(0)):CALL FREE(CLUSTERS%,SECTORS%,BYTES%)
230 PRINT"There are"CLUSTERS%*1#*SECTORS%*BYTES%"bytes free on default disk"
------------------------------
From: brown@nicmad.UUCP
Subject: IBM BASIC COMPILER V2.01 and other BASIC goodies
Date: 17 Jun 86 21:32:19 GMT
If you have been following this group, there have been discussions about
the sad shape of the IBM BASIC Compiler, ver 2.0. Well, the letter that
I had sent to IBM (a copy was posted here) got some response. But, before
the response came from the IBM Consumer Relation Department I received a
copy of the latest compiler from another source. BTW, all of the questions
that I had asked IBM have not been answered yet. The main one being why
didn't IBM say anything publically about the compiler problem. You know,
they still haven't made any public type of announcement about the compiler.
Anyway, the earlier versions of the patches (which were actually whole
new compiler programs) were supposidly not officially released. One
version was supposidly refused, as delivered from MicroSoft. But it
hit the streets anyway. She said that it caused more problems than it fixed.
I find it hard to believe that IBM did that. As you know, IBM won't even
tell someone something is coming, let alone let it sneak out to people.
My source, who has a direct link with the compiler group, even knew about
the bad version. So, I don't know the real story there.
What you need to get from you IBM dealer is the latest patch diskette that
is dated 04/04/86. When it compiles, it even gives a version number of 2.01
in the listing file.
I haven't been able to test it on some of the code that has given me trouble,
but it now works with the RBBS-PC code, which it NEVER worked with before.
A couple of other things while I am talking about the compiler.
A few of you have been having problems with getting sub-routines to work
with error trapping. Well, RBBS-PC uses error trapping in the SUB calls
and it works just fine. The secret is that the SB errors that you get
are ignored. The current version has 20 such errors. If you would like
a copy of the source code, send me some e-mail and I will send a copy
back for you to look at and compile, to get the idea how it is done.
The last thing is to do with the BASCOM20.LIB dropping DTR when a com
line is opened or closed. There is a patch for that and it goes as follows:
1. Make a backup of BASCOM20.LIB
2. DEBUG BASCOM20.LIB
3. -S 100 FFF0 83 C2 04 32 C0
This should give you two locations. If not give up. But it should
as it has worked on all of them so far.
4. Unassemble the two address given. You should see:
ADD DX,+04
XOR AL,AL
and within a couple of instructions:
OUT DX,AL
5. -A xxxx:nnnn
Replace nnnn with one of the addresses given. The xxxx can be ignored.
6. Assemble the following at the address:
MOV AL,01
7. After entering the instruction, be sure to enter RETURN again to get
out of the assembly mode.
8. Repeat 5 through 7 for the other address.
9. Write the file out.
10. Quit as you are done.
The above patch was initially reported on PC bulletin boards by Jeff Porter.
BTW, if you are using the Microsoft QuickBASIC compiler, the patch works
just as well with the BCOM10.LIB file. Actually Jeff did his research on
the Microsoft version.
Oh, before I forget. There is a file called SMALLERR.OBJ that comes with
the latest version of the IBM Basic Compiler. I have no idea what it is
for and I am waiting for a call from IBM to tell me what it is for.
ihnp4------\
harvard-\ \
Mr. Video seismo!uwvax!nicmad!brown
topaz-/ /
decvax------/
------------------------------
Date: Sun, 13 Jul 86 15:13:23 EDT
From: Chris Schmandt <geek@MEDIA-LAB.MIT.EDU>
To: Info-IBMPC@B.ISI.EDU
Subject: Accelerator Boards
I would like to see more discussion of accelerator boards.
Here's my two cents worth.
Just when I had gotten settled down to a faster life style on
my XT with 2 Mb of JRAM plus their winning ramdisk software and
my own hard reset switch to get me out of a jam, I was loaned
a 80286 accelerator board and now I *must* have one. I don't
know much to base a comparison on. Clearly, you want a board,
rather than just a chip socket level connection, so you can
run off memory on the board and really use the 16bit wide
bus. Also, if you can switch between the board processor and
the 8088 that can be a real win, as some software won't work
on the faster processor if it depends on wait loops for timing
information (Hayes' Smartcom is one). And, if you are developing
software you hope to sell some day, it is important to be able
to run on the 8088 just to see how well you perform on the machine
everyone who might buy your stuff owns.
I have been using the PC-elevATor (sic) board from Applied Reasoning
of Concord, MA. It is a 80286 board, 8 MHz, with 2 Mb on board.
This is probably not that different from the Orchid 286e. What
is very nice is their disk caching utility which can use the
remaining 8088 memory while you are running on the 286 for a
cache. This gives you about 480K (for a 640K XT) and their
recent (version 3.01) chacher works like a charm.
Also winning is their new memory manager, which can lump together
the extra 1 Mb on their board and any other EMS spec'd memory you
have on your XT and divvy it up between print spoolers, EMS, or
extended (i.e., VDISK-able) memory. (Only the 480K left from
Dos on the 8088 can be used for disk caching. I "jet" (copy)
all my tools into the VDISK, and use it as a read-only drive
at the top of my path).
Applied Reasoning also has a 10 MHz and 12 MHz (wow!) versions,
but you can't do a simple upgrade becuase the parts incompatibilities
is not just crystal and RAM. The version 3.01 of their software
is much superior to older versions. I am pretty happy with this
board.
Incidently, the JRAM-3 cards don't work with this board. Tall Tree
does pretty minimal address decoding on their bank select registers,
so it is easy to accidently hit one and suddenly you've got random
data swapped in to your page 0 and bye bye interrupt vectors!
As I am thinking of buying 5 or so accelerator cards, I would be
interested in any more info to use as a comparison between them.
Applied Reasoning is at 617-492-0700. Usual disclaimers.
chris
------------------------------
Date: Sun 13 Jul 86 18:52:41-EDT
From: Steven M. Kearns <KEARNS@CS.COLUMBIA.EDU>
Subject: Experience with GEM & MS-C
To: info-ibmpc@B.ISI.EDU
My initial impression of GEM, from a programmers view, has been very
discouraging. Many files were damaged upon receipt; I'll have to
wait a week or two to receive technical support; and worst of all,
they do not provide MS-C bindings, so until I get technical support I
cannot compile and run a single program.
Has anyone out in netland used Microsoft C with GEM?
I had originally hoped that GEM would be easier to port a Mac program to
than Windows. I am wrong! I haven't seen Windows yet, but from what I have
heard of it, and what I have seen of GEM, Windows is the graphical
operating system of choice.
-steve
(kearns@columbia-20)
------------------------------
Date: Sun, 13 Jul 86 20:05:29 PLT
To: INFO-IBMPC@USC-ISIB.ARPA
From: 26631853%WSUVM1.BITNET@WISCVM.ARPA
Subject: Re: ASMGEN
To your question on 'what is ASMGEN'.
ASMGEN is a program that reads in another program and dis-assembles it.
ASMGEN has the capability to use another file to spiecify
on how to dissasemble the program. ie. what locations refer to
character strings and what location is code and etc.
I have the program asmgen.exe (or .com) and asmgen.doc but I don't
know on how to get it to the archives from cms on bitnet to arpanet. I
can get it to pc->cms/vm but the rest is the problem. If you guys out
there in net land have learned how to deal w/ this problem let me
know.
Ron D Hutnik
------------------------------
To: info-ibmpc@isib
Subject: Re: ASMGEN
Date: Sun, 13 Jul 86 20:45:11 -0500
From: jcmorris@mitre.ARPA
ASMGEN is a program which can disassemble and/or cross-reference an executable
.EXE or .COM file. It is available on volume 68 of the PC-BLUE archives on
the SIMTEL20 system as ASMGEN.DOC and ASMGEN.CPM.
There is at least one version of ASMGEN which made a brief appearance on
bulletin boards used by professionals, but disappeared when the authors stated
that the code was *NOT* in the public domain. I don't know if the version
in the PC-BLUE files is that version.
I've not used the code and can't comment on its quality.
There have been a few references to ASMGEN here in the Digest, going back at
least to Volume 4, no. 130 (last fall).
Joe Morris (jcmorris@mitre)
------------------------------
To: info-ibmpc@usc-isib.ARPA
Subject: GRAPH Executables Available
Date: Mon, 14 Jul 86 07:39:38 -0500
From: James R. Van Zandt <jrv@mitre-bedford.ARPA>
Pete Galvin has agreed to include executable versions of my programs GRAPH and
SPLINE in his publicly accessable directory <CC.GALVIN.PUBLIC> on ARPANET host
UTEXAS-20. My thanks to Pete, and to Doug Brutlag for suggesting it to him.
- Jim Van Zandt
------------------------------
Date: 14 Jul 86 09:48:00 EDT
From: "CHRISTOPHER E. SHULL" <shull@wharton-10.ARPA>
Subject: PC TeX from Personal TeX, Inc.
To: "info-ibmpc" <info-ibmpc@b.isi.edu>
We have both MicroTeX from Addison Wesley and PC TeX from Personal TeX..
MicroTeX is a fine product, but lacks specific documentation other than
Knuth's "TeXbook". PC TeX does not include the "TeXbook", but has a
complete installation guide, manual with introduction and lessons. PC TeX
also has documentation on AMS-TeX and LaTeX, style files information, and
somewhat faster drivers for Apple LaserWriters and dot-matrix printers.
There is a somewhat dusty (i.e. old) review of the two products in the
April 1986 issue of Byte (Volume 11, number 4, 1986, p. 267).
MicroTeX can be ordered from Addison-Wesley Publishing
One Jacob Way
Reading, MA 01867
(617) 944-3700
for $495.
PCTeX can be ordered from Personal TeX, Inc.
20 Sunnyvale Ave., Suite H
Mill Valley, CA 94941
(415) 388-8853
for $379 (plus options).
Both products are diskspace pigs, requiring 5 MBytes, and barely run in
512K RAM, or barely 640K for LaTeX and/or AMS-TeX (goodbye SideKick). Both
products are also available for substantial educational discounts, and
revolutionary site license agreements are affordable and reasonable.
Disclaimer: I have no interest in either company, except as a customer.
-Chris
Christopher E. Shull
Decision Sciences Department
The Wharton School Shull@Wharton-10.ARPA
University of Pennsylvania
Philadelphia, PA 19104-6366 (215) 898-5930
------------------------------
Date: 14 Jul 86 18:15:48 PDT (Monday)
From: Colvin.PA@Xerox.COM
Subject: Re: 8-Mhz AT, Wait States
To: INFO-IBMPC@USC-ISIB.ARPA
The IBM AT automatically puts in one wait state for memory operations (2
for IO). This "feature" is implemented in hardware on the motherboard.
There is a provision for operating at 0 wait states. There is a line on
the IO Channel that is call (appropriately) 0WS. By pulling this line
low (at the proper time) you can tell the AT that your board can operate
at 0 wait states. It appears that this only works for 16-bit devices.
I have only seen one memory board available commercially that makes use
of this and operates at 0 wait states, I can't remember the name.
Anyway, hope this answers your question.
Craig Colvin (Colvin.pa@Xerox.COM)
------------------------------
From: nike!topaz!harvard!wjh12!maynard!campbell@ucbvax.berkeley.edu
Date: Sun, 13 Jul 86 17:09:05 edt
To: B.ISI.EDU!Info-IBMPC@wjh12.harvard.edu
Subject: DAK BSR X10 Powerhouse Interface
One small contradiction to Joe Newcomer's otherwise accurate review
of the BSR X10 Powerhouse in Info-IBMPC Digest V5 #68. He said that
it looked like the protocol manual was incomplete, and that anyone
trying to actually write software for the thing would probably have
to make a few phone calls to New Jersey. (He also wondered why anyone
would want to write such software since the program shipped with the
box was so good.)
I had to write my own software since I am not using an IBM PC running
MS-DOS, but rather a DEC Rainbow running VENIX. I was able to get my
software working without any calls to New Jersey. Actually there were
a couple of omissions in the manual, but I was able to figure them out
without any trouble. All in all, I think the protocol manual is pretty
good.
Another nifty feature of the BSR box that I think Joe failed to mention
is that it contains a battery backed up clock. Since there isn't a
reasonable way to get a clock into a Rainbow (there are some hacks on
the market at about $125, or more than twice the cost of the BSR box),
I also hacked up a way for my system to query the BSR box at boot time
for the date and time.
All in all, I agree with Joe: the box is nifty and a bargain at $49.90.
Larry Campbell The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
------------------------------
Date: 14 Jul 86 13:41:24 EDT (Mon)
From: Robert Farrell <farrell@YALE.ARPA>
Subject: MIDI Software Query
To: info-ibmpc@USC-ISIB.ARPA
Does anyone out there have any experience with MIDI software?
Does anyone out there have a Yamaha DX7? What kind of price did
you get on your synth? I am especially interested in software that
lets you program voices and MIDI commands and send them to the DX7,
store them on disk, etc.
-- Rob
------------------------------
End of Info-IBMPC Digest
************************
-------