Keeping data safe on a large capacity Rampack.

[Martin]

With the prospect of acquiring one of Andrew’s 256K Rampack’s. It might be time to consider the one downside. The tendency for Rampaks to format themselves when a top slot peripheral is inserted or removed. PSION themselves issued instructions as to how to safely use one of their Rampak’s these instructions are included in the backup test report.

This image shows the results of 'Backing up' and 'Restoring' the data from a Rampack using the various software and different Comms Servers available.
.

RamPack_BackUp_Tests.png

.
The full report (here) outlines the tests, equipment and methods used.

Sincerely
Martin
.

[Lostgallifreyan]

Interesting. I did test big RAM packs when I made ORG-Link, specifically 64K and 256K, both by 'DynaSys'.

I don't understand the connection between DumpPack and ORG-Link, I didn't know about DumpPack. As a minimum need, ORG-Link specifies the lowest standard binary multiple for pack size that can hold the data it's being asked to put on a pack.

[Martin]

I don't understand the connection between DumpPack and ORG-Link, I didn't know about DumpPack. As a minimum need, ORG-Link specifies the lowest standard binary multiple for pack size that can hold the data it's being asked to put on a pack.

Hi...

Dumppack will 'backup' or dump the pack on a Windows PC using a USB Comms Link but it has no way of 'restoring' the OPK back onto the Rampack should the need arise (Neither does Bosis's Psi2Win). So I used ORG-Link as a server to restore the OPK [Make Pack].

The full report (link above) goes on to do tests using a different comms connection (RS232) on a hard wired COM1 port. There readers will see that Boris's 'Psi2Backup' works as well as anything for Backing up and Restoring - It works in Windows but needs access to COM1 or COM2, which you will never get with a USB Comms Link on a modern PC. So again the best option to Backup and Restore (OPK's) is to use [Read Pack] and [Make Pack] in ORG-Link_v2

In good faith
Martin

[Lostgallifreyan]

Thanks for the detail. That's weird, USB not offering COM1 and COM2. I suspect they might become available if explicitly disabled in BIOS, because I think many machines assume those two should exist with full BIOS support (and dedicated IRQ's) even if there's no hardware socketry to use the assignments normally given to it.

[Lostgallifreyan]

DATA SAFETY ON RAM PACKS:
I just posted in a different thread... https://organiser2.com/viewtopic.php?p=130#p130
A link to that from here is probably useful.

[amenjet]

I'd not read the RAM pack operating manual before and it was interesting. The section about not plugging and unplugging when the organiser is on is similar to other advice given across a wide variety of electronic devices . It is probably not a good idea to 'hot plug' anything in systems unless it has been designed for hot plugging or concurrent maintenance. Some enterprise systems are very much designed for this, few consumer systems are.
If the RAM pack was being used at the time of removal then it's very likely that data would be lost. If it's not being accessed then less of a chance of loss, I'd say.
Similarly, the sections about static electricity is also a standard for electronic devices. Static damage is a real thing, and can lead to permanent or transient errors. The permanent damage may not become apparent until much later than the static event. Personally I've not seen much damage that was definitely attributable to static, but then I tend to handle devices in ways that minimise its presence.

The interesting part is the description of how to insert peripherals when you have RAM packs. It seems to suggest that there is an issue somewhere with the power supply of the organiser or RAM pack when a peripheral is inserted. It implies that turning the organiser off, and not having a powered peripheral being plugged in isn't enough to keep the RAM pack data safe. This may indicate it is a static discharge that they are worried about.

This has been a bit hand wavy, and subjective, but after reading that document I do feel that there's something up with RAM packs and the organiser circuitry. More than I did before I read it.

Andrew

[amenjet]

One way to keep data safe on a RAM pack is to back it up. This can be done to a computer over RS232 or USB, but there is another way.

You can take the datapack out of the organiser and plug it in to a hardware device and copy it directly. Some time ago Martin Prest built a datapack reader and writer, details here:

https://github.com/martinprest/Psion2-D ... der-writer
https://hackaday.io/project/176677-psio ... aderwriter

A while after this was built I needed a similar device and, not aware of the earlier device I built a reader myself. i didn't need the write functionality so that feature is missing.

Even later, I needed to copy some Psion 1 datapacks. This is tricky as, although the hardware is the same or similar to Organiser 2 packs, the layout of the data on the pack is not compatible. So you can't put an Organiser 1 pack in an Organiser 2 and copy or back up the pack. So, after some discussion with Martin I decided to build a new device that could read and write datapacks without the need of a PC. It now exists and more information will be forthcoming, but here's a list of it's features:

