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 ************************ -------