PocketBook II hardware...

If you are interested, the Acorn RISC OS Psion link project is available as source code, plus a horrendously detailed document describing practically every aspect of the link protocol.

When I get sorted out with a job over here , then I may look to getting a more modern PDA. I won't leave the PocketBook II behind though, I only hope the more modern Blackberry-era PDA is half as reliable as SIBO and its built-in software have proven to be. But, then again, I could always look for a second-hand series 5?

[later: I'm not sure about the series 5. Playing with the emulator and reading the 5mx user guide, it looks to be a great organiser with two important quirks. 1: It is possible to add custom software to the organiser, using a rather complicated (to create, not to use) SIS installer system, but it does not seem possible to arbitrarily arrange the order this is shown, so you can't keep "tools" (diary, bank account, household expenses, etc) at one end and "games/leisure" at the other. Is this correct or have I missed something? 2: It seems that series 5 does away with file extensions and instead associates a UID with files to link which files belong to which program. Using OPL on the emulator, I have not found a way to create/open a file specifying its UID - so I am not yet able to write a program that, when a file is chosen, is automatically started. As this is a rather important facet of how the system works, how come the OPL guide makes remarkably little reference to this?]

Here is an idea of what you can expect from two NiMH cells. The "batteries low" indicator is on, and has been for a couple of days (and about four hours of use, so far). The batteries are "low" but not expired.

