The following documentation by Allan
Kelly is for the Snapshot utility. I
copied the files from BBC-50.
Unfortunately, there seemed to be some
differences between the documentation
and the utilities supplied.
I have attempted to filter out these
differences. One thing that I have done
is to make up a rom image of the
snapshot utility that is ready for use
on a Master.
Master users may *SRLOAD S.MASROM and
do a CTRL+BREAK. The image is then
ready for use. BBC users must first run
the program "S.Palo4'1" and upload it
by *RUN U.UP
I have been unable to test the BBC
version, but Master version seems to
run very well.
Files are all in the S directory.
They are:
BBCmup BBC move up source code.
MasRom Master Snapshot rom image.
Palo4'1 Snapshot source code.
SnapDoc this documentation.
Yup1 This was on the original disc, but
I am unsure what it is! I have left it
on just in case.
Chris Richardson. 22.10.94
Now follows Allan Kelly's
documentation:
Snapshot Documentation Allan Kelly 1986, 1991 The system supports new star
commands. These may be
proceeded with a P to prevent clashes
with any other ROMs
installed. The commands may be in
upper or lower case; e.g.
*RESTORE, *PrestORE and *prestore are
all the same command.
The commands are:
*READY
This will make a copy of OS workspace
in SWR for future use -
the imposter. This command must be
issued before any Snapshot can
be taken. If you try to take a
Snapshot before this command has
been issued you will get the error
message "No Imposter".
*NOW
This will attempt to Snapshot
immediately the command is issued.
*WAIT x
( where x is a hexadecimal number
between 1 and FF )
This will use the 6522 User VIA timer
to time the specified period
of time and then Snapshot memory. Each
extra value of x causes
an increased wait of about 16 seconds.
If you want to take a
Snapshot in a shorter period of time
line 4140 of the assembly
program can be increased to a higher
value. If you try to use
this command without having prepared an
imposter - with *READY -
will cause the "No Imposter" error.
*REPEAT
Once this command has been issued any
Snapshot that is taken
using the timer will cause the timer to
be reset so Snapshots
will be taken at regular intervals as
specified with *WAIT.
There is no need to capture a new
imposter or issue *WAIT again.
This option is useful if you wish to
take a series of update
snapshots while playing a game or
processing data. This option
will stay set until Break is pressed.
( Break stops all
Snapshooting. )
There are a few points about the
program which must be noted.
Firstly, when saving memory to disc
two files names must be
used. The files are called "OLDBOY" and
"POT" one filename is for the memory
above &1400 and the other
one for the memory below &1400.
When RESTOREing the current
drive and directory settings
are used to recover Snapshots.
Another program is needed to "lift" the
main program into SWR.
This is the move up program and should
be assembled to a machine
code file on disc before loading
Snapshot. It will ask you for
the socket number your SWR is located
in - on the B+ 128K SWR
occupies sockets 1,2, 13 and 14. The
program will create a file
called UP on the disc.
Next you should assemble the Snapshot
program - or load a pre
configured on into memory - and then
run *UP to move the program
into SWR. Once this is done press
Break. After this typing
*HELP should produce the message
"Snapshot Version PALO004".
Master users please note that the rom
image S.Masrom is an assembled rom
ready for *SRLOAD
Move up simply switches the SWR into
the current paged ROM
position and moves all the program data
into it. Break must be
pressed so that the OS scans the ROM
bays and see the new 'ROM'.
Alternatively, for those who have an
aversion to pressing break,
the OS keeps a record of which sockets
contain active ROMs in
memory between &2A1 and &2B1 so:
?(&2A1 + [socket number of Snapshot
RAM]) = &82 (for service entry only)
will have the same effect.
( If you use a standard menu system for
loading sideways ROMs as
supplied with various SWR boards you
may like to save the image
in SWR for easier loading. B+ users
may make use of their
*SRSAVE and *SRLOAD commands. )
I have not tried Snapshot on an
Electron but the minimum
requirements for trying are: 16K of
SWR, a disc drive and a 6522
User VIA for timer. On the BBC the
main job of the User VIA is
to drive the printer so the Plus 1
interface should provide one
of these - although I don't know this
for certain. With the B+
the program works as normal, but only
main RAM is captured so
when shadow modes are in use the screen
will not be saved; for
some applications this will not be a
hindrance.
The Master series uses private RAM for
a lot of operations
allowing PAGE to be set to &E00, the
program will therefore need
a large amount of alteration. The same
principals will apply but
more OS workspace will have to be
shifted and more than one bank
of SWR may be needed.
This short program will provide a
simple demonstration of Snapshot.
10 REM Prepare Imposter
20 *READY
30 REM Set timer running
40 *WAIT 1
50 REM Set a BASIC loop running
60 FOR x = 0 TO 2000
70 PRINT x
80 NEXT
90 *RESTORE
100 REM Program will never reach here!
110 END
Sometime during the running of the loop
a Snapshot will be taken.
The loop will then continue running.
When the loop is terminated
the computer will restore the state it
was in while the loop was
running. The loop will terminate again
and the computer will be
restored again......
This will continue until Escape or
break is pressed.
Note that with Snapshot you are not
confined to using the BASIC
programming environment, Snapshots can
be taken from within other
language ROMs and programs.
The Inner workings
------------------
When a program is running there is no
way of guaranteeing that
the operating system's workspace is not
corrupted. Specifically,
if a programmer needs more memory - as
is usually the case with
games - the programmer will say "Ar,
while my program is running the
operating system does not need such big
chunks of RAM, look, I
don't use the discs, therefore I'll
disable the disc system and
use it's memory."
My problem is that I can't snapshot
without the disc drive.
Hence when Snapshot is run an Imposter
is taken. This is a copy
of the Operating workspace when the
system is running normally
with the disc drives working.
When the timer signals an interrupt the
operating system workspace
is copied into SWR - complete with any
corruptions - the imposter
is copied down. Now the disc system is
guaranteed to be working
- well at least 95% guaranteed - so I
can save the bulk of memory
including the screen, that is memory
&1401 to &8000. Next I copy
the operating system workspace which
I've been holding in SWR
down to main memory and save that.
Finally I reverse the process and
restore the machine to it's
original state.
Because this all occurs inside an
interrupt the Operating System
looks after the values of the A, X and
Y registers and program
counter for me, but I have to save the
stack pointer.
The only area I can't save is some of
the write only registers in
Shiela. Unfortunately some of these
control important things like
screen colour. They can be reset from
the OS records but, if a
programmer in an attempt to squeeze
that last ounce of power from
the machine has by passed the OS and
written directly to a write
only register there will be no record.
Hence the screen may be a
different colour when it is restored.