Pros:
Reads EPROM datapacks and RAM packs
Writes EPROM datapack and RAM packs
Deals with datapacks at a hardware level. so should be able to handle any datapack, read-only or not
Reads and writes data pack contents to and from SD cards (there is an SD card slot on the device) using .opk files
Powered by (micro) USB.
Has a small OLED display and buttons for stand-alone operation.
Has a USB interface so data can be captured and the device operated over USB.
Has a built-in 21V supply for programming EPROM based datapacks.
it is, and probably always will be a work in progress with features being added as they are needed.
It works with Psion 1 datapacks

Cons:
Deals with datapacks at the hardware level so needs full support of all datapacks to be coded in its firmware. This is an ongoing job.
The code is an amalgamation of firmware from two different devices and is a bit 'untidy'.
features are missing and device support is missing in some aspects. For instance segmented datapacks are not supported. It could be added in the firmware, though, and probably will be at some point.
It hasn't got a user manual, but is fairly straightforward to use.
it is, and probably always will be a work in progress.
The current PCB requires hand modifications to work. There are errors on the PCB.

The plan is to open the device up to the world in its current unfinished state as it has already been useful, at least to me, and then any features people add can be fed back into the firmware. If there is interest then I'll do a video and open up the github. Actually, I have just made the github public. It's here:

https://github.com/blackjetrock/psion-org-datapack-tool

So, if you do have one of these devices you can take your rampack out of the organiser, plug it into the device, press a couple of buttons and copy it to SD card, and then to a PC if you wish.

Andrew

[Lostgallifreyan]

I added a bit in a post in the other thread (link to that, three posts up, here...) It describes some of the risk related to plugging of even unpowered devices. Mainly it has to do with unexpected ON-signal from the PC end if that end of a Comms Link is connected there, but it mentions what can happen to a capacitance when the ground line is less that ideally solid. The thing with Organisers, is the linear regulator is distributed across a fair bit of board area, using small discreet parts. This makes it less resilient to transients than a single-chip design with a solid ground reference.

I think you're right that they also have static discharges in mind, and plugging and unplugging packs can and WILL risk this because the ABS plastic is subject to huge friction. That can be enough to cause unrest, and this is a BIG reason I went to the trouble of working on the Organiser machine code for MAKE and UNMAKE, to get ORG-Link the ability to use either slot. Every time I had to swap a pack, I got worried that this time, it would go wrong, because with RAM, it often did. I needed to minimise the risk. Removing to plug to a specialised reader is a nice idea, but you still have the same risk, and a need for that specialised device. ORG-Link removes the risk, AND the need.

EDIT:
Andrew, an experiment maybe worth a go: ORG-Link pack read of Psion 1 pack in Psion 2 organiser. I suspect it might work for the same reason that Ghost can image a hard disk on a PC, being agnostic of file system if it's doing a 'forensic' bit-for-bit copy. I'd like to know the outcome, if you try it. Also, assuming it even works, try SPLITOPK.exe on the resulting saved file... While not so intended, if SPLITOPK is old enough, it might have undocumented code that can handle Psion 1 pack images.

[amenjet]

I think you're right that they also have static discharges in mind, and plugging and unplugging packs can and WILL risk this because the ABS plastic is subject to huge friction.

Maybe the way to attach a ram pack to an external device is to remove it from the plastic case and then ground yourself on the PCB before inserting it. Then no ABS plastic about.

Andrew, an experiment maybe worth a go: ORG-Link pack read of Psion 1 pack in Psion 2 organiser. I suspect it might work for the same reason that Ghost can image a hard disk on a PC, being agnostic of file system if it's doing a 'forensic' bit-for-bit copy. I'd like to know the outcome, if you try it.

I could do that if I can get ORG-Link to work. I don't have any Windows machines, I'm Linux only. It might work under Wine...

Andrew

[Lostgallifreyan]

Please try. I really want to know if it does work on WINE. It should, because it uses only API functions likely to be supported by even a minimal emulation of the original API.

About removal to access the innards of a RAM pack, the parting of shell cover from case alone can cause a static charge event capable of bother. There really is no substitute for a direct read in an emergency because any physical stress can risk loss. The amount of handling to get at the board, when the suspect RAM is still inside the Organiser, is beyond risky. If I realised I needed to save RAM from a low-powered Organiser I'd neglected too long, I'd not even be sliding the outer cover open rapidly. I'd handle it like sweaty gelignite. I'd get the thing read, in place, ASAP.