Hi.

"Should I be reading this?"

This document describes "M7:Release Edition", as distrubted
from my webpages (typically as "m7rs.zip"), in source form,
as C code, compilable under DJGPP 2.03 and (with a few makefile
changes which are on you to make) under Linux, with Allegro
WIP (the version I used was downloaded around the start of
Feb.,2000).

If you have no idea what the above paragraph means, then 
you fall outside of the target audience by a considerable
margin. Indeed, you are of phlebian class, go away. 

Seriously speaking, this is a specially unprepared release
of a subset of a snapshot of the M7 project by Keinall
"Granitor" Caddle. (<"http://www.geocities.com/granitor">).

This is not a well prepared release, although I have put
some effort and considerable time into making this file plesant,
the same is not at all true for the other files. By no means is
M7:r a high quality release. This would never be released
with any sense of pride in the codebase, as this codebase possibly
represnts the worse code I have ever written.

"What is it, then?"

This "M7:Release Edition" is a trimmed down, mutilated 
subset of M7. 

It lacks the tokenisation routines,
the numeric variable routines, the "Print EX" routines,
the original CAS file handling routines, the MACAS parser,
and, moreover, there is no DMP. 

The less than stellar
rendering engine was severely mutilated, and although it is still
really pathetic, most of the unused stuff was removed. Some of the
stuff used in the vtest releases was removed from the rendering
engine, which is really sad because the .sp2 sprite support was
really kool, at least, in concept.

However, you could build useful stuff on top of IDEX.

Especially if you are in a hurry to get something on the screen.

"How does this stuff fit together?"

Below is a pretend block diagram,
pretend that [1.] is the top block and [5.] is the
bottom block. [4.] is divided into two blocks, at
the same level, but side by side rather than atop each
other. Draw an arrow from [2.] to [4b.] and sit [1] on
top of [2]. Now you should have the idea... if my
instructions are unclear, then you may wait for me to
do a graphical diagram of this... you wait might just be
infinite, however.

--:begin block diagram;

1. The Magnificent DRIVER (the part you would build)
e.g. "dr.c" ; This is the driver. It contains main();

2. IDE-X : A catchy make for "idex.c";

This is the library which immulates 
the Full Screen Editor of the C64.
API: "idelib.h"
This "sits on top of" [3.] SMELL and [4b.] LOWIDE

3. SMELL : A not-so-catchy make for "screen.c"; 

The Screen Matrix Emulation Layer Library.
This does what it says, and pretends to be a 
cute little text matrix. 
API: "screen.h"
This sits directly and solely on top of [4a.] REND-X

4a. REND-X : The Render Library, generation X.

Implemented in "rend2x.c", using two APIs:
- "lowide.h" ; these routines initalise and de-initalise
the library (and, implicitly, Allegro); also here are
routines to set various runtime flags such as rendering
speedups
- "rend2x.h" ; this is the main set of API calls for 
rendering stuff. 

4b. LOWIDE.
- "lowide.h" ; The REND-X low level routines, described
above in the breakdown of REND-X.

5. Allegro : #include "allegro.h" 
-the venerable Allegro library (not at all my work!)

The Allegro routines are an extension to DJGPP, they are
good but PCish. Hence I wrote the rest of stuff to present
a more C64ish environment. I succeded partially, we could
imm a BASIC Full Screen Editor now. However, I may have
misplaced some sanity in the process, and the code is very
ugly overall. Hence, I'm throwing it away to start fresh,
which is expected anyhow... this is a prototype, after all.

--:end block diagram;

Now, if you look at "dr.c", you're realise that it is trivial to
develop your own Full Screen Editor/IDE thingy, such as a full
C64 BASIC imm.

Okay, so maybe not trivial, but it is a lot easier than starting
from scratch. 

"Huh?"

To put it another way, study "dr.c" and "idelib.h", and make
calls to "idelib.h" to do anything with the screen. This is the
path to good use of the M7 codebase.

"Take my code, please!"

You are free to do as you wish with the source code here,
once you realise that I won't accept responsibility for what you
do with it. Once you copy my code off of my system, you are
making it part of a foreign environment. It may break. It may
be broken. I would not know, and really, it is not intrinsically
my concern.

"What do you mean, it may be broken?"

No great effort has been made to ensure that this codebase is
consistent, solid, or bug-free. It represents a variety of different
styles of coding, none of which approach excellence in my estimation.

