;
; ********** FOOTNOTE #1 **********
;
; ---	A general note about the rewrite of this BIOS.  The initial reason for
; the rewrite was to clarify (ie. comment) some of the original code as well as
; changes and additions that had been made in later releases.  In the process,
; much "deadweight code", or code which never took effect was discovered.
;	Ironically, the bulk of this code came from the examples given by
; the Digital Research blocking/deblocking algorythms found in the standard
; CP/M 2.2 (aka CP/M-80) manuals themselves.  The result you will find here
; does not conform with those outlines, but instead utilizes the fact that the
; largest physical sector permitted is 1024 bytes, the same value as the
; minimum logical block size.  Under these conditions, a disk read or write
; involving blocking/deblocking is triggered according to the physical size
; only, and no accounting of the logical blocking is required.  This technique
; actually will function better, in a more clearly documented manner than the
; "skeletal outline".  The overall result has been a noticable (20-100%) speed
; increase with absolutely no loss of compatibility or functionality as
; specified in the CP/M 2.2 documentation.
;
; ---	ADDITIONAL INFORMATION ABOUT DIFFERENCES IN THE COMPUPRO CBIOS  ---
;
;	1000h is the offset for CompuPro CP/M rev level 2.2J MOVCPM utility,
; but this will vary with the letter version of CP/M that you purchased.
; This BIOS offset was selected to comply with the "J" release, but you must
; move the offset for the "K" release, and others may be different.  Digital
; Research manuals show an offset of 0600h for their nominal 20K BIOS, which
; means that for the "J" version CompuPro system a "MOVCPM 64 *" will actually
; generate a "true" CP/M 61.5K system.  This is no real problem, because the
; CompuPro boot loads a CBIOS of 22 (or with special BOOT, 24) 128 byte
; sectors, which is 2.75 or 3K bytes (length 0B00h or 0C00h), both of which
; are much larger than would be permitted with a "true" 64K system.  CP/M can
; actually be generated by Digital Research to run on any page boundary
; (increments of 256 bytes), but once delivered it can only be "moved" with
; MOVCPM by 1Kbyte amounts.  Far better to have room in the CBIOS for expansion
; than follow Digital Research too literally.  This information is included
; for reference purposes only.						aep
;
; ********* FOOTNOTE #2 **********
;
;	I/O device initialization is performed upon cold boot only, and some
; of the routines for this are located at the end of the BIOS.  The bulk of
; the UARTs, interrupt controllers, timer/counters, etc. are initialized by
; a program called the Initial Program Loader (IPL for short).  This program
; also performs the task of loading the CBIOS and initializing high RAM for
; the 8088 to function.  By inspecting the CP/M file titled "HMFBOOT.ASM", you
; will see some of the reasoning behind placing the initialization routines
; there.  The program has quite a few "absolute location" requirements, and
; this made it easy to assign fixed locations to the important I/O initial
; settings.  You will also see that it is quite easy alter or "poke" additional
; I/O port initialization sequences into the allotted memory area.  If you
; opt to change the source program, be extremely careful not to inadvertantly
; alter the absolute location assignments -- this will nearly always cause
; the program to become non-functional and the system will play dead.
;
;	More on the BIOS -- Since the cold boot routine is utilized only once,
; it is placed at the upper end of RAM.  This permits the RAM used by these
; initialization routines to be "recycled" for use by CP/M as a portion of the
; general workspace.  Since the cold boot routine is executed prior to any
; CP/M BDOS calls, there is no conflict in performing this reclamation.
;
;	For individual logical to physical device assignments (I/O redirection
; performed usually thru the STAT utility), see the individual logical device
; vectors.  These are located between the Warm Boot and Cold Boot routines,
; again to permit them to be overlayed by other routines as needed.  This will
; usually take the form of input/output interrupt driven routines, which are
; generally larger than the normal CBIOS boot track would permit on a cold
; boot.
;
; *********** FOOTNOTE #3 ************
;
;---	As a side note, for those of you who never got a chance to work
; with one of the earliest (and possibly the slowest) operating systems
; implemented on a micro, the expression "CIOPB" used here comes from the Intel
; ISIS software.  It stands for "Command Input/Output Parameter Block", which
; itself is a derivative of the method used by the larger mainframes for
; communicating with their I/O channel controllers.
;	Since all of the versions of the CP/M operating system thru at least
; version 2.0 were developed using Intel MDS systems, ISIS and PL/M initially,
; there are many artifacts in CP/M that reflect that evolutionary process.
; The most obvious holdover from the MDS system is the IOBYTE, which is
; implemented in CP/M in exactly the same manner defined by the MDS monitor.
; (In the very early days of micros, there were no operating systems--just
; "monitor" programs that provided the barest necessities for making the thing
; behave vaguely like a computer).  The choice of retaining the flavor of
; the older Intel disk controllers by naming the variable here "CIOPB" came
; originally from work done at SORCIM, but I thought you might be interested
; in some of its related history.					aep
;
; ************* FOOTNOTE #4 ************
;
;	The following routine is a quick way to effectively implement the
; ETX/ACK software transmission protocol utilized in printers with "Diablo"
; type control sequences.  It takes advantage of the fact that every line
; of text transmitted to the printer will eventually be followed by a line
; feed character, or an ESCAPE sequence which has a line feed as its
; terminating character.  This is used instead of counting characters to
; determine when the buffer is full because the "last" character of the count
; may be the first or second of an "ESCAPE" control sequence.  The transmission
; of the ETX character at that time is usually interpreted as a valid "value"
; in the escape sequence, and not be recognized as an "end of transmission"
; as intended.
;	Since even at 1200 baud the printer is "using" characters from it's
; storage buffer at a fast enough rate (especially with word processing
; ESCAPE sequences stuck in the text stream,) that usually nearly twice the
; number of characters that the printer buffer can hold can be transmitted
; before the protocol is activated.  This scheme works particularly well in
; that it insures that the ETX character is never transmitted in the middle
; of a control sequence, but often enough to not overflow the printer buffer.
;
; ---	As a final note, DON'T USE THIS PROTOCOL UNLESS YOU ABSOLUTELY MUST.
; It is subject to a number of flaws generally, and a full blown software
; driver for this protocol is both a great memory consumer and it is quite
; difficult to develope a driver that absolutely, positively, under all the
; unusual conditions that may exist, does not either get "hung up" in a
; wait loop or overflow the printer's buffer.  Either the XON/XOFF protocol
; (in software) or the "REVERSE CHANNEL" or "DTR" (Data Terminal Ready)
; hardware handshaking is far more reliable, faster, and easier to implement.
;
; 	The hardware handshaking is usually found on either pin 19 or 20 of
; the printer EIA RS-232C connector, and is cross connected in the cable
; to the "Clear to Send" (CTS, usually pin 4 on the connector input to the
; computer).  The hardware protocol usually gives the most satisfactory
; results in that it tends to be independent of any changes in the operating
; software.
;
;--------------- end of footnotes -------------