Commercial pack not yet archived: AccuPEN GOLD

[okto]

AccuPEN GOLD appears to be a medical logging suite, particularly focused on diet and exercise. It came as a 32k image on a 64k Datapak, with a 16k Datapack for logging records.

Attached is the ROM image uploaded with Jaap's sendpack. I'll email it to Jaap directly for inclusion on his website, as well.

[Martin]

Well done Okto..

We are always on the lookout for 'new' program pack images.

(1) Please let me know if you get a response from Jaap... Others have tried without success.

(2) AccuPEN GOLD.. I'll try it in detail when I have a bit more time. The initials findings are..

All the routines are in (TRANSlated) OPL (no machine code)
It Boots into its own menu
If the clock is not set (I'm going to check how it knows) It first asks for a date which on an XP may turn out to be a problem with the Y2K bug on an LZ in XP mode it seams to work OK.
There are databases on the pack I'll need to check them out!

You mentioned a 16K record logging pack... you don't have an example of that do you? It might help to see the data structure of the records! if not I'll let the program create one and check that.

AND of course... Most importantly *** Do you have the manual? ***

Again I think its good work, I'm looking forward to deconstructing it..

Sincerely
Martin

[okto]

Answers in approximate order :
No response from Jaap.
I do not have the manual.
My findings and conclusions regarding function and use match yours. (It was actually quite distressing to me at first that the pack is bootable. I did not know how to exit to the main menu, as I did not realize the program's menu was scrollable!)
I erased the 16k record log pack as it was the only non-volatile storage I had when I bought the Organiser and I did not have a Comms Link yet. From looking at the files on it before I nuked it, I believe the main program will write them automatically, one file per type of info.

I saw another LZ on eBay recently with the same packs loaded, I think a multiple-unit lot of them was surplused from whatever medical facility was using them. Makes me wonder how many Org2s are left out in the world still in professional use.

[Martin]

AccuPEN more observations..
There is a Y2K issue if the clock is not set correctly..
The first lines of the boot code are

Code: Select all

Lab1::
IF YEAR<1989
 PRINT "SET DATE"
 PRINT "PRESS SPACE"
 GET
 TOPCALL:("TIME")
ENDIF

So to get it to run successfully on a CM/XP the clock will need to be set with years (1989 for 2023),(1996 for 2024),(1997 for 2025) etc etc.

A more interesting point is the 'statement' TOPCALL:(TIME) and later in the file TOPCALL:("CALC"). These are used to CALL the TOP level menu items TIME and CALCulator functions. To me this is interesting as I'm sure I've read somewhere that Psion recommended not to call these (or any other top level menu items) as the program could lose its place in the 'stack' and could crash on return. BUT the author of AccuPEN seems to have made it work here. I've included the code for their TOPCALL: function below in case any member with machine code experience can explain how it works that would be great.

I tried it on an LZ and firstly it detected a syntax error in --- USR(ADDR(L1%(1)),PEEKW(L3%)) --- as the programming manual states...

e.g. A%=ADDR(ARRAY()), but you can't specify individual elements of an array.

I modified it to USR(ADDR(L1%()),PEEKW(L3%)) which tranlated OK but crashed the machine when run with

TRAP 7B85
9ACE

(Battery out reset)

I would appreciate reading anyone's thoughts
Sincerely Martin

Code: Select all

topcall:(P1$)
REM CM/XP procedure
LOCAL L1%(55),L2%,L3%,L4%,L5%,L6$(5)

ESCAPE OFF
L2%=PEEKW(8194)
L6$=P1$
DO
 L4%=ADDR(L6$)
 L5%=5
 L3%=L2%+PEEKB(L2%)+1
 WHILE PEEKB(L4%)=PEEKB(L2%)
  L5%=L5%-1
  L2%=L2%+1
  L4%=L4%+1
  IF L5%=0
   GOTO Lab1::
  ENDIF
 ENDWH
 L2%=L3%+2
UNTIL PEEKB(L2%)=0
RETURN
Lab1::
L1%(1)=280
L1%(2)=$5ACD
L1%(3)=$023B
L1%(4)=16408
L1%(5)=$30C8
L1%(6)=$B28E
L1%(7)=7422
L1%(8)=8204
L1%(9)=$02CB
L1%(10)=3622
L1%(11)=5308
L1%(12)=8208
L1%(13)=9743
L1%(14)=$02CB
L1%(15)=4646
L1%(16)=2748
L1%(17)=8212
L1%(18)=9733
L1%(19)=$02CB
L1%(20)=5671
L1%(21)=313
L1%(22)=$9AED
L1%(23)=15614
L1%(24)=8293
L1%(25)=15582
L1%(26)=$C35A
L1%(27)=$02FF
L1%(28)=26078
L1%(29)=$C37A
L1%(30)=$6BED
L1%(31)=15614
L1%(32)=9186
L1%(33)=15582
L1%(34)=$C30B
L1%(35)=$2BED
L1%(36)=15582
L1%(37)=$C34B
L1%(38)=6317
L1%(39)=56
L1%(40)=$4BFD
L1%(41)=14559
L1%(42)=$832B
L1%(43)=$0BFD
L1%(44)=14591
L1%(45)=9186
L1%(46)=14559
L1%(47)=$836B
L1%(48)=$7AFD
L1%(49)=14559
L1%(50)=$835A
L1%(51)=$02FF
L1%(52)=25912
L1%(53)=$9AFD
L1%(54)=16198
L1%(55)=14592
USR(ADDR(L1%(1)),PEEKW(L3%))

[okto]

This is the eBay listing of another LZ with both AccuPEN paks:
https://www.ebay.com/itm/266101380093

[Pernod]

Attached is the ROM image uploaded with Jaap's sendpack. I'll email it to Jaap directly for inclusion on his website, as well.

As a newcomer to the Organiser why are pack owners not dumping the actual ROM contents, instead of producing these opk images?

[Martin]

Hi Nigel

In effect an OPK (Organiser PacK image) is a 'dump' of the contents. The beauty of...

(a) 'UNMAKE' (Original By Psion needs DOS and COM1 or COM2)
(b) [Read Pack B:] and [Read Pack C:] (by ORG-Link uses UNMAKE in Windows and USB port)
(c) 'Sendpack' (by Jaap)
(d) 'DumpPack' (by Boris Gornet RIP)

with these you have the option of letting the utility 'split' the OPK into its constituent parts. You can see the different file types supported by an Organiser in appendix A (page 39) of the Developer Manual (here).

Sincerely
Martin

[Pernod]

In effect an OPK (Organiser PacK image) is a 'dump' of the contents.

I appreciate an OPK is effectively a truncated ROM dump that just contains the required data, rather than full ROM dump. Have any ROM packs actually had their ROM read, and compared with OPK, ie. does the OPK contain files in the same order as they're in ROM? Do all pack reading tools produce identical OPK's?

I'm sure I've seen OPK's that claim to be from the same Pack but differ in some way. Maybe they're a different version, or created with a different tool?

Up until very recently Psion SSD's were 'archived' by just transferring the individual files to PC and zipping them up, whereas now we can read the full SSD including it's filesystem for a complete 'backup'.

[Martin]

I get what you are saying Nigel.. that there might be other pack 'information' that is not included in the OPK. I have successfully used UNMAKE to copy a pack image to a PC and later used MAKE to successfully put it back again.

The following are extracts from the developers Read_me txt files and information...

DumpPack
~~~~~~~~
by Boris Cornet (reusing code from Horatios brilliant fast5 routine)
Dumppack produces an exact copy of a pack on the PC, mostly even if UNMAKE fails.
Since it uses low level pack access, it will also copy protected or corrupted packs.
The OPKs produced are sligthly different from standard OPK because all bytes on the pack are copied, the program does NOT stop at the <end-of-pack>-marker!
Please make sure the CommsLink is booted in and activate Psi2Win on the PC.
The program has an option to detect the pack size, but if you are copying an Organiser 1 pack or a pack with a corrupted pack header, you will have to specify the pack size.

SENDPACK
~~~~~~~~
by Jaap Scherphuis, psion@jaapsch.net
This procedure will send an image of a pack through the comms link.
Before you run this program, make sure you have a comms link attached, and that the computer you have connected it to is running CL.
When you run PACKSEND, after a short pause you will be asked which pack to send. This can be pack B:, C: or D:. Simply press the appropriate letter, or ON to quit. Pack D: denotes the top slot, i.e. the comms link software.
While the image is sent, a counter counts down to 0 to indicate how much longer it will take. The pack image will be called PACK.OPK, and it is in the same format as the files produced by the developer kit's UNMAKE program.

ORG-Link_v2 Pack code buttons:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The four large buttons do exactly what the text on them says. Their actions replace the Psion MAKE and UNMAKE pack handling tools, and replicate their action precisely, but with two vital differences: 1, Psion limited this to pack C only, but with ORG-Link you can select pack B if you want, avoiding the need to risk physical and electrical stresses by moving packs when you don't want to; and 2, there is no 'AMAKE', you cannot append to a pack other than copying files to it in the normal way. It's easier, and safer, to make a clean pack image in one go, with BLDPACK. Add new files to that, then send the OPK file to a pack with ORG-Link. This method also prevents loss of space on EPROM or Flash packs caused by replacing old files.

Page 65 of the republished Technical Reference Manual (here) has a pack section
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 on page 80).


You can of course examine the contents of an OPK with Jaaps OPK Editor..
This is a screen dump of the editor examining the pocket spreadsheet pack image.
.

OPK_Editor.png

.
Sincerely Martin

[Pernod]

I get what you are saying Nigel.. that there might be other pack 'information' that is not included in the OPK. I have successfully used UNMAKE to copy a pack image to a PC and later used MAKE to successfully put it back again.

The following are extracts from the developers Read_me txt files and information...

Lots of good info there, so sounds like only DumpPack dumps the whole ROM. I'd previously assumed the actual ROMs in the packs were socketed, so would've been easy to remove and dump, but now see they're not so more easily read by software.

As I have some OPK's that are almost identical and only differ by a handful of bytes I'll see if the OPK file editor gives me any clues to their differences.

No more questions for now, thanks.