;
;	It should be noted that the following is called "fall thru" coding.
; It is also generally heavily discouraged by the "Establishment", which has
; now firmly locked onto the concepts of "Top down" and "Structured" coding
; techniques.  Not that fall thru coding doesn't have any structure, it just
; doesn't have the established structure.  Please note however that the Intel
; ISIS operating system, which was written in PL/M (a relatively high level
; language at the time), used such established coding techniques (there being
; absolutely no "micro hackers" at the time).  Even with a constant set of
; revisions it still occupies a minimum of 12K and only handles 9 or so open
; files a a time.  This is all in their own MDS system, using DMA and their
; own bus, but is still not reconfigurable by the user (except for minimal
; peripheral device modifications and excluding the disk system, with the small
; amount that can be done utilizing a link in their assembly language Monitor
; program).  And on top of it all, it continues to be as slow as molassis in
; midwinter (a biased but experienced opinion).  CP/M version 1.3 was also
; nearly entirely written utilizing PL/M, but had an assembly language
; "connection", the BIOS thru which users could make it run on almost any 8080
; based system.  CP/M has hardly grown at all in overall size thru its
; evolution to revision 2.2, but instead has retained its "shape" by having
; someone (admittedly probably tediously) piecemeal recode it using assembly
; language, first for the BDOS, and then for the CCP.  It has grown steadily
; in terms of overall functionality over the years, yet hardly varied
; in overall size -- (BDOS + a small BIOS still come in at under 6K of code).
;
;	The point I'm trying to make here is that almost ANYTHING will run fast
; with the very large system resources some researchers enjoy, but that same
; "anything" that works without perceptable difference from "optimized,
; tight-ass coded" programs on a "really big machine", falls flat on its face
; when squeezed into an 8 bit micro.  Fall thru coding (and the rest of the bag
; of tricks gained primarily thru experience) must indeed be done carefully,
; and is not easily mastered by the total novice to programming, nor would I
; expect it to be -- but by utilizing "standard" libraries of such code which
; has undergone extensive testing and experience has shown to be nearly bug
; free, it is possible to construct systems that are powerful, small and also
; inexpensive.  The 8 bit micros we now have come up a long way from their
; first showing, and what was originally designed and promoted as "only a smart
; controller chip" has far surpassed the expectations of their originators.
;
;	Here I include some of the simpler examples of "how it was done", a
; small part of its evolution into what is becoming a mainstay in our economy,
; and why these little machines will still retain these coding techniques and
; their overall power even in the face of ever stronger pressure to ban their
; continued developement.  This argument may all become a moot point as the
; 16 and 32 bit micros come into play, but I've already seen signs that they
; too are subjuct significant "absolute" restrictions, and when that happens
; there begins again the very strong pressure to make what you have work
; better by adopting some unorthodox coding techniques.
;
;	And here's the clincher -- code written in assembly language and its
; near kindred (FORTH, LISP or APL) runs generally at least twice as fast as
; the nearest high level language, and typically in as little as 1/4 the
; space required by something like BASIC, PL/I, ALGOL, COBOL, and even more
; modern languages like PASCAL.  My only real gripe about assembly language
; programming (and even more so for its near kindred) is that to maintain and
; understand any of them requires EXTENSIVE AND CONTINUOUS DOCUMENTATION, and
; the bulk of others (I won't even call them programmers) using any of these
; "gut level" languages that I know of can't understand a package they wrote
; only six months ago -- due (I'm convinced) entirely because they failed
; to document them properly.  In the same light, all of these languages lend
; themselves easily to truely obscure "tricks", which left undocumented are
; totally unmaintainable, especially in relation to modern requirements for
; software with long "shelf lives".   But even with the best of high level
; languages, Somebody has to do the translation back down into machine code,
; either at the assembly language or (worse yet) microcode levels.  And for
; those of you who are consistant "industry watchers", how long ago was it
; that all these great new 16 and 32 bit micros were supposed to be available,
; and how many of them (particularly with large fancy instruction sets, the
; bulk of which is used only once in a blue moon) STILL have bugs in them.
;
;	Yes, I know that I ramble on quite a bit, but the point I'm hoping to
; make is that for something to work reliably it MUST  1: Be relatively simple
; in itself or at least be able to exhibit the characteristics of "simplicity"
; at each level of its operation,  2: Must be completely understood at each
; of these levels (or at least nearly so, given the rate at which new concepts
; are introduced and implemented), and  3: Each level of the total system must
; be well and consistantly documented and the documention maintained throughout
; the entire life cycle of both the hardware and software of the machine.  AN
; UNDOCUMENTED OR POORLY DOCUMENTED PIECE OF EITHER IS WORTHLESS; actually they
; tend to be worse than useless in that some kind of temporary dependence on
; marginally operating equipment is fostered, and when a key individual or
; part becomes unavailable, its cold turkey time.
;
;	So much for "excusing" myself for using code that has worked flawlessly
; for nearly six years, I can't help it -- its in my library, it works, and its
; the best documented stuff I've come across.  Your welcome to add it to any
; library you have, particularly because the bulk of the older routines in my
; library have come originally thru the CP/M user's group.  I must admit to
; making a number of changes to them over the years, and that much time has
; added up.  By constantly upgrading in the documentation area, along with a
; few extra "tweaks" (found, by the way, mostly by adding more documentation),
; the original code each year has been made less like I found it and now is
; quite a bit different from those still available on early user group disks.
;
;	Enough is enough.  I hope you got some value out of all this.	aep
;
;===============
; NOTE: this is the highest level of a 4 level fall-thru code structure.  Each
; of the levels may be independently "called", perform its function, and then
; all but the last "primitive" will implicitly return by falling through to
; the next lower level (which performs more and more primitive operations).
; Coding this way has two advantages, speed and space, winning heavily on both
; counts.  You might ask what difference speed makes in this case, as any
; simple analysis will demonstrate that it is heavily I/O bound, and you're
; right -- but this code evolved at a time when a 1K byte EPROM cost just
; under $100, and disks were out of the question for most of us.  RAM was even
; more ridiculous, especially when compared to today's prices.  The thing of
; of interest here is that there is the same "implicit return" point for each
; of the levels, and very little space does quite a bit functionally.  The only
; real problem with coding this way is that it MUST be kept quite simple at
; each logical level, or any coding effeciency gained will be lost to debugging
; time.
;