mirror of
https://github.com/iKarith/beneath-apple-dos.git
synced 2024-12-03 01:51:56 +00:00
Remove trailing nulls, .pp tags
PIEWriter dot codes are case-insensitive, and I've deciphered that .pp is a paragraph break. Replace those with blank lines. The NUL at EOF was escaped, but it can be simply deleted. Did so.
This commit is contained in:
T. Joseph Carter
parent
1d9b739d80
commit
27bcf5f79c
@ -12,7 +12,7 @@
|
||||
.ce
|
||||
CHAPTER 1 - INTRODUCTION
|
||||
.sp 2
|
||||
.pp
|
||||
|
||||
Beneath Apple DOS is intended
|
||||
to serve as a companion to Apple's
|
||||
DOS Manual, providing additional
|
||||
@ -35,7 +35,7 @@ contents of the DOS Manual. Since
|
||||
all chapters presented here may not
|
||||
be of use to each Apple owner, each
|
||||
has been written to stand on its own.
|
||||
.pp
|
||||
|
||||
The information presented here is a
|
||||
result of intensive disassembly and
|
||||
annotation of various versions of DOS
|
||||
@ -53,7 +53,7 @@ presented here, all of the material
|
||||
included in Beneath Apple DOS has
|
||||
been thoroughly researched and
|
||||
tested.
|
||||
.pp
|
||||
|
||||
There were several reasons
|
||||
for writing Beneath Apple DOS:
|
||||
.SP1
|
||||
@ -68,7 +68,7 @@ To allow you to customize DOS to fit your needs.
|
||||
.br
|
||||
To provide complete information on diskette formatting.
|
||||
.br
|
||||
.pp
|
||||
|
||||
When Apple Computer Inc. introduced
|
||||
its Disk Operating System (DOS)
|
||||
version 3 in 1978 to support the
|
||||
@ -95,7 +95,7 @@ where the
|
||||
Disk Operating System
|
||||
Manual leaves off.
|
||||
.bp
|
||||
.pp
|
||||
|
||||
Throughout this manual, discussion
|
||||
centers primarily on DOS version
|
||||
3.3. The reasons for this are that 3.3
|
||||
@ -106,7 +106,7 @@ would imagine. Wherever there is a
|
||||
major difference between the various
|
||||
DOS releases in a given topic, each
|
||||
release will be covered.
|
||||
.pp
|
||||
|
||||
In addition to the DOS dependent
|
||||
information provided, many of the
|
||||
discussions also apply to
|
||||
@ -117,4 +117,3 @@ the track and sector level is, for
|
||||
the most part, the same.
|
||||
.br
|
||||
.nx ch2
|
||||
\x00
|
||||
@ -3,7 +3,7 @@
|
||||
.ce
|
||||
CHAPTER 2 - THE EVOLUTION OF DOS
|
||||
.sp 2
|
||||
.pp
|
||||
|
||||
Since its introduction, Apple DOS has
|
||||
gone through three major versions.
|
||||
All of these versions look
|
||||
@ -22,7 +22,7 @@ fit on a track from 13 to 16.
|
||||
DOS 3 - 29 June 1978
|
||||
.br
|
||||
DOS 3.1 - 20 July 1978
|
||||
.pp
|
||||
|
||||
The first release of DOS was
|
||||
apparently a victim of a rush at
|
||||
Apple to introduce the DISK II. As
|
||||
@ -32,7 +32,7 @@ and the introduction of the AUTOSTART
|
||||
ROM, a new release was needed.
|
||||
.SP1
|
||||
DOS 3.2 - 16 February 1979
|
||||
.pp
|
||||
|
||||
Although DOS 3.2 embodied more
|
||||
changes from its
|
||||
predecessor than any other release of
|
||||
@ -44,37 +44,37 @@ are listed below:
|
||||
.pi-2
|
||||
.in2
|
||||
.ps0
|
||||
.pp
|
||||
|
||||
- NOMON C,I,O is the initial default
|
||||
under DOS 3.2. MON C,I,O was the
|
||||
default under DOS 3.1.
|
||||
.pp
|
||||
|
||||
- Input prompts (>,],*) are echoed
|
||||
when MON O is in effect, not under
|
||||
MON I as was the case under 3.1.
|
||||
.pp
|
||||
|
||||
- When a DOS command was entered from
|
||||
the keyboard, DOS executed it and
|
||||
then passed a blank followed by a
|
||||
carriage return to BASIC under 3.1. Under 3.2
|
||||
only a carriage return is passed.
|
||||
.pp
|
||||
|
||||
- Under 3.2, certain commands may not
|
||||
be entered from the keyboard but may
|
||||
only be used within a BASIC program
|
||||
(READ, WRITE, POSITION, OPEN,
|
||||
APPEND).
|
||||
.pp
|
||||
|
||||
- Under 3.2, when LOADing an APPLESOFT program,
|
||||
DOS automatically
|
||||
converts from APPLESOFT ROM format to
|
||||
APPLESOFT RAM format if the RAM version of
|
||||
BASIC is in use and vice versa.
|
||||
.pp
|
||||
|
||||
- DOS 3.1 could not read lower case
|
||||
characters from a text file; DOS 3.2
|
||||
can.
|
||||
.pp
|
||||
|
||||
.bp
|
||||
- Some DOS commands are allowed to
|
||||
create a new file, others will not.
|
||||
@ -88,30 +88,30 @@ XYZ, and then printed the file not
|
||||
found error message.) Under 3.2, OPEN
|
||||
is allowed to create a file if one
|
||||
does not exist, but LOAD may not.
|
||||
.pp
|
||||
|
||||
- Under 3.1, exiting to the monitor
|
||||
required that the monitor status
|
||||
register location ($48) be set to
|
||||
zero before reentering DOS. Under DOS
|
||||
3.2 this is no longer necessary.
|
||||
.pp
|
||||
|
||||
- The Read/Write-Track/Sector (RWTS)
|
||||
section of DOS disables interrupts
|
||||
while it is executing. Under 3.1,
|
||||
RWTS could be interrupted by a
|
||||
peripheral while writing to a disk,
|
||||
destroying the disk.
|
||||
.pp
|
||||
|
||||
- The default for the B (byte offset) keyword is 0
|
||||
under 3.2.
|
||||
.pp
|
||||
|
||||
- DOS was reassembled for 3.2 causing most of
|
||||
its interesting locations and
|
||||
routines to move slightly. This
|
||||
played havoc with user programs and
|
||||
utilities which had DOS addresses
|
||||
built into them.
|
||||
.pp
|
||||
|
||||
- Additional file types (beyond
|
||||
T, I, A, and B) are defined within
|
||||
DOS 3.2, although no commands yet
|
||||
@ -122,14 +122,14 @@ DOS TOOLKIT for relocatable object
|
||||
module assembler files. At present,
|
||||
no other use is made of these
|
||||
extra file types.
|
||||
.pp
|
||||
|
||||
- Support was added under 3.2 for the
|
||||
AUTOSTART ROM.
|
||||
.pp
|
||||
|
||||
- All files open when a disk full
|
||||
condition occurs are closed by DOS
|
||||
3.2.
|
||||
.pp
|
||||
|
||||
- As with each new release of DOS,
|
||||
several new programs were added to
|
||||
the master diskette for 3.2. Among
|
||||
@ -145,7 +145,7 @@ renamed.
|
||||
.ps1
|
||||
.sp1
|
||||
DOS 3.2.1 - 31 July 1979
|
||||
.PP
|
||||
|
||||
DOS 3.2.1 was essentially a
|
||||
"maintenance release" of DOS 3.2.
|
||||
Minor patches were made to RWTS and
|
||||
@ -155,7 +155,7 @@ done. Additional delays were added
|
||||
following a switch between drives.
|
||||
.bp
|
||||
DOS 3.3 - 25 August 1980
|
||||
.PP
|
||||
|
||||
Introduced in mid 1980 as a
|
||||
hardware/software upgrade from DOS
|
||||
3.2.1, the DOS 3.3 package includes
|
||||
@ -183,7 +183,7 @@ received a few patches:
|
||||
.pi-2
|
||||
.in2
|
||||
.ps0
|
||||
.pp
|
||||
|
||||
- The initial DOS bootstrap loader
|
||||
was moved to $800 under 3.3. It was
|
||||
at $300 under 3.2. In addition, as
|
||||
@ -191,16 +191,16 @@ stored on the diskette (track 0
|
||||
sector 0) it is nibbilized in the
|
||||
same way as all other sectors under
|
||||
3.3.
|
||||
.pp
|
||||
|
||||
- A bug in APPEND which caused it to
|
||||
position improperly if the file was a
|
||||
multiple of 256 bytes long was fixed
|
||||
under 3.3.
|
||||
.pp
|
||||
|
||||
- A VERIFY command is internally
|
||||
executed after every SAVE or BSAVE
|
||||
under 3.3.
|
||||
.pp
|
||||
|
||||
- All 4 bytes are used in the Volume
|
||||
Table Of Contents (VTOC) free sector bit map when
|
||||
keeping track of free sectors. This
|
||||
@ -208,20 +208,20 @@ allows DOS to handle up to 32 sectors
|
||||
per track. Of course, RWTS will only
|
||||
handle 16 sectors due to hardware
|
||||
limitations.
|
||||
.pp
|
||||
|
||||
- If a LANGUAGE CARD is present, DOS
|
||||
stores a zero on it at $E000 during
|
||||
bootstrap to force the HELLO program
|
||||
on the master diskette to reload
|
||||
BASIC.
|
||||
.pp
|
||||
|
||||
- DOS is read into memory from the
|
||||
top down (backwards) under 3.3 rather than the
|
||||
bottom up. Its image is
|
||||
still stored in the same order on the
|
||||
diskette (tracks 0, 1, and 2),
|
||||
however.
|
||||
.pp
|
||||
|
||||
- Additional programs added to the
|
||||
master diskette under 3.3 include
|
||||
FID, a generalized file utility which
|
||||
@ -234,7 +234,7 @@ will boot a 13 sector diskette,
|
||||
and a new COPY program
|
||||
which will also support single drive
|
||||
copies.
|
||||
.pp
|
||||
|
||||
- Under 3.2, speed differences in
|
||||
some drives prevented their use
|
||||
together with the DOS COPY program.
|
||||
@ -246,4 +246,3 @@ applies.
|
||||
.in0
|
||||
.ps1
|
||||
.nx ch3.1
|
||||
\x00
|
||||
@ -3,7 +3,7 @@
|
||||
.ce
|
||||
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
|
||||
.sp 2
|
||||
.pp
|
||||
|
||||
Apple Computer's excellent manual on
|
||||
the Disk Operating System (DOS)
|
||||
provides only very basic information
|
||||
@ -14,7 +14,7 @@ diskette. The first section will
|
||||
contain a brief introduction to the
|
||||
hardware, and may be skipped by those
|
||||
already familiar with the DOS manual.
|
||||
.pp
|
||||
|
||||
For system housekeeping, DOS divides
|
||||
diskettes into tracks and sectors.
|
||||
This is done during the
|
||||
@ -43,7 +43,7 @@ tracks, although they are invisible
|
||||
to the eye on a real diskette.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.1 HERE ***
|
||||
.pp
|
||||
|
||||
It should be pointed out, for the
|
||||
sake of accuracy, that the disk arm
|
||||
can position itself over 70 "phases".
|
||||
@ -67,7 +67,7 @@ two phases from one another. See
|
||||
APPENDIX B for more information on
|
||||
protection schemes.
|
||||
.bp
|
||||
.pp
|
||||
|
||||
A sector is a subdivision of a track.
|
||||
It is the smallest unit of
|
||||
"updatable" data on the diskette.
|
||||
@ -130,14 +130,14 @@ USABLE* BYTES PER DISKETTE
|
||||
* Excludes DOS, VTOC, and CATALOG
|
||||
.bp
|
||||
TRACK FORMATTING
|
||||
.pp
|
||||
|
||||
Up to this point we have broken down
|
||||
the structure of data to the track
|
||||
and sector level. To better
|
||||
understand how
|
||||
data is stored and retrieved, we will
|
||||
start at the bottom and work up.
|
||||
.pp
|
||||
|
||||
As this manual is primarily concerned
|
||||
with software, no attempt will be
|
||||
made to deal with the specifics of
|
||||
@ -150,7 +150,7 @@ hardware converts analog data to
|
||||
digital data but how this is
|
||||
accomplished is beyond the scope of
|
||||
this manual.
|
||||
.pp
|
||||
|
||||
Data is recorded on the diskette
|
||||
using frequency modulation as the
|
||||
recording mode. Each data bit
|
||||
@ -163,7 +163,7 @@ pattern shown represents a binary
|
||||
value of 101.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.2 HERE ***
|
||||
.pp
|
||||
|
||||
As can be seen in Figure 3.3, the
|
||||
clock bits and data bits (if present)
|
||||
are interleaved. The presence of a
|
||||
@ -177,7 +177,7 @@ bit and the leading edge of the next
|
||||
clock bit.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.3 HERE ***
|
||||
.PP
|
||||
|
||||
A byte would consist of eight (8)
|
||||
consecutive bit cells. The most
|
||||
significant bit cell is usually
|
||||
@ -200,7 +200,7 @@ illustrates the relationship of the
|
||||
bits within a byte.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.4 HERE ***
|
||||
.PP
|
||||
|
||||
To graphically show how bits are
|
||||
stored and retrieved, we must take
|
||||
certain liberties. The diagrams are
|
||||
@ -218,7 +218,7 @@ embodies the function of data flow to
|
||||
and from the diskette.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.5 HERE ***
|
||||
.pp
|
||||
|
||||
Figure 3.5 shows the three bits, 101,
|
||||
being read from the diskette data
|
||||
stream into the data latch. Of
|
||||
@ -229,7 +229,7 @@ clock bits. This task is done by the
|
||||
hardware and is shown more for
|
||||
accuracy than for its importance to
|
||||
our discussion.
|
||||
.pp
|
||||
|
||||
Writing data can be depicted in much
|
||||
the same way (see Figure 3.6).
|
||||
The clock bits which
|
||||
@ -250,7 +250,7 @@ Self-sync bytes will be covered in
|
||||
detail shortly.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.6 HERE ***
|
||||
.PP
|
||||
|
||||
A "field" is made up of a group of
|
||||
consecutive
|
||||
bytes. The number of bytes varies,
|
||||
@ -273,7 +273,7 @@ computer time
|
||||
to decode the address field before
|
||||
the corresponding data field can pass
|
||||
beneath the read/write head.
|
||||
.pp
|
||||
|
||||
All gaps are primarily alike in
|
||||
content, consisting of self-sync
|
||||
hexadecimal FF's, and vary only in
|
||||
@ -283,7 +283,7 @@ of a typical track, broken into its
|
||||
major components.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.7 HERE ***
|
||||
.PP
|
||||
|
||||
Self-sync or auto-sync bytes are
|
||||
special bytes that make up the three
|
||||
different types of gaps on a track.
|
||||
@ -325,14 +325,14 @@ have been stripped out and 0's and
|
||||
1's have been used for clarity.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.8 HERE ***
|
||||
.pp
|
||||
|
||||
There is no way from looking at the
|
||||
data to tell what bytes are
|
||||
represented, because we don't know
|
||||
where to start. This is exactly the
|
||||
problem that self-sync bytes
|
||||
overcome.
|
||||
.pp
|
||||
|
||||
A self-sync byte is defined to be a
|
||||
hexadecimal FF with a special
|
||||
difference. It is, in fact, a 10 bit
|
||||
@ -344,7 +344,7 @@ elsewhere on the disk and a self-sync
|
||||
hex FF byte.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.9 HERE ***
|
||||
.pp
|
||||
|
||||
A self-sync is generated by using a
|
||||
40 cycle (micro-second) loop while
|
||||
writing an FF. A bit is written
|
||||
@ -378,7 +378,7 @@ the data unless there is an error on
|
||||
the track.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.10 ***
|
||||
.PP
|
||||
|
||||
We can now discuss the particular
|
||||
portions of a track in detail. The
|
||||
three gaps will be covered first.
|
||||
@ -395,7 +395,7 @@ bytes must be maintained for
|
||||
each gap type (as discussed earlier).
|
||||
The result is fairly uniform gap
|
||||
sizes within each particular track.
|
||||
.pp
|
||||
|
||||
Gap 1 is the first data written to a
|
||||
track during initialization. Its
|
||||
purpose is twofold. The gap
|
||||
@ -422,7 +422,7 @@ as a Gap 3 type for Address Field
|
||||
number 0 (See Figure 3.7 for
|
||||
clarity).
|
||||
.bp
|
||||
.pp
|
||||
|
||||
Gap 2 appears after each Address
|
||||
Field and before each Data Field.
|
||||
Its length varies from five to ten bytes
|
||||
@ -474,7 +474,7 @@ byte. Figure 3.12 illustrates this.
|
||||
*** INSERT FIGURE 3.11 HERE ***
|
||||
.SP1
|
||||
*** INSERT FIGURE 3.12 HERE ***
|
||||
.PP
|
||||
|
||||
Gap 3 appears after each
|
||||
Data Field and before each Address
|
||||
Field. It is longer than Gap 2 and
|
||||
@ -498,7 +498,7 @@ the first part of the gap can be
|
||||
overwritten or damaged. (See Figure
|
||||
3.11 for clarity)
|
||||
.bp
|
||||
.pp
|
||||
|
||||
An examination of the contents of the
|
||||
two types of fields is in order.
|
||||
The Address Field contains
|
||||
@ -516,7 +516,7 @@ detailed illustration is given in
|
||||
Figure 3.13.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.13 HERE ***
|
||||
.PP
|
||||
|
||||
The prologue consists of three bytes
|
||||
which form a unique sequence, found
|
||||
in no other component of the track.
|
||||
@ -552,7 +552,7 @@ that the drive is still in sync with
|
||||
the bytes on the disk. These bytes
|
||||
are probably unnecessary, but do
|
||||
provide a means of double checking.
|
||||
.pp
|
||||
|
||||
The other field type is the Data
|
||||
Field. Much like the Address Field,
|
||||
it consists of a prologue, data,
|
||||
@ -575,4 +575,3 @@ in the Address Field and it serves
|
||||
the same function.
|
||||
.bp
|
||||
.nx ch3.2
|
||||
\x00
|
||||
@ -3,7 +3,7 @@
|
||||
.ce
|
||||
CHAPTER 3 - DISK II HARDWARE AND TRACK FORMATTING
|
||||
.sp 2
|
||||
.pp
|
||||
|
||||
Apple Computer's excellent manual on
|
||||
the Disk Operating System (DOS)
|
||||
provides only very basic information
|
||||
@ -14,7 +14,7 @@ diskette. The first section will
|
||||
contain a brief introduction to the
|
||||
hardware, and may be skipped by those
|
||||
already familiar with the DOS manual.
|
||||
.pp
|
||||
|
||||
For system housekeeping, DOS divides
|
||||
diskettes into tracks and sectors.
|
||||
This is done during the
|
||||
@ -43,7 +43,7 @@ tracks, although they are invisible
|
||||
to the eye on a real diskette.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.1 HERE ***
|
||||
.pp
|
||||
|
||||
It should be pointed out, for the
|
||||
sake of accuracy, that the disk arm
|
||||
can position itself over 70 "phases".
|
||||
@ -67,7 +67,7 @@ two phases from one another. See
|
||||
APPENDIX B for more information on
|
||||
protection schemes.
|
||||
.bp
|
||||
.pp
|
||||
|
||||
A sector is a subdivision of a track.
|
||||
It is the smallest unit of
|
||||
"updatable" data on the diskette.
|
||||
@ -130,14 +130,14 @@ USABLE* BYTES PER DISKETTE
|
||||
* Excludes DOS, VTOC, and CATALOG
|
||||
.bp
|
||||
TRACK FORMATTING
|
||||
.pp
|
||||
|
||||
Up to this point we have broken down
|
||||
the structure of data to the track
|
||||
and sector level. To better
|
||||
understand how
|
||||
data is stored and retrieved, we will
|
||||
start at the bottom and work up.
|
||||
.pp
|
||||
|
||||
As this manual is primarily concerned
|
||||
with software, no attempt will be
|
||||
made to deal with the specifics of
|
||||
@ -150,7 +150,7 @@ hardware converts analog data to
|
||||
digital data but how this is
|
||||
accomplished is beyond the scope of
|
||||
this manual.
|
||||
.pp
|
||||
|
||||
Data is recorded on the diskette
|
||||
using frequency modulation as the
|
||||
recording mode. Each data bit
|
||||
@ -163,7 +163,7 @@ pattern shown represents a binary
|
||||
value of 101.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.2 HERE ***
|
||||
.pp
|
||||
|
||||
As can be seen in Figure 3.3, the
|
||||
clock bits and data bits (if present)
|
||||
are interleaved. The presence of a
|
||||
@ -177,7 +177,7 @@ bit and the leading edge of the next
|
||||
clock bit.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.3 HERE ***
|
||||
.PP
|
||||
|
||||
A byte would consist of eight (8)
|
||||
consecutive bit cells. The most
|
||||
significant bit cell is usually
|
||||
@ -200,7 +200,7 @@ illustrates the relationship of the
|
||||
bits within a byte.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.4 HERE ***
|
||||
.PP
|
||||
|
||||
To graphically show how bits are
|
||||
stored and retrieved, we must take
|
||||
certain liberties. The diagrams are
|
||||
@ -218,7 +218,7 @@ embodies the function of data flow to
|
||||
and from the diskette.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.5 HERE ***
|
||||
.pp
|
||||
|
||||
Figure 3.5 shows the three bits, 101,
|
||||
being read from the diskette data
|
||||
stream into the data latch. Of
|
||||
@ -229,7 +229,7 @@ clock bits. This task is done by the
|
||||
hardware and is shown more for
|
||||
accuracy than for its importance to
|
||||
our discussion.
|
||||
.pp
|
||||
|
||||
Writing data can be depicted in much
|
||||
the same way (see Figure 3.6).
|
||||
The clock bits which
|
||||
@ -250,7 +250,7 @@ Self-sync bytes will be covered in
|
||||
detail shortly.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.6 HERE ***
|
||||
.PP
|
||||
|
||||
A "field" is made up of a group of
|
||||
consecutive
|
||||
bytes. The number of bytes varies,
|
||||
@ -273,7 +273,7 @@ computer time
|
||||
to decode the address field before
|
||||
the corresponding data field can pass
|
||||
beneath the read/write head.
|
||||
.pp
|
||||
|
||||
All gaps are primarily alike in
|
||||
content, consisting of self-sync
|
||||
hexadecimal FF's, and vary only in
|
||||
@ -283,7 +283,7 @@ of a typical track, broken into its
|
||||
major components.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.7 HERE ***
|
||||
.PP
|
||||
|
||||
Self-sync or auto-sync bytes are
|
||||
special bytes that make up the three
|
||||
different types of gaps on a track.
|
||||
@ -325,14 +325,14 @@ have been stripped out and 0's and
|
||||
1's have been used for clarity.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.8 HERE ***
|
||||
.pp
|
||||
|
||||
There is no way from looking at the
|
||||
data to tell what bytes are
|
||||
represented, because we don't know
|
||||
where to start. This is exactly the
|
||||
problem that self-sync bytes
|
||||
overcome.
|
||||
.pp
|
||||
|
||||
A self-sync byte is defined to be a
|
||||
hexadecimal FF with a special
|
||||
difference. It is, in fact, a 10 bit
|
||||
@ -344,7 +344,7 @@ elsewhere on the disk and a self-sync
|
||||
hex FF byte.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.9 HERE ***
|
||||
.pp
|
||||
|
||||
A self-sync is generated by using a
|
||||
40 cycle (micro-second) loop while
|
||||
writing an FF. A bit is written
|
||||
@ -378,7 +378,7 @@ the data unless there is an error on
|
||||
the track.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.10 ***
|
||||
.PP
|
||||
|
||||
We can now discuss the particular
|
||||
portions of a track in detail. The
|
||||
three gaps will be covered first.
|
||||
@ -395,7 +395,7 @@ bytes must be maintained for
|
||||
each gap type (as discussed earlier).
|
||||
The result is fairly uniform gap
|
||||
sizes within each particular track.
|
||||
.pp
|
||||
|
||||
Gap 1 is the first data written to a
|
||||
track during initialization. Its
|
||||
purpose is twofold. The gap
|
||||
@ -422,7 +422,7 @@ as a Gap 3 type for Address Field
|
||||
number 0 (See Figure 3.7 for
|
||||
clarity).
|
||||
.bp
|
||||
.pp
|
||||
|
||||
Gap 2 appears after each Address
|
||||
Field and before each Data Field.
|
||||
Its length varies from five to ten bytes
|
||||
@ -474,7 +474,7 @@ byte. Figure 3.12 illustrates this.
|
||||
*** INSERT FIGURE 3.11 HERE ***
|
||||
.SP1
|
||||
*** INSERT FIGURE 3.12 HERE ***
|
||||
.PP
|
||||
|
||||
Gap 3 appears after each
|
||||
Data Field and before each Address
|
||||
Field. It is longer than Gap 2 and
|
||||
@ -498,7 +498,7 @@ the first part of the gap can be
|
||||
overwritten or damaged. (See Figure
|
||||
3.11 for clarity)
|
||||
.bp
|
||||
.pp
|
||||
|
||||
An examination of the contents of the
|
||||
two types of fields is in order.
|
||||
The Address Field contains
|
||||
@ -516,7 +516,7 @@ detailed illustration is given in
|
||||
Figure 3.13.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.13 HERE ***
|
||||
.PP
|
||||
|
||||
The prologue consists of three bytes
|
||||
which form a unique sequence, found
|
||||
in no other component of the track.
|
||||
@ -552,7 +552,7 @@ that the drive is still in sync with
|
||||
the bytes on the disk. These bytes
|
||||
are probably unnecessary, but do
|
||||
provide a means of double checking.
|
||||
.pp
|
||||
|
||||
The other field type is the Data
|
||||
Field. Much like the Address Field,
|
||||
it consists of a prologue, data,
|
||||
@ -560,4 +560,4 @@ checksum, and an epilogue. (Refer to
|
||||
Figure 3.14) The prologue is
|
||||
different only in the third byte.
|
||||
The bytes are $D5, $AA, and $AD,
|
||||
which again form a
|
||||
which again form a
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.SP2
|
||||
DATA FIELD ENCODING
|
||||
.pp
|
||||
|
||||
Due to Apple's hardware, it is not
|
||||
possible to read all 256 possible
|
||||
byte values from a diskette.
|
||||
@ -22,7 +22,7 @@ This amounts to about 88K of data per
|
||||
diskette, or roughly 72K of space
|
||||
available to the user; typical for 5
|
||||
1/4 single density drives.
|
||||
.pp
|
||||
|
||||
Fortunately, a second technique for
|
||||
writing data to diskette was devised
|
||||
that allows 13
|
||||
@ -39,7 +39,7 @@ track format used by DOS 3 through
|
||||
DOS 3.2.1. The "5 and 3" scheme
|
||||
represented a hefty 33% increase over
|
||||
comparable drives of the day.
|
||||
.pp
|
||||
|
||||
Currently, of course, DOS 3.3
|
||||
features 16 sectors per track and
|
||||
provides a 23% increase in disk
|
||||
@ -52,7 +52,7 @@ was to the logic of the "state
|
||||
machine" in the P6 PROM, now allowing
|
||||
two consecutive zero bits in data
|
||||
bytes.
|
||||
.pp
|
||||
|
||||
These three different encoding
|
||||
techniques
|
||||
will now be covered in some detail.
|
||||
@ -74,7 +74,7 @@ are all set to one to guarantee
|
||||
meeting the two requirements.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.15 HERE ***
|
||||
.PP
|
||||
|
||||
No matter what value the original
|
||||
data data byte has, this technique
|
||||
insures that the high bit is set and
|
||||
@ -90,7 +90,7 @@ the byte containing the even bits.
|
||||
This is illustrated in Figure 3.16.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.16 HERE ***
|
||||
.PP
|
||||
|
||||
It is important that the least
|
||||
significant bit contain a 1 when the
|
||||
odd-bits byte is left shifted. The
|
||||
@ -98,7 +98,7 @@ entire
|
||||
operation is carried out in the
|
||||
RDADR subroutine at $B944 in DOS
|
||||
(48K).
|
||||
.pp
|
||||
|
||||
The major difficulty with the above
|
||||
technique is that it takes up a lot of
|
||||
room on the track. To overcome this
|
||||
@ -126,7 +126,7 @@ An overview is diagrammed in Figure
|
||||
3.17.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.17 HERE ***
|
||||
.PP
|
||||
|
||||
First, the 256 bytes that will make
|
||||
up a sector must be translated to
|
||||
five bit bytes. This is done by the
|
||||
@ -150,7 +150,7 @@ contains three areas, graphically
|
||||
illustrating the name "5 and 3".
|
||||
.bp
|
||||
*** INSERT FIGURE 3.18 HERE ***
|
||||
.PP
|
||||
|
||||
A total of 410 bytes are needed to
|
||||
store the original 256. This can be
|
||||
calculated by finding the total bits
|
||||
@ -166,7 +166,7 @@ involving a one to one look-up in the
|
||||
table given in Figure 3.19.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.19 HERE ***
|
||||
.pp
|
||||
|
||||
The Data Field has a checksum much
|
||||
like the one in the Address Field,
|
||||
used to verify the integrity of the
|
||||
@ -181,7 +181,7 @@ Figure 3.19. This can best be
|
||||
illustrated by Figure 3.20 on the following page.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.20 HERE ***
|
||||
.PP
|
||||
|
||||
The reason for this transformation
|
||||
can be better understood by examining
|
||||
how the information is retrieved from
|
||||
@ -205,7 +205,7 @@ for that point in the series.
|
||||
This process is diagrammed in Figure 3.21.
|
||||
.bp
|
||||
*** INSERT FIGURE 3.21 HERE ***
|
||||
.pp
|
||||
|
||||
The third encoding technique, currently
|
||||
used by DOS 3.3, is similar to the "5
|
||||
and 3". It was made possible by a
|
||||
@ -238,7 +238,7 @@ is done by the prenibble routine
|
||||
results are shown in Figure 3.22.
|
||||
.sp1
|
||||
*** INSERT FIGURE 3.22 (20) HERE ***
|
||||
.PP
|
||||
|
||||
A total of 342 bytes are needed,
|
||||
shown by finding the total number of
|
||||
bits (256 x 8 = 2048) and dividing by
|
||||
@ -255,7 +255,7 @@ of exclusive-ORs, exactly as with the
|
||||
*** INSERT FIGURE 3.23 (21) HERE ***
|
||||
.sp1
|
||||
SECTOR INTERLEAVING
|
||||
.PP
|
||||
|
||||
Sector interleaving is the staggering
|
||||
of sectors on a track to maximize
|
||||
access speed. There is usually a
|
||||
@ -287,7 +287,7 @@ are stored in descending sequential
|
||||
order, no single interleaving scheme
|
||||
works well for both booting and
|
||||
sequentially accessing a file.
|
||||
.pp
|
||||
|
||||
A different approach has been used in
|
||||
DOS 3.3 in an attempt to maximize
|
||||
performance. The interleaving is now
|
||||
@ -309,7 +309,7 @@ problem if RWTS is used for disk
|
||||
access, but would become a
|
||||
consideration if access were made
|
||||
without RWTS.
|
||||
.pp
|
||||
|
||||
To eliminate the access differences
|
||||
between booting and reading files,
|
||||
another change has been made. During
|
||||
@ -319,7 +319,7 @@ order into memory, just as files are
|
||||
accessed. This means one
|
||||
interleaving scheme can minimize disk
|
||||
access time.
|
||||
.pp
|
||||
|
||||
It is interesting to point out that
|
||||
Pascal, Fortran, and CP/M diskettes
|
||||
all use software interleaving also.
|
||||
@ -331,4 +331,3 @@ differences is presented in Figure
|
||||
*** INSERT FIGURE 3.24 (22) HERE ***
|
||||
.br
|
||||
.nxch4
|
||||
\x00
|
||||
@ -2,7 +2,7 @@
|
||||
.np
|
||||
.ce
|
||||
CHAPTER 4 - DISKETTE DATA FORMATS
|
||||
.pp
|
||||
|
||||
As was described in CHAPTER 3, a 16
|
||||
sector diskette consists of 560 data
|
||||
areas of 256 bytes each, called
|
||||
@ -12,7 +12,7 @@ rings or tracks of 16 sectors each.
|
||||
The way DOS allocates these tracks of
|
||||
sectors is the subject of
|
||||
this chapter.
|
||||
.pp
|
||||
|
||||
A file (be it APPLESOFT,
|
||||
INTEGER, BINARY, or TEXT type)
|
||||
consists of one or more sectors
|
||||
@ -42,7 +42,7 @@ DOS uses sectors is given in Figure
|
||||
*** INSERT FIGURE 4.1 ***
|
||||
.sp1
|
||||
DISKETTE SPACE ALLOCATION
|
||||
.pp
|
||||
|
||||
The map in Figure 4.1 shows that the
|
||||
first three tracks of each diskette
|
||||
are always reserved for the bootstrap
|
||||
@ -80,7 +80,7 @@ track is allocated elsewhere on the
|
||||
disk in the manner described above.
|
||||
.bp
|
||||
THE VTOC
|
||||
.pp
|
||||
|
||||
The Volume Table Of Contents is the "anchor" of the
|
||||
entire diskette. On any diskette
|
||||
accessible by any version of DOS, the
|
||||
@ -146,7 +146,7 @@ BIT MAPS OF FREE SECTORS ON A GIVEN TRACK
|
||||
If all sectors are free:
|
||||
|
||||
FFFF0000
|
||||
.pp
|
||||
|
||||
An example of a VTOC sector is given
|
||||
in Figure 4.2. This VTOC corresponds
|
||||
to the map of the diskette given in
|
||||
@ -156,7 +156,7 @@ Figure 4.1.
|
||||
.bp
|
||||
THE CATALOG
|
||||
.ll30
|
||||
.pp
|
||||
|
||||
In order for DOS to find a given
|
||||
file, it must first read the VTOC to
|
||||
find out where the first catalog
|
||||
@ -189,7 +189,7 @@ that there are no more catalog
|
||||
sectors in the chain.
|
||||
.SP1
|
||||
*** INSERT FIGURE 4.3 ***
|
||||
.PP
|
||||
|
||||
In each catalog
|
||||
sector up to seven files may be
|
||||
listed and described. Thus, on a
|
||||
@ -251,7 +251,7 @@ BYTE DESCRIPTION
|
||||
this length giving 1-255 but a full 65,535 may be
|
||||
stored here.
|
||||
.sp
|
||||
.pp
|
||||
|
||||
Figure 4.4 is an example of a typical
|
||||
catalog sector. In this example there
|
||||
are only four files on the entire
|
||||
@ -264,7 +264,7 @@ and contain zeros.
|
||||
*** INSERT FIGURE 4.4 ***
|
||||
.SP1
|
||||
THE TRACK/SECTOR LIST
|
||||
.PP
|
||||
|
||||
Each file has
|
||||
associated with it a "Track/Sector
|
||||
List" sector. This sector contains a
|
||||
@ -309,7 +309,7 @@ BYTE DESCRIPTION
|
||||
0E-0F Track and sector of second data sector or zeros
|
||||
10-FF Up to 120 more Track/Sector pairs
|
||||
.sp1
|
||||
.pp
|
||||
|
||||
A sequential file will end when the first zero T/S List entry
|
||||
is encountered. A random file, however, can have spaces within
|
||||
it which were never allocated and therefore
|
||||
@ -318,7 +318,7 @@ in the T/S List. This distinction is not always handled
|
||||
correctly by DOS. The VERIFY command, for instance, stops when
|
||||
it gets to the first zero T/S List entry and can not be used
|
||||
to verify some random organization text files.
|
||||
.pp
|
||||
|
||||
An example T/S List sector is given in Figure 4.6.
|
||||
The example file (HELLO, from our
|
||||
previous examples) has only one data
|
||||
@ -352,7 +352,7 @@ that the data was broken up into
|
||||
sectors at all.
|
||||
.SP1
|
||||
TEXT FILES
|
||||
.pp
|
||||
|
||||
The TEXT data type is the least
|
||||
complicated
|
||||
file data structure. It consists of
|
||||
@ -393,7 +393,7 @@ file.
|
||||
*** INSERT FIGURE 4.7 ***
|
||||
.bp
|
||||
BINARY FILES
|
||||
.pp
|
||||
|
||||
The structure of a BINARY type file is
|
||||
shown in Figure 4.8. An exact copy of
|
||||
the memory involved is written to the
|
||||
@ -423,7 +423,7 @@ the diskette.
|
||||
*** INSERT FIGURE 4.8 ***
|
||||
.SP1
|
||||
APPLESOFT AND INTEGER FILES
|
||||
.pp
|
||||
|
||||
A BASIC program, be it APPLESOFT or
|
||||
INTEGER, is saved to the diskette in
|
||||
a way that is similar to BSAVE. The
|
||||
@ -457,7 +457,7 @@ BASIC program is given in Figure
|
||||
*** INSERT FIGURES 4.9 AND 4.10 ***
|
||||
.bp
|
||||
OTHER FILE TYPES (S,R,A,B)
|
||||
.pp
|
||||
|
||||
Additional file types have been
|
||||
defined within DOS as can be seen in
|
||||
the file descriptive entry format,
|
||||
@ -485,7 +485,7 @@ about R files he should refer to that
|
||||
documentation.
|
||||
.sp1
|
||||
EMERGENCY REPAIRS
|
||||
.PP
|
||||
|
||||
From time to time the information on
|
||||
a diskette can become damaged or
|
||||
lost. This can create various
|
||||
@ -499,7 +499,7 @@ and a few program tools can allow any
|
||||
reasonably sharp APPLE II user to
|
||||
patch up most errors on his
|
||||
diskettes.
|
||||
.pp
|
||||
|
||||
A first question would be, "how do
|
||||
errors occur". The most common cause
|
||||
of an error is a worn or physically
|
||||
@ -517,7 +517,7 @@ the files on
|
||||
the aged diskette to a brand new one
|
||||
and discards the old one or keeps it
|
||||
as a backup.
|
||||
.pp
|
||||
|
||||
Another cause of damaged diskettes is
|
||||
the practice of hitting the RESET key
|
||||
to abort the execution of a program
|
||||
@ -553,7 +553,7 @@ checksum (see CHAPTER 3) it may be
|
||||
possible to read the bad sector and
|
||||
ignore the error and get most of the
|
||||
data.
|
||||
.pp
|
||||
|
||||
An I/O error usually means that one
|
||||
of two conditions has occured. Either
|
||||
a bad checksum was detected on the
|
||||
@ -571,7 +571,7 @@ to copy all readable sectors from the
|
||||
damaged diskette to another formatted
|
||||
diskette and then reconstruct the
|
||||
lost data there.
|
||||
.pp
|
||||
|
||||
Many commercially available utilities
|
||||
exist which allow the user to
|
||||
read and display the contents of
|
||||
@ -616,7 +616,7 @@ files periodically to simplify
|
||||
recovery. More information on the
|
||||
above procedures is given in APPENDIX
|
||||
A.
|
||||
.pp
|
||||
|
||||
A less significant form of diskette
|
||||
clobber, but very annoying, is the
|
||||
loss of free sectors. Since DOS
|
||||
@ -644,7 +644,7 @@ another diskette (note that FID must
|
||||
be used, not COPY, since COPY copies
|
||||
an image of the diskette, bad VTOC
|
||||
and all).
|
||||
.pp
|
||||
|
||||
If a file is deleted it can usually
|
||||
be recovered, providing that
|
||||
additional sector allocations have
|
||||
@ -661,4 +661,3 @@ and then the original deleted so that
|
||||
the VTOC freespace bit map will
|
||||
be updated.
|
||||
.nx ch5
|
||||
\x00
|
||||
@ -4,7 +4,7 @@
|
||||
CHAPTER 5 - THE STRUCTURE OF DOS
|
||||
.sp 2
|
||||
DOS MEMORY USE
|
||||
.pp
|
||||
|
||||
DOS is an assembly language program
|
||||
which is loaded into RAM memory when
|
||||
the user boots his disk. If the
|
||||
@ -39,7 +39,7 @@ occupied does not exist on a smaller
|
||||
machine.
|
||||
.SP1
|
||||
*** INSERT FIGURE 5.1 ***
|
||||
.pp
|
||||
|
||||
A diagram of DOS's memory for a 48K
|
||||
APPLE II is given in
|
||||
Figure 5.1. As can be seen, there are
|
||||
@ -58,7 +58,7 @@ the file buffers also changes. This
|
||||
affects the placement of HIMEM,
|
||||
moving it up or down with fewer or
|
||||
more buffers respectively.
|
||||
.pp
|
||||
|
||||
The 3.5K
|
||||
above the file buffers is occupied by
|
||||
the main DOS routines. It is here
|
||||
@ -86,7 +86,7 @@ of DOS. This interface is generalized
|
||||
through a group of vectors in page 3
|
||||
of RAM and is documented in the next
|
||||
chapter.
|
||||
.pp
|
||||
|
||||
The last 2.5K of DOS is the
|
||||
Read/Write Track/Sector (RWTS)
|
||||
package. RWTS is the next step lower
|
||||
@ -107,7 +107,7 @@ the next chapter.
|
||||
.ne5
|
||||
THE DOS VECTORS IN PAGE 3
|
||||
.ll30
|
||||
.pp
|
||||
|
||||
In addition to the approximately 10K
|
||||
of RAM occupied by DOS in high
|
||||
memory, DOS maintains a group of what
|
||||
@ -199,7 +199,7 @@ ADDR USAGE
|
||||
a maskable interrupt occurs.
|
||||
.bp
|
||||
WHAT HAPPENS DURING BOOTING
|
||||
.PP
|
||||
|
||||
When an APPLE is powered on its
|
||||
memory is essentially devoid of any
|
||||
programs. In order to get DOS
|
||||
@ -218,7 +218,7 @@ in Figure 5.2 and a description of
|
||||
the bootstrap process follows.
|
||||
.SP1
|
||||
*** INSERT FIGURE 5.2 ***
|
||||
.pp
|
||||
|
||||
The first boot stage (let's call it
|
||||
Boot 0) is the execution of the ROM
|
||||
on the disk controller card. When the
|
||||
@ -242,7 +242,7 @@ $300). Once this sector is read, the
|
||||
first stage boot jumps (GOTO's) $800
|
||||
which is the second stage boot (Boot
|
||||
1).
|
||||
.pp
|
||||
|
||||
Boot 1, also about 256 bytes long,
|
||||
uses part of the Boot 0 ROM as a
|
||||
subroutine and, in a loop, reads the
|
||||
@ -336,7 +336,7 @@ that it will execute properly at its
|
||||
new home. The relocator then jumps to
|
||||
the high memory copy of DOS and the
|
||||
old image is forgotten.
|
||||
.pp
|
||||
|
||||
The DOS boot is completed by the DOS
|
||||
coldstart routine. This code
|
||||
initializes DOS, making space for the
|
||||
@ -363,7 +363,7 @@ form of nibbilization (see chapter 3)
|
||||
than any other sector on the
|
||||
diskette, making its raw appearance
|
||||
in memory at $3600 non-executable.
|
||||
.pp
|
||||
|
||||
The various stages of the bootstrap
|
||||
process will be covered again in greater
|
||||
detail in Chapter 8, DOS PROGRAM
|
||||
@ -372,4 +372,3 @@ LOGIC.
|
||||
*** INSERT FIGURE 5.3 HERE ***
|
||||
.BR
|
||||
.NX CH6.1
|
||||
\x00
|
||||
@ -4,7 +4,7 @@
|
||||
CHAPTER 6 - USING DOS FROM ASSEMBLY LANGUAGE
|
||||
.sp1
|
||||
CAVEAT
|
||||
.PP
|
||||
|
||||
This chapter is aimed at the advanced
|
||||
assembly language programmer who
|
||||
wishes to access the disk without
|
||||
@ -17,7 +17,7 @@ present) of a programmer who has
|
||||
never used assembly language.
|
||||
.sp2
|
||||
DIRECT USE OF DISK DRIVE
|
||||
.PP
|
||||
|
||||
It is often desirable or necessary to
|
||||
access the Apple's disk drives
|
||||
directly from assembly language,
|
||||
@ -78,7 +78,7 @@ generally desirable to write code
|
||||
that is not slot dependent, one would
|
||||
normally use $C08A,X (where the
|
||||
X register contains the value $s0).
|
||||
.pp
|
||||
|
||||
In general, the above addresses need
|
||||
only be accessed with any valid 6502
|
||||
instruction. However, in the case of
|
||||
@ -92,7 +92,7 @@ number 1. (Assume slot number 6)
|
||||
LDA $C0EA
|
||||
BIT $C08A,X (where X-reg contains $60)
|
||||
CMP $C08A,X (where X-reg contains $60)
|
||||
.pp
|
||||
|
||||
Below are typical examples
|
||||
demonstrating the use of the device
|
||||
address assignments. For more
|
||||
@ -101,7 +101,7 @@ assumed and the X-register contains
|
||||
$60.
|
||||
.sp1
|
||||
STEPPER PHASE OFF/ON:
|
||||
.PP
|
||||
|
||||
Basically, each of the four phases
|
||||
(0-3) must be turned on and then off
|
||||
again. Done in ascending order, this
|
||||
@ -169,7 +169,7 @@ NOTE: $C08F,X must already have been
|
||||
accessed to insure Write mode and a
|
||||
100 microsecond delay should be
|
||||
invoked before writing.
|
||||
.pp
|
||||
|
||||
Due to hardware constraints, data
|
||||
bytes must be written in 32 cycle
|
||||
loops. Below is an example for an
|
||||
@ -197,7 +197,7 @@ without an adjustment.
|
||||
RTS (6)
|
||||
.SP2
|
||||
CALLING READ/WRITE TRACK/SECTOR (RWTS)
|
||||
.pp
|
||||
|
||||
Read/Write Track/Sector (RWTS) exists
|
||||
in every version of DOS as a
|
||||
collection of subroutines, occupying
|
||||
@ -206,11 +206,11 @@ program. The interface to RWTS is
|
||||
standardized and thoroughly documented by Apple
|
||||
and may be called by a
|
||||
program running outside of DOS.
|
||||
.pp
|
||||
|
||||
There are two subroutines which must
|
||||
be called or whose function must be
|
||||
performed.
|
||||
.pp
|
||||
|
||||
JSR $3E3 - When this subroutine is
|
||||
called, the Y and A registers are
|
||||
loaded with the address of the
|
||||
@ -227,7 +227,7 @@ to RWTS. Of course, you may set up
|
||||
your own IOB as long as the Y and A
|
||||
registers point to your IOB upon
|
||||
calling RWTS.
|
||||
.pp
|
||||
|
||||
JSR $3D9 - This is the main entry to
|
||||
the RWTS routine. Prior to making
|
||||
this call, the Y and A registers must
|
||||
@ -356,4 +356,3 @@ Output: Byte 0D - Return code (See previous definition)
|
||||
10 - Current Drive number
|
||||
.bp
|
||||
.nx ch6.2
|
||||
\x00
|
||||
@ -1,5 +1,5 @@
|
||||
CALLING THE DOS FILE MANAGER
|
||||
.pp
|
||||
|
||||
The DOS file manager exists in every
|
||||
version of DOS as a collection of
|
||||
subroutines occupying approximately
|
||||
@ -20,7 +20,7 @@ these routines may be relied upon as
|
||||
program
|
||||
uses these routines to process files
|
||||
on the diskette.
|
||||
.pp
|
||||
|
||||
There are
|
||||
two subroutines which must be called
|
||||
in order to access the file manager.
|
||||
@ -289,7 +289,7 @@ Input: Byte 00 - 0C
|
||||
Output: Byte 0A - Return code
|
||||
.bp
|
||||
DOS BUFFERS
|
||||
.pp
|
||||
|
||||
Usually it is desirable to use one of DOS's buffers when
|
||||
calling the file manager to save memory. DOS buffers consist of
|
||||
each of the three buffers used by the file manager (file
|
||||
@ -336,7 +336,7 @@ BYTE DESCRIPTION
|
||||
the chain then this field contains zeros.
|
||||
.bp
|
||||
THE FILE MANAGER WORKAREA
|
||||
.pp
|
||||
|
||||
The file manager workarea contains
|
||||
the variables which, taken together,
|
||||
constitute all of the information the
|
||||
@ -398,13 +398,13 @@ BYTE DESCRIPTION
|
||||
2A/2C Not used
|
||||
.bp
|
||||
COMMON ALGORITHMS
|
||||
.PP
|
||||
|
||||
Given below are several pieces of code
|
||||
which are used when working with DOS:
|
||||
.SP1
|
||||
.ne5
|
||||
LOCATE A FREE DOS BUFFER
|
||||
.PP
|
||||
|
||||
The following subroutine may be used
|
||||
to locate an unallocated DOS buffer
|
||||
for use with the DOS file manager.
|
||||
@ -438,7 +438,7 @@ NBUF SEC INDICATE-NO FREE BUFFERS
|
||||
RTS RETURN TO CALLER
|
||||
.bp
|
||||
IS DOS IN THE MACHINE?
|
||||
.PP
|
||||
|
||||
The following series of instructions
|
||||
should be used prior to attempting to
|
||||
call RWTS or the file manager to
|
||||
@ -452,7 +452,7 @@ machine.
|
||||
.SP2
|
||||
.ne5
|
||||
WHICH VERSION OF DOS IS ACTIVE?
|
||||
.pp
|
||||
|
||||
In case the program has version dependent code, a check of
|
||||
the DOS version may be required:
|
||||
.sp1
|
||||
@ -498,7 +498,7 @@ SETBSC CMP $E000 CORRECT BASIC ALREADY THERE?
|
||||
\x2c\x40\x42\x5b\x33\x03\x61\x9fTS RTS IN ANY CASE, EXIT TO CALLER
|
||||
.bp
|
||||
SEE IF A BASIC PROGRAM IS IN EXECUTION
|
||||
.PP
|
||||
|
||||
To determine if there is a BASIC program running or
|
||||
if BASIC is in immediate command mode, use the following
|
||||
statements:
|
||||
@ -519,4 +519,3 @@ statements:
|
||||
BNE EXEC ELSE, PROGRAM IS EXECUTING
|
||||
.br
|
||||
.nx ch7
|
||||
\x00
|
||||
@ -3,7 +3,7 @@
|
||||
.ce
|
||||
CHAPTER 7 - CUSTOMIZING DOS
|
||||
.sp1
|
||||
.PP
|
||||
|
||||
Although DOS usually provides most of
|
||||
the functionality needed by the BASIC
|
||||
or assembly language programmer, at
|
||||
@ -22,7 +22,7 @@ implications of each change can
|
||||
result in an unreliable system.
|
||||
.sp1
|
||||
SLAVE VS MASTER PATCHING
|
||||
.PP
|
||||
|
||||
The usual procedure for making
|
||||
changes to DOS involves "patching"
|
||||
the object or machine language code
|
||||
@ -78,7 +78,7 @@ DOS.
|
||||
.SP1
|
||||
.ne5
|
||||
AVOIDING RELOAD OF LANGUAGE CARD
|
||||
.PP
|
||||
|
||||
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
|
||||
@ -122,7 +122,7 @@ store instruction for a 32K DOS is
|
||||
7FD3 and for a 16K DOS is 3FD3.
|
||||
.sp1
|
||||
INSERTING A PROGRAM BETWEEN DOS AND ITS BUFFERS
|
||||
.pp
|
||||
|
||||
Once in a while it is useful to find
|
||||
a "safe" place to load a machine
|
||||
language program (a printer driver,
|
||||