A little digression... The only thing the organiser appears to be missing in this respect (i.e. power handling) is the ability to have a 'boot' script (let's call it Autoexec.bat!), so if all power is lost, it can switch itself on and resume when power is restored. The data will be okay, the memory backup battery will see to that, however the organiser will come back to you in 'off' mode (i.e. in standby, out of 'on' mode - it is important to realise 'on' and 'off' are not absolute states like a light switch).
I guess it could be forced by clever use of the Auto-Wake-Up on the serial port to cause the machine to 'come alive'? Or perhaps it may be possible to set some sort of alarm semaphore to trigger every minute? I have not looked into this. I know it is possible, set an alarm and the organiser will switch itself 'on' and 'ring' the alarm at the correct time.

• Unregulated
  A biggish transformer will be connected to the mains, with the other end feeding into a group of chunky diodes or a bridge rectifier (four-legged black thing, probably marked ~ ~ on one side, and + - on the other). The power will then most likely have a largish ~25V rated capacitor across it, and if a decent brand, a fuse of some sort.
  That's all.
  There is no picture, unregulated supplies look a lot like that shown just below, only with a lot less 'stuff' on the circuit board.
  
• Regulated
  Exactly as above, except at some stage the power will pass through a thing that looks like a power transistor; which may have a metal 'back' and may additionally be connected to a heatsink (left and part of bottom left in the picture). This lump of silicon clips the excessive input voltage (can be 12V to 16V) down to the desired amount (in our case, 9V but may be slightly weird like 8.7V - close enough).
  The picture is of an iomega Zip power pack.
  As a complete aside: years ago I made a portable video display system using a tiny monochrome monitor (powered off 12V battery), a Bush Box, and a Zip drive to boot from. I originally ran the Zip drive off the 6V battery (actually 5.7V) that would run the Bush box. The Zip failed to read even one disc. It wasn't until I put its power through a 5V regulator that the thing worked. The Zip drive spindle speed varies according to voltage so it must be run at exactly the right voltage - how crap is that!?!?!
   
  
• Switch mode
  This clever supply works by 'slicing' a DC part of the input power to generate the output power. It is electrically 'noisy' (you can usually hear it on a LW radio), and it is quite a complex thing to achieve in circuitry - however it is worth the effort as a switchmode is much more efficient than wound transformers, and also able to deliver higher power for less heat (and in a smaller physical space).
  The alleged downside is that if a switchmode fails, you may end up with mains on the output!
  Having said this, pretty much everything uses a switchmode (your laptop or desktop, satellite receiver, printer, router...) and does so cooly and efficiently. I don't lose sleep over failed switchmodes as I've not experienced such a thing in all my years of being a geek, nor have I ever been any closer to seeing one than the usual "the favourite second uncle of a friend of a friend". It may be an urban myth invented by the manufacturers of the older wound-transformer power packs who knew their days were numbered!
  First: IMPORTANT SAFETY WARNING The capacitors in a switchmode are usually rated 350V for dealing with rectified mains voltages. They may pack quite a punch in a tiny size, much like a camera flash unit. DO NOT TOUCH THE CIRCUITRY WITH BARE FINGERS EVEN WHEN DISCONNECTED. And don't be dumb enough to think it'd be 'cute' to short across a capacitor with a screwdriver. It'll make a big spark and a pop, whoo-hoo. Now your power pack may fail to work correctly.
  Easy ways to spot a switchmode: The transformer is way smaller than it ought to be. There are lots of components on the board. Look at the solder-side if you can, you may see more there! And if you look carefully at the capacitors, you'll see some are rated 350V.
  The picture is of a generic (unbranded) mobile phone charger. It is the one I use to power my organiser.

All present Psion computers are based around the proprietary SIBO architecture. A SIBO machine is a battery-powered, 8086-based, computer system. (this was written before the ARM-based series 5 was introduced)

The above information applies to the V30 as a discrete part. It may not apply entirely to the organiser as the organiser contains a custom ASIC of which a part is a V30 core. It is possible that various changes may have been made in order to offer greater throughput - perhaps the ASIC uses a 16 bit data bus internally? The memory protection is implemented in hardware (source: Psion SIBO HDK). I do not have have any technical information on the main ASIC.
 
The 16 bit x86 processors contain a number of registers, which I shall now describe. The register name shown in bold is the Intel name, and the name shown in brackets is the V30 name. I have chosen to prefer Intel terminology as most people seem to treat it as a type of x86 device; hence the register variables frequently defined in OPL software are AX%, BX%, CX%, DX%, SI%, and DI% instead of AW%, BX%, CW%, DW%, IX%, and IY% which are the V30 names.
 

AX (AW) - Accumulator

There are four 16 bit general purpose registers, and this is the first. The x86 processors can also treat this register as two 8 bit values, where it will be referred to as AL (A - low) and AH (A - high). AL/AH names are the same in V30 terminology.
As the x86 is highly non-orthogonal, there are specific instructions make use of this register:

• AX - word multiplication and division; word input and output; data exchange.
• AL - byte multiplication and division; byte input and output; BCD rotate; data exchange.
• AH - byte multiplication and division

To see what I mean, consider a brief description of the MUL instruction:

Unsigned multiply of the accumulator by the source. If 'src' is a byte value, then AL is used as the other multiplicand and the result is placed in AX. [etc]

This is obviously different to, say, the ARM processor where the MUL instruction is as follows:

The MUL instruction multiplies the values from Rm and Rs, and places the least significant 32 bits of the result in Rd.

The only restrictions are that Rd cannot be R15 (the Program Counter!), and due to the multiply algorithm Rm and Rd must be different registers. All other combinations of register are possible.
 

BX (BW) - Base

As above; this instruction is used in translation table data exchange - namely the XLAT instruction; and also in indexed addressing.
 

CX (CW) - Counter

As above; this instruction is used as a counter - for example the LOOP instruction will decrement CX and loop if it is not zero. It can also be used to count how many shifts to perform with ROL or ROR, etc.
 

DX (DW) - Data

As above; this instruction is used for word multiplication/division, and also input and output using indirect addressing.
Back to the MUL instruction for details:

Unsigned multiply of the accumulator by the source. If the source operand is a word value it is multiplied by AX and the result is stored in DX:AX. [etc]

---

The x86 can address 64K, and it splits up the nominal 1Mb addressable memory by using a segmented addressing system where a 16 bit address is added to a 16 bit segment reference to generate a 20 bit physical address.
For example, you may have seen addresses in PC clones (in the DOS era) specified with a syntax such as DC00:0010, which is DC000 + 0010, or the physical address 0xDC010.
 
How this works is that you have two registers for the address. The most significant is the segment register (i.e. DS) which in our example is DC00. Then you have the displacement register (i.e. SI) which is 0010. The processor will shift the segment register to the left four places (effectively a multiply by sixteen) to form the address DC0000 to which the displacement will be added. In total, the final address is DC010 as shown.
 
Growing up with the 6502 and then the ARM, I find this method of addressing to be extremely messy. However we must remember that the 6502 (first produced in 1975) and Z80 (first produced 1976) could only address 64K of memory. The 8088 (first produced in 1977), by using this horrid segmentation scheme, was able to address a mindblowing megabyte.
 
The problem, and the complication that often causes confusion, is that squishing two sixteen bit values into a twenty bit result can cause a number of important overlaps. For example, the BIOS machine ID (in a generic 'PC clone') may be determined by hoiking a word from the address FFFF:000E. The value will probably be 0x00FC or 0x01FC which will mean "I'm an AT clone", as PCs don't really use this information any more.
However, to complicate matters, this location can be addressed as FFF0:00FE or FF00:0FFE or even F000:FFFE.
Basic logic may suggest to use the segment register to specify the segment, and the offset to specify a 64K offset within this segment (i.e. F000:FFFE), however it seems that in reality, the segment register holds most of the address, so you'll see the machine ID quoted as being at FFFF:000E.
Yet another complication arises from the fact that the four segment registers may refer to the same actual 64K location, to four different 64K locations, or to a mixture. This gives rise to the concept of memory models, and in using trickery to address data of more than 64K (thus polluting the C programming language with the keywords far and huge).

As a brief aside, this is the difference between a .COM and a .EXE in DOS software. The .COM can only work within the so-called 'tiny' memory model in which case CS = DS = ES = SS (definitions just below), while .EXEs can work in whatever memory model the programmer sets the compiler to. Asides from embedded code designed to recycle old hardware and programs where function is more important than looks, you'll be hard pushed to find many 16 bit DOS applications these days. I believe Vista cannot run 16 bit DOS software natively, it needs a third-party emulation layer (i.e. DosBox). Software written for Windows (Win95 and later) uses a flat 32 bit address system and segmentation is simply a ghost of the dark ages before anybody really knew who Bill Gates was...

It gets even better - because of the overlaps, it is possible to set the segment registers differently and use specific offsets so that all of the memory locations referenced point to exactly the same place. I guess this might have made sense back in the '70s when the original PC design was considered 'advanced' it if had a full 256Kb of memory. I have also used an XT clone (some sort of Tandy computer) offering 640Kb on-board, plus a "Turbo" button to select between 4MHz and 8MHz (roughly) operation. Accordingly it was always running 'fast'! All of this is hard to swallow if you are used to the sort of stuff available these days, but, you know, there WAS a time when entire software packages fit into a hundred kilobytes. Now you'd be hard pushed to find a support DLL that small!

For what it is worth, and to brag a little, I have written a simple GIF image viewer in ARM code. The entire application? 2048 bytes exactly. Why? Because I could. Perhaps as a karmic balance for my VisualBasic code which offers an acceptable size .EXE along with a less acceptable 3½Mb worth of support junk.

But I don't need to brag too much, do I? After all, the organiser you hold in your hand offers a functional word processor, diary, spreadsheet, spellcheck, and simple database application. And you might have 256Kb on-board, plus one or two not overly large memory devices which may be used for files (not extended memory). Oh, and let us not forget OPL so you can download or create lots of additional software, such as a handy French verb reference, a bank account manager, biorhythms, games, solar compass, etc etc.
 
Anyway, the majority of this stuff about segment registers is of little consequence to you when coding on the organiser as messing with the segment registers can cause some very unpleasant effects. This is purely provided as a brief explanation as to what these registers are actually for.
 

CS (PS) - Code Segment (Program Segment)

This specifies the base address of the segment storing the program's instructions.
 

DS (DS0) - Data Segment (Data Segment 0)

This specifies the base address of the segment storing the data.
 

ES (DS1) - Extra Segment (Data Segment 1)

This specifies the base address of the segment used by data transfer instructions as the destination.
The MOVS (move string) instruction shows how DS and ES are used:

Copies data from addressed by DS:SI (even if operands are given) to the location ES:DI destination and updates SI and DI based on the size of the operand or instruction used.

SS (SS) - Stack Segment (same)

This specifies the base address of the segment storing the stack. When you PUSH or POP stuff on/off the stack, the actual address is formed with SS:SP.
 

---

SP (SP) - Stack Pointer (same)

This register holds the least significant 16 bits of the stack address. When data or status is to be written to, or read from, the stack, this register is merged with the Stack Segment (like SS:SP) to form the physical address.
 

BP (BP) - Base Pointer (same)

This register is used in various forms of addressing for data access as an index into the specified segment, like BP:DI, etc.
 

---

IP (PC) - Instruction Pointer (Program Counter)

This, forming a complete physical address in the style CS:IP, specifies the address of the next instruction to be executed; this pointer being incremented as the instruction is loaded and thus processed.
Treat this register as a "you touch, you die".

---

 

SR (PSW) - Status Register (Program Status Word)

This holds various items of status: Carry flag, Parity flag, Auxiliary Carry Flag, Zero Flag, Sign Flag, Break/Trap Flag, Interrupt Enable Flag, Direction Flag, Overflow Flag...

 
In OPL, the OS keyword returns the flags after making an OS call. The only flag of specific interest is the Carry flag (bit zero - the 'error' bit) which is set if a system call failed. Note that non-error-generating system calls (i.e. those which return a failure code instead of an error) may also set this bit.
The only other two flags of interest are the Zero flag (in bit six - called EQual) and the Sign flag (in bit 7 - called SL); which are used in one way or another with CharIsControl (function 0x9D), BufferCompare(Folded)/StringCompare(Folded) (functions 0xA3/0xA4/0xAF/0xB0 - in which case bit zero is given as the 'UL' flag, but it is a form of error flag), Long(Unsigned)IntCompare (functions 0xBB/0xBE), and FloatCompare (function 0xC5).
 

---

Finally, there are two indexing registers. One is a 'source' pointer, the other is a 'destination' pointer. You'll see this used in SIBO system calls such as ProcCopyToById (function 0x92) and the time read/write/convert functions (0x89...).
 

SI (IX) - Source Index (Index X)

This is used as a source pointer in data block transfer instructions.
 

DI (IY) - Destination Index (Index Y)

This is used as a destination pointer in data block transfer instructions.

177C:0100 8CD8  MOV  AX, DS
177C:0102 CB    RETF       
177C:0103 8CC0  MOV  AX, ES
177C:0105 CB    RETF       
177C:0106 8CD0  MOV  AX, SS
177C:0108 CB    RETF       
177C:0109 8CC8  MOV  AX, CS
177C:010B CB    RETF       
177C:010C 89E0  MOV  AX, SP
177C:010E CB    RETF       
177C:010F 89E8  MOV  AX, BP
177C:0111 CB    RETF       

REM RegPeek
REM
REM By Rick Murray; 2008/01/01
REM For PocketBook II techie information
REM http://www.heyrick.co.uk/software/pb2/
REM

PROC Main:
  REM Allocate memory for code
  GLOBAL ReadDS%, ReadES%, ReadSS%, ReadCS%
  GLOBAL ReadSP%, ReadBP%, Result%, SPS%
  GLOBAL DSCode%(2), ESCode%(2), SSCode%(2)
  GLOBAL CSCode%(2), SPCode%(2), BPCode%(2)
  GLOBAL Rslt$(32), Result&

  REM Poke in code. It is essentially:
  REM   mov   ax, REG
  REM   retf
  REM Where REG is DS, ES, SS, CS, SP & BP.
  DSCode%(1) = $D88C : DSCode%(2) = $CB
  ESCode%(1) = $C08C : ESCode%(2) = $CB
  SSCode%(1) = $D08C : SSCode%(2) = $CB
  CSCode%(1) = $C88C : CSCode%(2) = $CB
  SPCode%(1) = $E089 : SPCode%(2) = $CB
  BPCode%(1) = $E889 : BPCode%(2) = $CB

  REM Set a value to point to the code
  ReadDS% = ADDR(DSCode%(1))
  ReadES% = ADDR(ESCode%(1))
  ReadSS% = ADDR(SSCode%(1))
  ReadCS% = ADDR(CSCode%(1))
  ReadSP% = ADDR(SPCode%(1))
  ReadBP% = ADDR(BPCode%(1))

  REM Generate output, calling our routines
  REM as we go.
  dINIT "The 'other' processor registers"

  Result% = USR(ReadDS%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(Result%), 4)
  Result& = Result% : Result&=Result& * 16
  Rslt$=Rslt$+", which is +"+GEN$(Result&, 7)
  dTEXT "DS (Data Segment)", Rslt$

  Result% = USR(ReadES%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(Result%), 4)
  dTEXT "ES (Extra Segment)", Rslt$

  Result% = USR(ReadSS%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(Result%), 4)
  dTEXT "SS (Stack Segment)", Rslt$

  SPS% = Result%
  Result% = USR(ReadCS%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(Result%), 4)
  dTEXT "CS (Code Segment)", Rslt$

  Result% = USR(ReadSP%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(Result%), 4)
  dTEXT "SP (Stack Pointer)", Rslt$

  Result% = USR(ReadBP%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(Result%), 4)
  dTEXT "BP (Base Pointer)", Rslt$, $200

  Result% = USR(ReadSP%, 0, 0, 0, 0)
  Rslt$=RIGHT$("0000"+HEX$(SPS%), 4)+":"
  Rslt$=Rslt$+RIGHT$("0000"+HEX$(Result%), 4)
  dTEXT "The stack address is", Rslt$
  
  DIALOG

  REM All done!
ENDP

IMPORTANT - This is only an idea, NOT working code!

; Initialise
push  bx                     ; stash BX as we'll use it

; Try to claim the channel
mov   al, A9MSlave           ; Value of this is unknown
HwGetChannel                 ; OS call, value not known
jc    ChNotAvail             ; If channel isn't available...
pushf                        ; Remember CPU state
cli                          ; Disable interrupts
mov   al, SelectChannel5     ; Value of this is unknown
HwSelectChannel              ; OS call, value not known
push  ax                     ; Remember previous channel

; Try to communicate with ASIC
HwNullFrame                  ; OS call, value not known
mov   al, 0043h              ; SerialSelect | ASIC5NormalID
out   008ch, al              ; =A9BSerialControlW
in    al, 008ah              ; =A9BSerialDataRW
test  al, al
je    NoASIC                 ; If no ASIC...
mov   ax, bx                 ; If ASIC, stash AX in BX
jmp   SkipASIC

; No ASIC, set to return value -1 for No ASIC error
NoASIC:
mov   -1, bx

; Resume here if or if no ASIC
SkipASIC:
pop   ax                     ; Recall previous channel
HwSelectChannel              ; OS call, value not known
popf                         ; Recall CPU state
mov   al, A9MSlave           ; Value of this is unknown
HWFreeChannel                ; OS call, value not known

; Our exit code
DropOut:
mov   ax, bx                 ; Copy set up BX into AX
pop   bx                     ; Restore original BX
clc                          ; Interrupts back on
retf                         ; Back to caller

; If channel wasn't available, we come down to here
ChNotAvail:
mov   -2, bx                 ; Set error code to be -2
jmp   DropOut                ; Go to exit code