Flash Datapaks on the Organiser represent a substantial
improvement in storage technology.  There are four major

      - significantly less power used when writing,

      - non-volatile,

      - can be formatted in place,

      - bigger than available EPROMs.

This document explains the technical details that enable
this new technology to be implemented.


Flash Datapaks consist of either one or two Flash chips on
a board with associated regulator, counters and logic.  All
circuitry is CMOS so reading requires very little power.


Flash Datapaks are paged and segmented.  Segments control
address lines A14 to A18 (16K byte blocks) and pages
control lines A8 to A13 (256 byte blocks).  So to get to
the last byte requires the segment to be set, 63 toggles of
the page and 255 toggles of the address.  This will take in
the order of 1 millisecond.

All Organiser models can read data from Flash Datapaks
except CMs which are not able to recognise segmented packs.


Writing is done in a completely different way to EPROMs and
a special software driver must be present.  If the Flash
driver is not present and a write is attempted a "READ ONLY
PACK" error is reported.

It is impossible to quantify the power saving compared to
EPROMs.  It depends primarily on the length of the data
being written.  The longer the data the greater the saving.
As a generalisation a user can expect an order of magnitude
improvement though 2 orders is quite possible.


Flash Datapaks can be formatted in place.  To do this each
byte must be written to zero and then for the one or two
chips present they must commanded to erase back to FF.
When doing this each byte must be checked to ensure that is
has been erased properly.  If not it tries another erase
until either all bytes are FF or the chip is judged to have

In Flash driver Version 1.3 and greater packs can be
formatted by calling the OPL procedure FLSHFORM:("B",0)
where the first parameter is the slot (B or C) and the
second is whether a display is required.  If the second is
non-zero then the standard display is given otherwise the
screen is not altered.

Formatting does consume a noticeable amount of power and it
is suggested that a power supply unit is connected.


All Flash Datapaks have their write protect bit set to zero
so that unless the Flash driver is present no writing can
take place.  In order that Flash Datapaks can be write
protected the most significant bit of byte 8 of the header
is used as the alternate write protect bit.  When a pack is
freshly formatted it is always 1 (ie write enabled).

The format of the header is basically the standard bootable


TYPE           bit 0     Not used, always 0
               bit 1     EPROM (ie not RAMPAK) always set to 1
               bit 2     PGCPK always set to 1 as paged
               bit 3     RDWRT always set to 0
               bit 4     BOOT generally set to 0 as pack bootable
               bit 5     COPYPK generally set to 1 as pack is copyable
               bit 6     NYIMPL set 0 to indicate flash
               bit 7     MK1PAK set to 0 as not MKI pack

               The default type bye is $26.

SIZE           $20 for 256K pack.

CODE           $01

DEV & PRIOR    $F8

BOOT           $19 default

RANDOM WORD    The most significant bit is used as the real
    		write protect bit


The driver software comes as a bootable device on every
standard Flash Datapak and on the Flash Formatter packs.
It is different from other drivers in that it is permanent,
it does not get removed when On/Clear is pressed at the top
level even if the bootable pack is no longer present.

In order to achieve this it assumes that it is the first
item booted in.  It has priority $F8.  If something else is
already booted in and not also a permanent device it will
be removed from the device list.  This should, of course,
never happen.

To make a device permanent two alternative strategies
should be followed depending on whether the code is booted
in the low 7K or in the PERMCELL.

If it is booted in the low 7K then make 'dva_bot' the same
as 'dva_top'.  Remember both the old values.  When
attempting to remove check that both 'dva_top' and
'dva_bot' are equal and the same as the old 'dva_top'.
Refuse if they are not.  If they are then replace both with
the old 'dva_bot'.

If it is booted in the PERMCELL then remember the old base
value (at $2000) and make it equal to the value at $2002.
When attempting to remove check that the value at $2000 &
$2002 is as you left it then make $2000 the old value.
Then push the address of 'al$zero' on the stack and exit
(get the address by looking in the table pointed to by

To ensure that you are not booted in more than once use a
bit in 'dvt_spar'.  To be allocated a bit talk to Support.
Flash sets bit 2 of $2178 when it is present.
It re-vectors the following OS routines:
      pk$save       fl$writ        fl$eras        fl$copy
      fl$deln       fl$bdel        fl$renm        dv$vect
      dv$lkup       dv$clsr        pk$setp

To remove the driver all other drivers must be removed (by
pulling out all bootable packs and then pressing On/Clear
at the top level) and REMOVE used in the FLASH menu.  All
other drivers must be removed to avoid re-revectoring
problems.  If a device is still present the REMOVE fails
with the message "BAD DEVICE CALL".  If other permanent
drivers are released then they should be removed in this
way, one at a time, and in the reverse order to which they
were inserted.

This is a complete new procedure and care must be taken to
explain it to users when an upgrade of the driver is
released.  There is no exterior indication that the driver
has been upgraded.

Every time the Organiser is rebooted he name FLASH is re-
inserted in the menu.  This is to avoid the situation where
FLASH has been deleted from the menu.


The multi-boot Flash driver allows all long records
following to be booted in.  This means that other OPL
extensions can be added without altering the Flash Driver.
It is an extension to the standard Flash Driver.

It requires about 500 bytes of extra code some of which
will be taken out of the PERMANENT cell.  For this reason
it is not included in the standard driver.

The first time it boots as well as making itself permanent,
it boots all the long records (02 80 type that are assumed
to be .BINs) immediately after the bootable code on the
pack.  The second time (ie when the driver is already
present) it will be boot into the PERMCELL (the existing
flash driver will already take up most of the lower 7K).
Once it has determined that the flash driver is already
present it minimises its size and boots the following long

To generate a pack to utilise this feature either use
custom software or release 3.20 or above of BLDPACK.

WARNING:  BLDPACK is unable to adjust any absolute pack
addressing in the .BINs that it strings together.  The main
use of absolute pack addresses is for loading overlays.
There are a variety of ways round this problem if it is
absolutely necessary.


MAKE - version 3.20 and above will allow Flash Datapaks to
be made in the ordinary way.

FMAKE - uses the copier parallel interface to the IBM and
allows 256k Flash Datapaks to be made from a 256K image.

Copier File Transfer Utilities - serial and parallel utilities
in beta test, on this disk in COPIER directory.


If you have more than one Flash Datapak, they may have different
versions of the controlling software. You MUST install whichever
version is the latest. The original version of the software did not
display a version number; subsequent versions display a version
number when you select the `Flash' option. (On XPs, the number is on
the end of the menu.)

To use a second Flash Datapak, first note the version of your current
software, then remove the software (as explained in the Flash Datapak
leaflet). Now install the software from the new Datapak, and note its
version number. It will probably be the same version, or a later one.
You can now use both Flash Datapaks.

The new Flash Datapak may not work if you do not do this.

In the unlikely event that the new software is an earlier version
that the software from your original Datapak, remove the new software
and re-install your previous software.

If you do have different versions of the software, then having
installed the most recent version, you should format any Flash
Datapaks which have the old version. (Otherwise, when you come to
format the newer Datapak, the formatting process would copy the older
version of the software from the older Datapak onto the newer one,
and the newer Datapak might not work.) You can copy any data from the
older Datapak - perhaps to the newer one - before formatting it.

Flash Datapak Formatters contain the same formatting software as
Flash Datapaks themselves, and you can check the version number of
the software in the same way. You must not use a Flash Datapak
Formatter to format a Flash Datapak if the Datapak itself has a later
version of the software. In this event, return your Flash Datapak
Formatter to Psion for an upgrade.