There is probally a large mass of unused code, as well as obvious
inefficiencies in a lot of things, maybe in everything. This does not
bother me because I intended to "throw away" this codebase anyhow,
so in a great sense this codebase is trash.

"Why release it, then?"

Why not? I released m1, vtest, and so on... and in fact I have found
that some features of old releases were much more fun than 
the features
in new releases. This is part of the decline that came from attempting
to hak a broken (by design) codebase... so, by releasing this, I can
put it asside and start fresh on something else.

Besides, it might amuse you. Really, parts of the code are downright
hilarious.

"Webpage?"

    http://www.geocities.com/granitor

is my alledgedly programming-related homepage. You should know that,
you probally got this file from there. 

"What's next?"

Officially (um, yeah, like anything about a hobbyist project is
official) speaking, I am taking a vacation from M7, my next project
may well be a better implementation of M7 (including the extra stuff
that was in DMX, and the cool stuff that was in rendlib1/vtest r1,
and the cool stuff that I never put in, but had in mind...),
or it may be something totally different. Currently
I am shifting focus a lot, partially because of task concurence,
and partially due to new interests, e.g. I am finding C++ has merits
that may make it more suited for expressing the C99 project. 

So, I have no idea what I will do next, and I am tremendously happy
with this. You should be too (smile with me! have Joy with me!),
and if you are not, well, that remains your concern. 

"To be enhanced..."

They are many other things I would like to do and say (type?), perhaps
I will do some of them before I "M7:r" goes out the door. If not, 
well, that's okay, I guess.

"Glossary"

DMP
    Direct Mode Parser, featured in the "DMX" releases, but not
    in this release.

M7:r
    Militant codebase, conceptual progression 7, Release Edition.
    In other words, this release.

FSE
    Full Screen Editor. This was a Commodore innovation, at the time,
    but is now immitated by Microsoft's QBasic Editor (and edit.com).

MACAS
    Mainstream Constricted NASIC. A very limited "sub-language" used
    to write scripts for testing earlier interations of M, and M7,
    and featured in DMX (but not in this release). Based on the
    "testin.txt" file in m1. (see webpage for m1 stuff).

M1
    Militant One, the initial release of the M series of proof of
    concepts. Each M has been a test of a different set of concepts,
    research projects which preceed C99.

C99
    A project to immulate the koolness and fun of a the Commodore 64,
    initiated by Sam "Chip" Steele and Keinall "Granitor" Caddle in
    1999 A.D. This has produced several different codebases, 
	running on
    everything from 8088-2 based machines to AMD K6-2's, however,
    the inital goal has not yet been reached. 
	Although direct development
    on C99 has not been very active recently, neither I nor Sam have
    given up on this project...
	
hak
	A term used by Granitor to describe any modification made in a 
	decisive manner; such manners include but are not limited to 
	militant vigor and zen-like singularity of purpose, as well as
	"brute force" modifications which lack elegance.

hoc
	Short for "ad hoc", a modification made to change the workings of 
	one program which had been designed (either explicitly or, through
	haphazard implementation, implicitly) to embody a different work
	ethic. 

---]

"Greetz!"

Thanks to irc:doot.fdf.net/#kode for all of your support, esp. 
Master Chip, who worked on parallel C99 projects, esp. back in the 
high activity days circa m1. Hails also to Sir Nelish Batel, who 
advocated simplicity of code (and shunning of C++). And, of course,
our resident female, the beautifully talented "CC", who is not a
C Compiler (similarly, Chip is not an edible food product). 

Greetings also to "dopey", part-time visitor to #kode, and official
pornstar for all things doot. I would complain about her descriptions
of me, and indeed, the Koders Three, being compressed and shortened
ad absurdum, but (a) I do not know latin, (b) I have nearly 0 mention
of any of my friends, family, or associated on my web pages (c) she
is really scary, and so I feel it best not to piss her off.. besides,
she smells better pissed on.

"More Greetings!"

They are many more people that I could greet, but I do not fathom
that non-#kode people would be the least bit interested in this,
so, if you are my friend, associate, acquaintance, or a stranger
who gave me directions to the nearest ATM, then feel greeted, even
if I have not here greeted you explicitly. The only reason you are
not explicitly greeted is that I do not fathom you would ever read this. 

"Adieu."

Love, Kode, and Rice. 
---Kei~n~all,
a.k.a. Lord Granitor
Feb. 21, 2000.
A bizarre Monday Night. 
Feb. 22, 2000.
A peaceful Tuesday Noonishtime.
Feb. 27, 2000.
A resounding Sunday afternoon.

