Messages sent by Albert Schofield.
Still being Compiled.
ISSUE 33
To: 999 (all members)
From: K3H (Albert Schofield )
Subject: Tape to Disc.
Chris has suggested that I write some
articles on my pet subject which I
will call Tape to Disc on the BBC
Model 'B'
Some of you may have started, like
myself, with just a cassette based
machine and later had a DFS fitted.
Well, let us suppose that you have
just switched your machine on and
can't wait to get your programs on to
disc. So you load your program, which
is an ordinary basic program, from
cassette, type *DISC, and in no time
at all it is on disc. Then you run it.
If it is a fairly short program it
may work perfectly. If it is a fairly
long program then it will probhably
stop with an error message usually BAD
MODE, the mode being bad because there
is not enough memory available.
The reason for this is because the
DFS uses a large slice of memory. On a
cassette based machine page is
normally at &E00. You can check this
by typing PRINT÷PAGE. On a disc based
machine page is much higher usually
&1900.
However, you can claim some of this
memory back. If the program does not
use any file handling commands such as
OPENIN etc. and most games don't, then
you can lower page to &1100.
So type PAGE=&1100 and run your
program again. If it works OK then add
the following line to the beginning of
your program:-
1IF PAGE<>&1100 THEN PAGE=&1100:CHAIN
"PROG"
Put the filename of your program in
place of PROG. Then when you run your
program in future it will
automatically set page to &1100.
But if your program still gives error
messages with page at &1100 then you
will have to download it to &E00.
To do this add the following lines to
the beginning of your program:-
1CLS:VDU23,1,0;0;0;0;:PRINTTAB(8,10)
CHR$(131)"Downloading...."
2*FX3,2
3*KEY0 *TAPE|MD%=PAGE-&E00:FORL%=PAGE
TO TOP STEP4:!(L%-D%)=!L%:NEXT:PAGE=&
E00|MOLD|MDEL.1,5|M*FX3,0|MRUN|M
4*FX138,0,128
5END
The downloader deletes itself. Your
program will then be in memory exactly
as if you had loaded it from cassette.
You can create an ASCII version of
this downloader and save it to disc.
Then with your program in memory the
downloader can be *EXECed on to it and
saved to disc. See page 402 of the
User guide to do this. But first make
sure that the first line of your
program is not numbered less than six.
If it is RENUMBER your program or the
first lines will be overwritten.
That's all for this month. I hope
some of you have found it useful. Next
month I will deal with machine code
programs.
ISSUE 34
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC FOR M/C PROGRAMS
Most games are in several parts, each
part chaining or *RUNning the next. If
a program is chained then it is BASIC.
If it is *RUN or *LOADed it is machine
code.
Let us suppose we have a three part
game on tape. The first two parts are
in BASIC and the last part is machine
code. The first two parts can be just
loaded type *DISC and then saved. If
the file names are more than seven
letters long then they will have to be
shortened to seven letters, the
maximum allowed by the DFS.
To get the M/C program on to disc
type *OPT1,2 (RETURN) then type
*LOAD""1900 (RETURN) to load the M/C
program from tape. When the program is
loaded you will have four sets of
numbers after the filename. Ignore the
first four numbers or letters in each
set. The first set is the number of
blocks and can also be ignored. The
second set is the length of the
program. The third set is the load
address and the forth set is the
execution address. Now type *DISC.
To save the program to disc type
*SAVE"filename"1900+length execution
load
Put the proper filename in and the
three sets of numbers where indicated.
&1900 was used as a temporary address
for loading an saving and is discarded
when the program is saved.
The three parts are now on disc so
chain the first part. You may get an
error message either FILE NOT FOUND or
BAD FILENAME. This means that the
first part CHAINS"". A null string
will not work on the DFS or the first
part is using a filename more than
seven letters long. Alter the first
part to chain the filename of the
second program. The second part may
also need altering.
If the load address of the third part
is &1100 or more, the program may now
run but it will probably be less so it
will have to be downloaded.
The following short relocator will do
this:-
10 *KEY0 *LOAD "filename"1900|M
*TAPE|MFOR T%=0 TO &length STEP 4:
T%!&load =T%!PAGE:NEXT|M
CALL&execution|M
20 *FX138,0,128
30 END
Put the filename, length, load and
execution addresses in where
indicated.
Some DFSs include relocating
utilities. The Watford DFS has the
commands *MRUN and *MLOAD which will
do the relocating. If you have the
BEEBUG DISC MASTER this has an
excellent move down routine which tags
a small machine code on the end of
your program for either machine code
or basic programs.
That's all for this month. Next month
I will deal with the problem of LOCKED
programs.
ISSUE 35
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC ON THE BBC'B'
First I would like to deal with MR.
Gallagher's problem which he is having
with 'MAGIC MUSHROOMS'. It is basically
a tape to disc problem as your disc
version has originated from tape and
has not been fully transferred. Just
over half way through the main file
there are two references to TAPE. Use
a sector editor to change these to
DISC and you will then be able to save
and load screens to disc.
This month I am going to deal with
the problem of LOCKED files on tape.
A LOCKED file on tape can only be
*RUN. It cannot be *LOADed or *DUMPed.
It cannot therefore be transferred to
disc. However there are plenty of
utilities for unlocking files on tape
and locking them again. Once unlocked
they can be transferred to disc in the
usual way and most files work just as
well unlocked as locked.
On the other hand some files when
unlocked will not work and locking
them on disc is of no use as this is
a different method altogether.
So what can be done ? If you have
sideways ram the ROM FILING SYSTEM is
very similar to the CASSETTE FILING
SYSTEM, so the file can be put into a
ROM image, locked once again and will
work from the RFS. A short loader
program can be used to load the ROM
image and *RUN the locked file
something like the following:-
10 *KEY10 *ROM|MPAGE=&E00|M*OPT1,2|M
*RUN filename|M
20 ?&FF34=0:*LOAD filename 8000
30 CALL!-4
The first line programs the break key
to enter the RFS. The OPT command lets
you see the file loading and then the
locked file is *RUN. The second line
selects the rom bank to be used, in
this case bank 4. Alter the 4 for any
other bank. Then the rom image is
loaded from disc. Use the filename you
have chosen. The last line 'presses'
the break key which initialises the
rom image and *RUNs the locked file.
That is one way of doing it. But what
if you do not have SWR. There is
another and better way but not as
simple. The reason the locked file
will not work when unlocked is because
the execution address is a false one
so if you can find the true execution
address then the file will work as
normal without having to be locked.
But how do you find it ? It is not
always easy. It is in the file
somewhere and in reverse order. In
some acornsoft games such as VOLCANO
the true execution address is the last
two HEX numbers on the file in
reverse. In the case of VOLCANO the
last two HEX numbers are A0 and 44,
therefor the true execution address is
&44A0.
Last of all there is another type of
locked file which when unlocked will
not work and when it is locked again
it still will not work so I can only
assume that it is locked originally in
some special way. That is why if this
type of file is backed up with a tape
copier which has unlocking facilities,
the resultant copy will not work. So
with this type of file the SWR method
cannot be used. The only way is to
find the true execution address. With
this type of file there is usually a
short machine code loader which
contains the true execution address.
The file can also be *DUMPED and
various addresses tried but unless you
are an expert in machine code it can
be a long task.
Next month I will be discussing
various tape to disc utilities.
ISSUE 36
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC ON THE BBC'B'
There are many types of tape to disc
utilities, some on disc, some on ROM.
Some are quite good but tend to be
fairly limited. For instance they
cannot cope with games that are loaded
as a continuous stream of data. This
is where the utilities which save the
whole of computer memory come into
their own. The best must be REPLAY as
this will transfer just about
everything but this requires quite a
bit of extra hardware and specially
formatted discs. However there is
another memory saver which only
requires a single bank of SWR and that
is SNAPSHOT which, I beleive is
available from 8-BIT. This is an
excellent tape to disc and disc to
disc utility. It will not cope with
everything but can transfer most. I
originally obtained it from
TELESOFTWARE and consists of three
files. One is a text file with the
instructions. When a program is saved
to disc it is saved as two files. One
is memory from zero to &1400, the
other is memory from &1400 upwards.
The command used to reload the saved
program is *RESTORE. I have found that
the best way to reload from disc is to
save the ROM image. Have this on a
disc with the two memory files. Then
all that is needed is a short loader
program something like the following:-
10*KEY10 *RESTORE|M
20?&FF34=0:*LOAD <FILENAME> 8000
30CALL!-4
This will load in the ROM image and
give the *RESTORE command. If the game
has a page of instructions it can be
saved on to the disc as normal and the
loader program incorporated into it. I
have found that SNAPSHOT can be useful
in another way. Sometimes a decoded
file or a file loaded in as a
continuous stream of data can be
retreived from the two memory files
and used independently of SNAPSHOT.
The ROM image takes up rather a lot of
space on disc but this can be reduced
to &500 and will still work. More next
month.
ISSUE 37
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC ON THE BBC"B"
Sometimes when a game or utility etc.
which may be made up of several parts
has been transferred from tape to disc
and then run, one or two parts may
load and then suddenly the searching
message appears on the screen and the
computer is back in the tape mode. If
the offending part is in basic then
you will have to list it and look for
*T. or *TAPE and eliminate it. Or it
may be *FX140 which is the cause or
even something like:- FOR N%=6 TO &3F:
N%?&200=N%?&D940:NEXT. So a bit of
detective work is required to isolate
and eliminate the guilty section.
Also the lines containing the
statements may have been made
unlistable so you may need to use
*DUMP to find it. In this case you
will have to use a sector editor to
remove it.
But what if the offending part is in
machine code. With this you will have
to *DUMP it and seek out the following
sequence of hex numbers:- A9 8C A2.
8C is the OSBYTE CALL for TAPE (See
page 434 of the user guide) If it is a
long program it can be a lengthy
search. Use a sector editor to
eliminate the 8C. Replace it with a
space (20) then all should be well.
If the next part has to be loaded via
sideways ROM then the 8C could be
changed to 8D and then the computer
will search in the rom filing system.
8D being the OSBYTE CALL for ROM (See
page 165 of the advanced user guide)
I am sorry MR. GALLAGHER (4MD) that
my information regarding MAGIC
MUSHROOMS did not work for you. Your
version of the game must be different
to mine. However, this article should
solve your problem. Let me know how
you get on. As a last resort you could
send me a copy of your version and I
would try to sort it out for you or I
could send you a copy of my version.
And finally thanks ROY (20G) for the
bouquet. More next month.
ISSUE 38
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC ON THE BBC"B"
In a previous article I wrote about
the possibility of false execution
addresses. It is also possible to have
false load addresses. The file
information is usually obtained by the
use of *OPT1,2. The use of *OPT1,2
will obtain the information from the
last block of the file. In some cases
the last block of the file has been
altered to give a false load address.
In fact some files have a different
load address in every block but the
load address in the first block must
be the correct one. To obtain the file
information from the first block,
catalogue the file from cassette and
as soon as the first block appears on
th screen as "PROG 00" (PROG being the
file name) press ESCAPE. Then type:-
PRINT ÷!&3BE <RETURN>. The true load
address will then be shown.
Another way of finding the true load
address of any file would be to load
the file from cassette and then save
it using SNAPSHOT. Then *DUMP the
memory files so obtained to see where
the relevant file starts.
If you find that your transfer of any
files from tape to disc does not work
for no apparent reason it is always
worth while checking the load address
from the first block to see if it is
the same as the one obtained by using
*OPT1,2. More next month.
ISSUE 39
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC ON THE BBC"B"
Most of the newer games for the BBC
micro on cassette are in quite a
number of parts. Some of these games
can be transferred to disc and will
run without alteration at all provided
that all the parts load at no less
than &1100. If the last part loads at
less than &1100 then it can be
downloaded and the game will run
perfectly even though the computer
ends up in the tape mode. But if a
section has to be downloaded before
the last part has been reached then
there is a problem as the DFS can not
be re-entered without corrupting
memory. The way to overcome this is to
put the last parts into a rom image.
They can then be reloaded from the
rom filing system with page below
&1100. A short loader program can be
written to load the rom image or
images and then run the first part of
the game as I described in a previous
article.
In last months article where I dealt
with the problem of machine code
programs that revert to tape I may
possibly have caused some confusion by
the way the article was set out. So,
to recap, the three pairs of hex
numbers to find are A9 8C A2. The 8C
should be replaced with a space (20).
I recently came accross another
method which is used to make a program
revert to tape in OMEGA ORB. This game
is in eight parts and they all load at
&1100 or over so no downloading is
involved. Five of the parts have an
execution address of B80. At this
location there is a tape routine which
causes the problem. This routine is
placed there by the third section
"OMEGA2". This section is the loader
and is really a basic program posing
as machine code. So edit this using a
sector editor. The first statement is
!2944=&A28CA9. You will see that this
contains the three pairs of hex
numbers I mentioned earlier but in
reverse order. Also 2944 is the
decimal equivalent of B80. So again
alter the 8C to 20. Then carry on
shortening the file names to the seven
characters that you have used to save
them to disc. The game should then run
from disc without any problems.
If anyone would like any help
transfering to disc a game or utility
please let me know either through the
8-BIT disc or drop me a line. My
address is 46 FIR St. NELSON. LANCS.
BB9 9RG. More next month.
ISSUE 40
To: 999 (all members)
From: K3H (ALBERT SCHOFIELD)
Subject: TAPE TO DISC ON THE BBC'B'
Transferring files from tape to disc
is usually a simple task. Utilities
exist for doing this and the computer
can be left to get on with the job.
Getting the files to work on disc is
when the problems arise.
However sometimes transferring files
from tape to disc can be a problem if
the file is exceptionally long as in
some adventure games. Even with page
at &1100 the file tends to spill over
onto the screen when loaded, and when
saved to disc may have bits of the DFS
rom in it which means that it will not
work properly.
A way round this problem is to
transfer one block at a time. The
following program will do this.
110 *TAPE
120 IN=OPENUP("")
130 *DISC
140 OUT=OPENOUT("filename")
150 *TAPE
160 REPEAT
170 C=BGET £IN
180 *DISC
190 BPUT £OUT,C
200 *TAPE
210 UNTIL EOF£IN
220 CLOSE£IN
230 *DISC
240 CLOSE£OUT
Enter the filename for the file on
disc at line 140. If the file should
happen to be locked add the following
lines.
10 FOR pass%=0 TO 3 STEP 3
20 P%=&70:[OPT pass%
30 PHP:PHA:TXA:PHA:TYA:PHA
40 LDA &3CA:AND £&FE:STA &3CA
50 LDA £0:STA &3C7
60 PLA:TAY:PLA:TAX:PLA:PLP:RTS
70 ]:NEXT
80 ?&220=&70:?&221=0
90 *FX14,4
The file will be transferred to disc
automatically (providing you have
motor control) with no more than one
block in memory at any time.
With the complete file in disc it
will then be necessary to set the load
and execution addresses of the file to
the correct values. The following
program will do this.
10 OSFILE=&FFDD
20 DIM PARAM 18,NAME 8
30 $NAME="filename"
40 !PARAM=NAME
50 PARAM!2=&<load address>
60 PARAM!6=&<execution address>
70 X%=PARAM MOD 256
80 Y%=PARAM DIV 256
90 A%=2
100 CALL OSFILE
110 A%=3
120 CALL OSFILE
Enter the correct filename at line
30. Enter the correct load address
afte the '&' at line 50. Likewise
enter the correct execution address at
line 60. More next month.