RKCP

********************************************************************
***************************** READ.ME ******************************
********************************************************************

Before you start looking at the documentation, I just want to
outline the seven units in this archive.

FSWAP A TP5 unit written in assembly language for very fast swapping
of variables with no "storage space" that is typical of Pascal
swapping procedures. Three routines. Ver. 0.3
FSTACK A TP5 unit written in assembly language for array-based stacks.
Handles only byte and word sizes, but there is NO per item
overhead, and using getmem and freemem you can even arrange
it so there is no overhead anywhere at all! Fourteen routines.
Ver. 0.4
FBIOS Another TP5 unit written in assembly language. This one calls
various BIOS interrupts. Interrupts are called much much faster
from assembly language than the INTR procedure supplied with
TP. Only relativly "safe" routines have been included; I don't
want any disks ruined. Sixteen routines. Ver. 0.1
FWRITE A fourth TP5 unit written in assembler. This one has ultra-high
speed routines to read and write from the screen. It is
supposed to cause snow on "snowy" CGA cards (I haven't tried it
out, however) and it doesn't autodetect EGA or VGA cards. But
you can read characters, lines or whole screens, and write
likewise. You can also redirect the output from the screen to
a predefined type (Vram_ScrBuf), or ANY buffer large enough (4000
bytes for a 80*25 screen). Ninteen routines. Ver. 0.7
FWIN A windowing program in TP5. It uses FWRITE, so it has the same
snow and detection problems as FWRITE. As well as the windowing
routines, there are also some general-purpose procedures and
functions, GetXY being an example. FWIN can leave images or
parts of images on the screen after deleting windows, depending
on how the windows are called. Ten routines. Ver. 0.8
XWIN Another windowing program in TP5. This is basically the same as
FWIN. It doesn't have the leftover image problem that FWIN does,
and it uses less memory per window. It is slower, but that
can't be helped. Eleven routines. Ver. 0.0
FILE1 A TP5 unit for more advanced file routines with error checking.
Uses heap for typing and copying buffer. Buffer adjusts from
1k to 32k depending on the amount of free heap available.
Five routines. Ver. 1.0

That's all of them. I just want to warn of one thing: do NOT use
mark and release when you use either of the windowing programs! You
can release the window memory, which would be disasterous to both the
windows and your program. Also, check the free heap before you call
CreateWindow in either windowing unit. You need roughly 5k free for
one FWIN window and a varying amount for XWIN (but never more than 5k).
If you know you have plenty of space to spare, you don't need to check,
but if you're getting close, it won't hurt and it could save a run-time
error.

Generally, none of the units check that the values passed are in a
valid range. (FILE1 is an exception.)

These units are shareware, but we'll get to that in a moment.

RKCP stands for Rex Kerr's Compiliers and Programs. Currently
I only have programs (or programming aids like these). I'm going to
get started on compilier-writing real soon now. Nothing as advanced
as TP5, I don't think, but some useful compiliers and maybe even
a parser generator for Turbo Pascal.

>>Shareware<<

These units are shareware. You can have as long as you think you
need (within reason [reason is about 2 months {at the most}]) to try
them out. When and if you decide you like them and want to use them,
you will be expected to register them. There is one exception to this.
If you are using *ONLY* FSWAP, you don't have to register. I can't see
why anyone would only want to use just it, but in case you do.... Also,
if any of these units are going to be included in a COMMERCIAL product,
that will cost you one (free) copy of that product. Registration is
$10, which includes all help I can give and the most recent versions
of these seven units. This is probably the final FWIN, but I'll see.
Registration does NOT include a manual.

I have not included any source code with the programs for two reasons.

1) None of the source code is commented yet. If I did include it,
I doubt anyone would be able to understand it.
2) When you register, I will send you all the of the source code
(commented). This way, I can be sure that anyone who is
*REALLY* interested will register.

By the way, if you think these units are worth more than $10, I
certainly have no objections to you sending more.

If you have any ideas about other units or additions to one or
more of these units, or about any ideas for a new compilier or
anything else, don't hesitate to contact me. The best way is
through EasyPlex on CompuServe. If you think your questions or
requests might be of general interest, you can post a message in
the TP5 section of BPROGA's message section (this is also on
CompuServe). If you don't want to do it that way, I suppose you
can always mail a letter to me. My address is

8301 Buckingham Drive
El Cerrito, CA 94530

and my CompuServe ID number is

71550,3147

I will return any mail or messages the same way I got it unless
you specify to do otherwise.

I suggest proceeding in this order:

1) Finish reading this.

2) Run FTPUDEMO for a demonstration of the different programs.

3) Un-arc FDOCS.ARC and read the documentation for the units.

4) Un-arc FTPUS.ARC and start using the units.

5) Do whatever. If you need to review the docs or want to run
the demo again, go ahead. You don't even really have to
follow this order to make sense out of things, but I think
it would help.

The strange thing is, the units take up about 20k altogether. But
the documentation takes up 40k! Gee....

Actually, that's not as bad as it seems. Recently I downloaded a
fast writing file from CompuServe (to take a look at my competition)
and the TPU file was only about 8k. But the documentation was 150k.
Wow! I got pretty board while it was downloading. So after downloading
this 100k file (it was ARCed, of course) I decided that I wouldn't
have the documentation more than three as large as the units. I tried
not to sacrifice any clarity by keeping the files short, and I hope I
have succeded.

Well, now that I have finished my least favorite part of programming
(writing documentation) I can start again on my favorite part (coming
up with good ideas and making them work).


I hope you find at least one of the units useful, and if you do I
hope to hear from you.

<<< Rex Kerr >>>

RKCP