Technical Reference Manual

PACKS

GENERAL PACK TYPES DATAPACKS FLASHPACKS RAMPACKS DEVICE A: INTERNAL RAMPACK DEBUG RAMPACK SOFTWARE VARIABLE USAGE PACK ID STRING SYSTEM SERVICES PACK ERRORS CONNECTOR PINOUT

GENERAL

Packs are the removable storage medium used in the Organiser. On a Pack the data is stored in either

• EPROM (ultraviolet Erasable and electrically Programmable Read-Only Memory). These packs are called Datapacks.
• Flash-EEPROM (Electrically Erasable and Programmable Read-only Memory). These packs are called Flashpacks.
• Battery buffered RAM (Random Access Memory). These packs are called Rampacks.

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.

PACK TYPES

DATAPACKS

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.

FLASHPACK OVERVIEW

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:

• significantly less power used when writing,
• nonvolatile,
• can be formatted in place,
• bigger than available EPROMs.

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

Rampacks are packs that have RAM rather than EPROM as their storage medium. This has advantages and disadvantages:

• RAM can be written to much faster than EPROM (the same speed as reading in fact).
• The RAM used in rampacks is CMOS RAM and uses less power than EPROM.
• RAM can be altered and does not require formatting.
• RAM is volatile and requires a back up battery to retain its contents.
• Data in RAM is not as secure as in EPROM and is more easily corrupted (e.g., by pulling rampack out of Organiser while it is being accessed).
• RAM is much more expensive byte for byte than EPROM.

The CM operating system does not handle rampacks.

WARNING

Rampacks contain a lithium battery that has an estimated lifetime of 5 years.

A Rampack with a dead battery is still fully functional within the organiser, but if at any time it is plugged out, all data is lost! This may also happen when the organiser is left unpowered (e.g. while battery changes).

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: INTERNAL RAMPACK

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).

DEBUG RAMPACK

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.

SOFTWARE

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.
DEVICE B: Upper side slot (closest to the top slot).
DEVICE C: Lower side slot.
DEVICE D: Top slot.

VARIABLE USAGE

Described below are the variables used by the pack handling system services.

PACK ID STRING

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.

SYSTEM SERVICES

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.

PK$SETP

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).

PK$SAVE

Save a given number of bytes at the current position in the current pack.

PK$READ

Reads a given number of bytes from the current position in the current pack into a buffer.

PK$RBYT

Reads a byte from the current position in the current pack.

PK$RWRD

Reads a word from the current position in the current pack.

PK$SKIP

Skips the pack's address up by a given number.

PK$QADD

Returns the current pack address.

PK$SADD

Sets the current pack address.

PK$PKOF

Turns off all slots.

PK$SETP or PK$SADD must be called before the packs can be accessed again.

PACK ERRORS

The following errors can occur when accessing the datapack slots.

CONNECTOR PINOUT

SD0-7 SMR SCLK SOE_B SS_B Gnd SPGM_B SVCC SVPP

8 data lines Master Reset ClockOutput EnableSlot Select Ground (0v) Program 5v Program Voltage

Note that lines which are active low (inverted logic) are followed by '_B'.