Reflow chapter 7 paragraphs

This commit is contained in:
T. Joseph Carter 2017-07-21 04:56:15 -07:00
parent 1b3552fee7
commit 1315e34995
1 changed files with 58 additions and 125 deletions

183
ch07.txt
View File

@ -1,38 +1,22 @@
# CHAPTER 7 - CUSTOMIZING DOS
Although DOS usually provides most of
the functionality needed by the BASIC
or assembly language programmer, at
times a custom change is required.
Making changes to your copy of DOS
should only be undertaken when
absolutely necessary, since new
versions of DOS are released from
time to time, and the job of moving
several patches to a new version of
DOS every few months can become a
burden. In addition, wholesale
modification of DOS without a clear
understanding of the full
implications of each change can
result in an unreliable system.
Although DOS usually provides most of the functionality needed by the BASIC or
assembly language programmer, at times a custom change is required. Making
changes to your copy of DOS should only be undertaken when absolutely necessary,
since new versions of DOS are released from time to time, and the job of moving
several patches to a new version of DOS every few months can become a burden. In
addition, wholesale modification of DOS without a clear understanding of the
full implications of each change can result in an unreliable system.
SLAVE VS MASTER PATCHING
The usual procedure for making
changes to DOS involves "patching"
the object or machine language code
in DOS. Once a desired change is
identified, a few instructions are
stored over other instructions within
DOS to modify the program. There are
three levels at which changes to DOS
may be applied.
The usual procedure for making changes to DOS involves "patching" the object or
machine language code in DOS. Once a desired change is identified, a few
instructions are stored over other instructions within DOS to modify the
program. There are three levels at which changes to DOS may be applied.
1 - A patch can be made to the DOS
in memory. If this is done, a later
reboot will cause the change to "fall
out" or be removed.
1 - A patch can be made to the DOS in memory. If this is done, a later reboot
will cause the change to "fall out" or be removed.
2 - A patch of the first type can be made permanent by initializing a diskette
while running the patched DOS. This procedure creates a slave diskette with a
@ -41,16 +25,11 @@ newly created diskette is booted the patched version of DOS will be loaded.
Also, any slave diskettes created by that diskette will also contain the patched
version of DOS.
3 - The patch is applied directly to
a master diskette. This is somewhat
more complicated. Either the patch
may be made to the image of DOS on
the first three tracks of a master
diskette using a zap program, or
MASTER CREATE may be used to write
the changed copy of DOS to a new
diskette. The following procedure may
be followed to do this:
3 - The patch is applied directly to a master diskette. This is somewhat more
complicated. Either the patch may be made to the image of DOS on the first three
tracks of a master diskette using a zap program, or MASTER CREATE may be used to
write the changed copy of DOS to a new diskette. The following procedure may be
followed to do this:
BLOAD MASTER CREATE
Get into the monitor (CALL -151)
@ -67,95 +46,54 @@ be followed to do this:
Complete the MASTER CREATE update normally. The
resulting diskette will have the patches applied.
This procedure will work for versions 3.2, 3.2.1, and 3.3 of
DOS.
This procedure will work for versions 3.2, 3.2.1, and 3.3 of DOS.
AVOIDING RELOAD OF LANGUAGE CARD
A rather annoying addition to DOS 3.3
was a patch to the Boot 2 code to
store a binary zero in the first byte
of the Language Card, forcing DOS to
reload BASIC (either INTEGER or
APPLESOFT) for every boot, whether or
not the machine was just powered up.
When the machine is first powered up
this patch is not necessary, since
the first byte of the Language Card
does not appear to DOS to be either
BASIC, and it will reload the card
anyway. On subsequent reboots, more
often than not, a good copy of BASIC
already resides in the Language Card
and this patch results in a LANGUAGE
NOT AVAILABLE error message after
booting a slave diskette. Presumably
the patch was added for version 3.3
to allow for the eventual possibility
that a language like PASCAL whose
first byte of code just happens to
match one of the BASICs would cause
strange results in DOS. If the user
always powers the machine off and on
between using DOS and any other
system, the patch may be removed as
follows.
A rather annoying addition to DOS 3.3 was a patch to the Boot 2 code to store a
binary zero in the first byte of the Language Card, forcing DOS to reload BASIC
(either INTEGER or APPLESOFT) for every boot, whether or not the machine was
just powered up. When the machine is first powered up this patch is not
necessary, since the first byte of the Language Card does not appear to DOS to
be either BASIC, and it will reload the card anyway. On subsequent reboots, more
often than not, a good copy of BASIC already resides in the Language Card and
this patch results in a LANGUAGE NOT AVAILABLE error message after booting a
slave diskette. Presumably the patch was added for version 3.3 to allow for the
eventual possibility that a language like PASCAL whose first byte of code just
happens to match one of the BASICs would cause strange results in DOS. If the
user always powers the machine off and on between using DOS and any other
system, the patch may be removed as follows.
At $BFD3 (48K) is a STA instruction which
stores a zero on the Language Card.
This instruction must be made into
three no-operation instructions:
At $BFD3 (48K) is a STA instruction which stores a zero on the Language Card.
This instruction must be made into three no-operation instructions:
BFD3:EA EA EA
A slave diskette may then be INITed
using this modified version of DOS
and that diskette will have the
patch in its DOS. The address of the
store instruction for a 32K DOS is
7FD3 and for a 16K DOS is 3FD3.
A slave diskette may then be INITed using this modified version of DOS and that
diskette will have the patch in its DOS. The address of the store instruction
for a 32K DOS is 7FD3 and for a 16K DOS is 3FD3.
INSERTING A PROGRAM BETWEEN DOS AND ITS BUFFERS
Once in a while it is useful to find
a "safe" place to load a machine
language program (a printer driver,
perhaps) where BASIC and DOS
can never walk over it, even if DOS
is coldstarted. If the program is
less than 200 bytes long, $300 is a
good choice. For larger programs,
it is usually better to "tuck" the
program in between DOS and its
buffers (assuming the program is
relocatable and will run at that
location). To do this, load the
program into low RAM, copy it to high
RAM right below $9D00 (for a 48K
machine), over the top of DOS's
buffers, change the first buffer
address at $9D00 to point below your
program, (remember to allow 38 extra
bytes for the filename and link fields)
and JMP to $3D3 (DOS
COLDSTART). This will cause DOS to
rebuild its buffers below your
program and "forget" about the memory
your program occupies until the next
time DOS is booted. Of course, BASIC
can not get at that memory either,
since its HIMEM is below the DOS
buffers.
Once in a while it is useful to find a "safe" place to load a machine language
program (a printer driver, perhaps) where BASIC and DOS can never walk over it,
even if DOS is coldstarted. If the program is less than 200 bytes long, $300 is
a good choice. For larger programs, it is usually better to "tuck" the program
in between DOS and its buffers (assuming the program is relocatable and will run
at that location). To do this, load the program into low RAM, copy it to high
RAM right below $9D00 (for a 48K machine), over the top of DOS's buffers, change
the first buffer address at $9D00 to point below your program, (remember to
allow 38 extra bytes for the filename and link fields) and JMP to $3D3 (DOS
COLDSTART). This will cause DOS to rebuild its buffers below your program and
"forget" about the memory your program occupies until the next time DOS is
booted. Of course, BASIC can not get at that memory either, since its HIMEM is
below the DOS buffers.
BRUN OR EXEC THE HELLO FILE
Ordinarily, when DOS finishes booting
into memory, it performs a RUN
command on the HELLO file in its file
name buffer (left there by the INIT
command which wrote DOS to the
diskette). To change the RUN command
to a BRUN or an EXEC, apply the
following patch to DOS (48K):
Ordinarily, when DOS finishes booting into memory, it performs a RUN command on
the HELLO file in its file name buffer (left there by the INIT command which
wrote DOS to the diskette). To change the RUN command to a BRUN or an EXEC,
apply the following patch to DOS (48K):
9E42:34 (for BRUN)
..or..
@ -163,15 +101,10 @@ following patch to DOS (48K):
REMOVING THE PAUSE DURING A LONG CATALOG
Normally, when a CATALOG command is
done on a disk with many files, DOS
will pause every time the screen
fills with names to allow the user
time to see them all.
By pressing any key
the CATALOG continues. If this pause
is undesirable, apply the following
patch to DOS (48K):
Normally, when a CATALOG command is done on a disk with many files, DOS will
pause every time the screen fills with names to allow the user time to see them
all. By pressing any key the CATALOG continues. If this pause is undesirable,
apply the following patch to DOS (48K):
AE34:60