Technical Reference Manual
Packs are the removable storage medium used in the Organiser. On a Pack the data is stored in either
Storing Data on Packs has certain advantages and disadvantages when compared to conventional storage such as floppy disks. Packs are much more robust than disks - e.g. you cannot scratch a datapack and they are not susceptible to magnetic fields. They require no special drives - they can be driven from a simple I/O port. This results in higher reliability (no moving parts), much lower power consumption (no motors) and a much smaller package than floppy disk drives.
All packs can be read faster than disks but the write time of Data- and Flashpacks is comparatively slow.
Also once written to, the space on Data- and Flashpacks is permanently used even if the data is deleted. Once a pack gets full, the complete pack has to be erased. While Flashpacks are formatted within the Organiser, Datapacks must be placed under an Ultraviolet lamp.
Selective erasure of one part of a pack other than a Rampack is not possible.
These are the most common memory packs. They are available in several sizes: 8, 16, 32, 64, 128k, and even made larger ones by 3party manufacturers. Note that the CM model organiser cannot use packs larger than 64k.
Datapacks of 8 and 16K were first produced for the Series One Organiser. The Series II offers compatibility so those old packs can be used with it.
Datapacks contain an EPROM (Erasable Programmable Read-only Memory) chip. Such chips can be written to by using a high voltage, and once that is done the data contained on it is very safe. Writing to a datapack will cost considerable battery power and is very slow.
Information stored on a datapack will last for many years without the need of a power supply.
EPROM's are erased by subjecting them to ultraviolet light through the quartz window on top of the chip. The database cabinet has a hole underneath the label to access the window without having to open it.
The recommended erasure procedure is exposure to UV light which has a wavelength of 253.7nm. The integrated dose (i.e. UV intensity x exposure time) for erasure should be a minimum of 15W-sec/cm2. The erasure time with this dosage is approximately 15 to 20 mins using a UV lamp with a 12mW/cm2 power rating. The EPROM should be placed within 2.5cm of the lamp tubes during erasure.
Detailed Flashpack Information is provided in an extra chapter.
Flashpacks on the Organiser represent a substantial improvement in storage technology. There are four major advantages:
Writing is done in a completely different way to EPROMs and a special software driver must be present. The driver software comes as a bootable device on every standard Flash Datapack. Once booted, the flashpack driver is resident, i.e. it does not get removed when On/Clear is pressed, even if the pack is no longer present. If the driver is not present and a write is attempted a "READ ONLY PACK" error is reported.
Flashpacks can be formatted in place by using the main menu option FLASH (automatically established by the driver) or by calling the OPL procedure FLSHFORM:("B",1) where the first parameter is the slot (B or C). FLSHFORM:("B",0) operates the same way without displaying a message.
Formatting does consume a noticeable amount of power and it is suggested that a power supply unit is connected.
As after formatting the driver has to be copied back to the pack, there must be another flashpack (or a flash formatter pack) present, otherwise a DEVICE MISSING error will occur.
The CM operating system does not handle flashpacks.
Rampacks are packs that have RAM rather than EPROM as their storage medium. This has advantages and disadvantages:
The CM operating system does not handle rampacks.
There is no way to check the pack battery by software. However older documents list a PACK BATTERY LOW (191) error which was removed later, as the feature was never implemented.
Usually there is no need for formatting a rampack, nevertheless the following program might become useful in case of spurious read errors:
FMTRAM: REM PROGRAM TO FORMAT RAMPACK LOCAL a%(11) CLS :PRINT "Format C: Y/N ?" IF LOC("Yy0",GET$) rem writes a zero byte at the beginning of the rampack rem this invalidates the pack and the OS automatically reformats a%(1)=$4f37 :rem CLRA, PSHB a%(2)=$3f62 :rem OS pk$setp a%(3)=$3225 :rem PULA, BCS $1 a%(4)=$0d36 :rem PSHA a%(5)=$4f36 :rem CLRA, PSHA a%(6)=$30c6 :rem TSX, LDAB $01 a%(7)=$013f :rem OS pk$save a%(8)=$6131 :rem INS a%(9)=$334f :rem PULB, CLRA a%(10)=$3f62 :rem $1: OS pk$setp a%(11)=$3900 :rem RTS USR(ADDR(a%()),2) :REM 1=Pack B, 2=Pack C ENDIF STOP
Device A: (also known as PACK A:) is the internal RAM of the Organiser which is treated as if it were a rampack. It is accessible via the same operating system services that handle datapacks.
Obviously the amount of memory available to Device A: varies depending on the machine type and on other demands on memory (e.g. the Diary and OPL programs).
A special type of rampack can be produced by setting the pack header ID byte (see below) to $3C and then adjusting the checksum word. The Rampack thus produced will automatically back up all (XP) or parts of the internal memory (LZ) in case of a TRAP error (i.e. a system crash).
A few seconds after displaying the TRAP message, the organiser will switch off. If a debug rampack is is present in one of the slots when the organiser is switched on again, all of the non-paged RAM area (see memory map) is copied onto the pack. Only low level pack access procedures are used in order to preserve as much of the zeropage as possible.
This is intended for debugging purposes, but may also be helpful for rescuing data.
As well as the 3 slots through which the Organiser can access datapack devices (or in the case of the top slot datapack like devices) it can also access the internal RAM as a datapack type device. From the top level menu and from OPL the following naming convention is used:
DEVICE A: Internal RAM of the Machine.
Described below are the variables used by the pack handling system services.
Every pack logged on the Organiser has a ten byte string for identification. This string is blown onto a blank pack by the Organiser during "sizing". It consists of an ID byte, a size byte, a 6 byte time string and a 2 byte checksum.
Note that the time string (bits 2-7) is replaced by device information on bootable packs (see details in chapter External Interfacing).
PK$SETP sets PKA_PKID to point to the relevant ID string in PKT_ID for the requested slot. When PK$SETP is called and a valid pack is in the requested slot then the first 10 bytes of the pack are compared to the 10 bytes stored in RAM for that particular slot. If they are not the same, then the 10 bytes from the pack are copied into RAM and, if requested, a "PACK CHANGED" error is reported.
The word checksum is used in rampacks to determine if they have been corrupted. If this checksum is not correct in a rampack it is assumed that they have been corrupted and they are filled with $FF and then resized (all data in them is lost). This does not apply to the CM operating system as it does not handle rampacks.
The first 2 bytes of the ID string are useful in determining the pack type and size.
Note that if bit 7 of the ID byte is set (MK1 Organiser datapack), the id string on the datapack will be different to that stored in the id table. The operating system converts the MK1 id string on the datapack to a valid MKII id string in the id table.
This section describes the operating system calls for pack handling.
These routines provide all that the programmer should need for datapack accessing. They automatically take care of reading and writing to the different types and sizes of packs giving the programmer a consistent interface irrespective of the pack which is plugged in.
However the operating system also offers more comfortable file handling services.
These routines will access the internal RAM of the Organiser (referred to as PACK A) as if it were an external rampack.
Sets up the operating system to access the current pack.
It powers up the slots (if they are powered down) and selects the required slot. It then detects if a pack is plugged into that slot and if so "logs on" that pack.
This routine must be run before calling any further pack routines and must be called again if the packs have been turned off or the slots have been modified in any way (i.e. by a user machine code program).
Save a given number of bytes at the current position in the current pack.
Reads a given number of bytes from the current position in the current pack into a buffer.
Reads a byte from the current position in the current pack.
Reads a word from the current position in the current pack.
Skips the pack's address up by a given number.
Returns the current pack address.
Sets the current pack address.
Turns off all slots.
PK$SETP or PK$SADD must be called before the packs can be accessed again.
The following errors can occur when accessing the datapack slots.
Note that lines which are active low (inverted logic) are followed by '_B'.