By C.J.Richardson. This program will archive up to 50
filenames into one. Especially useful
for DFS users. DFS has a filename
limit.
The program will allow you to add files
to the archive at a later date. You
cannot delete files from the archive
(the program could be adapted to do
so).
The program allows you to de-archive
all files or just one and then run it.
You may view the files in the archive.
You may also use * commands.
To use the program:
CHAIN"Arch`de"
The main menu offers you 3 options and
a * command facility:
Option 1. Archive Files.
Choosing this option takes you to a
sub-menu with 2 further options. The
first of which is to start a new
archive, the second to continue
building an existing archive. Both
options start by asking which archive
you want to begin/add to. You then
enter the name/s of the file/s to
archive. Finish by pressing RETURN.
Option 2. De-Archive Files. When you choose this option you are
first asked which archive you want to
split. Enter the filename of the
archive you wish to split. You are then
presented with the available archived
files in that archive. You may now
choose option 1 to de-archive all of
the files or option 2 to de-archive
just one of the files.
If you choose to de-archive just one
file, when de-archiving is complete,
you will be given the option to CHAIN
or *RUN the de-archived file or to
continue in the archiver/de-archiver.
If you use a twin drive, you have no
need to copy archived files to the
blank disc first. Make the drive with
the blank disc the current drive with
*DR. <num>. Then when prompted for the
source file, enter the full pathname
including the drive number.
For example. The archived file View is
in drive 2. The blank disc is in drive
1. Load the de-archiver. Type *DRIVE 1.
Type RUN. Enter 2 to de-archive.
Enter :2.View. Enter 1. The file will
be de-archived directly from drive 2 to
drive 1.
Option 3. View Archived Files. Choosing this option allows you to see
what files are in an archive. Enter
the name of the archive.
* Command. Type * followed by any * command to
change drives etc. Remember that some *
commands corrupt memory and will
overwrite the program.
Do not enter file names longer than 10
characters. This will not allow full
pathnames in ADFS, but as ADFS uses a
directory structure, there is no need
to archive files for ADFS.
This program will probably feature on
future 8BS issues as it enables single
programs to be easily fished out of a
large archive. As a lot of the programs
submitted to 8BS are short and sweet,
this will no longer pose a problem for
DFS users.
To: 999 (all members)
From: K6N (Brian Raw)
Subject: Pattern V.2
The main reason for using higher level
languages is to utilise their
arithmetic functions but at the
expense of usable memory and
portability if using a rom.
After messing with C and Forth, I have
come to the conclusion I would be
better off sticking to machine code.
Until now I have avoided arithmetic in
machine code, usually dropping back
into Basic as necessary.
Pattern which you may have seen in
issue 39 seemed a suitable first
exercise. In addition to the usual
arithmetic it uses the SIN function.
The standard method for these is to
use a lookup table, which even if used
in a Basic program will double its
speed.
The "integer" table in Basic would be
of values 0 to 10,000, that is
SIN(x)*10,000 which can later be
divided down to a more suitable level.
A table for machine code however would
be easier to deal with if the values
were rotated several times to make
them larger i.e. 2^13 = 8192, so I have
used a table 0 to 8192 or SIN(x)*2^13.
So all the maths are using integer
values simplifying the routines.
I altered the action part of the
program to allow a pause toggle on the
spacebar and (D) screen dump to disc if
required, (S) also toggles the display
of current values. <copy> by poking
a different rotate value alters the
size of the pattern.
On my humble beeb this has speeded
things up by a factor of six approx.
Some of the more complex patterns took
about 40 secs. With the original
program the coding brought this down
to around 7 secs, and will no doubt
be even faster on the Master.
To: 999 (all members)
From: K6N (Brian Raw)
Subject: Resistor codes
Here is the finished version of the
program in issue 44 which now converts
both ways.
The program itself warrants little
explanation, if you don't already know
colour codes then you should have a
good idea of them after messing with
this for ten minutes. The preferred
values table may be unclear, these
are the values that the manufacturers
stick to, so subsequently the only ones
you can get.
The worst tolerance [20%] use [X]
values only, next best (10%) include
both [X] and (X) values,so then 5% are
all the values.
Electronics is not a precise subject.
Small-C version
***************
This is my first program in C and so
probably my worst as well. However from
what I have read I seem to have written
a fair program without using what is
purported to be C's greatest asset,
that is pointers. I did use a
variable called ptr to point into a
string in much the same way as you
would use it in MID$.
An aforementioned pointer would be
named *ptr but is in fact an absolute
address pointing to a string.
Both programs limit what can be input
at the keyboard in different ways
which is more important in C since the
final code is in machine code, naff
input may hang the system.
The first program preprimes the string
valid which the function chkin() then
uses to compare with the character it
is given from the keyboard, this is
more useful if the allowed data is not
sequential.
The second program passes the upper
and lower limit of sequential data as
parameters to the input function.
C treats strings as integer arrays!
this causes all sorts of problems, not
least that the first character
position is 0 as opposed to 1 in BASIC
To demonstrate this, in an earlier
version I used the same string as in
BASIC "0123456789" for use with the
function instr(), checking for "0"
returns 0 (false) which is incorrect
so then adding a space to the string
" 0123456789" doing the same
check now returns 1 (BROWN) all the
colours will be wrong by 1, this then
is the reason for the alterations "+1"
and "--ok" remarked in the source.
I got a lot of variable declaration
errors while writing this so here are
some general rules.
1. Any variable, string or integer
manipulated by more than one
function is best declared global.
2. local variables may be passed as
arguments to another function only
from within the declaring function,
but must also be immediately
redeclared in the new function.
ie this will cause an error
newfunc(x,y)
int z; /* new local variable */
intx,y;
this will not
newfunc(x,y)
intx,y;
intz; /* new local variable */
Has anybody noticed that the BASIC
version runs faster than the C.
This is not the usual case when you
convert to machine code.
Take a look at the size of the file.
From: 3PM (dp-j)
Subject: !Fred vers.Q7a
This is a demo of !Fred text file
reader running a teletext file written
on the Master EDIT facility.
It is like a computerised text book.
Read text, RUN a demo program copied
from the text (or loaded from disk)
and return to text. It does not matter
if the program being copied crosses a
screen boundary. Copy the Basic lines
available, return to text, scroll on,
copy the rest and RUN it.
The text file is just a pot pourri of
thoughts on shedding light.
A bit of a con really. Just a text
file instantly CALLable from Basic but
with lateral thinking it's a RUNable
text book. However, it's ideal for use
as a what-if teaching system.
PRESS SPACE