|Line 310||–||Continue until % Files done.|
|Line 320||–||Back to CP/M.|
The above Program would initialize 3 files of 100 records, each of 582 bytes,
on drives A and B, marking each record as free, and filling all fields (except
MK$) with ‘Period’ characters. There are 9 repetitions of 6 different fields
in each record in this example.
e.g CN$(1),CNA$(1)......O$(1),C$(1) up to CN$(9),CNA$(9)......O$(9),C$(9)
Each File will consist of 100 records x 582 bytes = 58,200 bytes or app 58K.
Thus the Three Data files will occupy about one half of each Disk space. It
will sometimes be convenient to try to structure a Data File so that it can be
kept to less than about 40K (assuming 64K RAM). If this can be done then if a
lot of Data processing is going to occur the Data can be RBAD directly into
ARRAYS in RAM for processing, and WRITTEN out to Disk afterwards. Processing
will then be a lot faster, and of course Disk and Drive wear will be
minimized. Another alternative is to use Virtual Disk.
Note that in this example the SAME field variables were used for drives A
and B. Because of this, the two files could not be OPEN and PUT at the same
time, but only one set of ‘LSET’ statements was needed. An alternative method
is to have both files OPEN at the same time. If this is done then the file
number ‘£1’ cannot be used for both files and one would have to be referred to
by another number like ‘£2’. The two sets of FIELD statements would then
have had to use differing Variables, and an additional set of ‘LSET’
statements would also have been needed. A further slight complication is that
extra DIM statements might be necessary, for any extra FIELD variables that
use arrays. (Especially where the program is to be compiled and all Arrays
must be DIM’ed.)
TO SCROLL or NOT TO SCROLL?
When processing Data it is common practice for programmers to use a lot
of PRINT CHR$(26) statements to clear the screen, and then to loop back to
reprint updated Data, or to PRINT a succession of INPUT prompts at the bottom
of the screen. This causes the display to scroll upwards, particularly where
input errors have occured and Error messages and repeat prompts are printed. A
much more effective method is available. The Gemini
card supports a number
of commands that enable the cursor to be repositioned, and the screen to be
cleared from the cursor. If this approach is used, then a much steadier
display is possible. e.g.