I'm not sure if this is documented anywhere, I can't explicitly see anything:
While messing about doing things I accidentally erased a datapack which was an original Psion pack with a program on it. It was for the Psion 1 but I don't think that's important. No problem I thought, I'll just reprogram it. After several reprogramming attempts I failed to program the pack. After a flash of inspiration I checked the PCB and found that the VPP signal wasn't connected to the EPROM. So, even though it looks like a datapack and has most if not all of the same circuitry, it is not writeable. I didn't know that Psion did this, I assumed their programs were on normal datapacks with a write-protected bit in the header.
On the PCB:
you can see that pin 1 just goes to 5V, not the VPP signal.
Anyway, maybe this is common knowledge, but I was surprised.
Andrew
Read Only datapack
-
- Posts: 211
- Joined: Tue Jan 03, 2023 7:54 pm
Read Only datapack
You do not have the required permissions to view the files attached to this post.
- Martin
- Global Admin
- Posts: 227
- Joined: Mon Jan 02, 2023 5:18 pm
Read Only datapack - CPWRT
Andrew have you seen this utility that Alexandre wrote?
. .
EXTRACT from CPWRT.txt
CPWRT
~~~~~
By Alexandre Bouillot, 1989. - Translated into English by Christophe Guilloux.
This program can Protect a Datapack against Copying, Writing or both... When a Datapack is protected, it's impossible to deprotect.
If you Protect a RAMPACK, it will become completely UNFORMATTABLE !!!
Christophe.
From "Bulletin Technique" by AWARE - April, may and June 1989
P.S : Don't try to modify this procedure if you are not a machine code programmer... (If you are, remember to Save all your stuff first !)
-----------------------------------------------------------------------------
Jaap's Psion II page: Software written by others
. .
EXTRACT from CPWRT.txt
CPWRT
~~~~~
By Alexandre Bouillot, 1989. - Translated into English by Christophe Guilloux.
This program can Protect a Datapack against Copying, Writing or both... When a Datapack is protected, it's impossible to deprotect.
If you Protect a RAMPACK, it will become completely UNFORMATTABLE !!!
Christophe.
From "Bulletin Technique" by AWARE - April, may and June 1989
P.S : Don't try to modify this procedure if you are not a machine code programmer... (If you are, remember to Save all your stuff first !)
-----------------------------------------------------------------------------
Jaap's Psion II page: Software written by others
You do not have the required permissions to view the files attached to this post.
-
- Posts: 211
- Joined: Tue Jan 03, 2023 7:54 pm
Re: Read Only datapack
No, oi hadn't seen that before. It looks like it adjusts the header flags. The tool I was using when copying packs was a hardware tool and can copy protected datapacks. Well, as long as the one being written to has Vpp connected...
Andrew
Andrew
-
- Posts: 83
- Joined: Thu Jan 12, 2023 8:25 pm
Re: Read Only datapack
I think one of the versions of 'Unmake' can read a protected pack by ignoring the copy-protect bit. I used its Psion code in ORG-Link. I can't remember what I did now, but if you have ORG-Link you could try copying a protected pack to see if it can.
That write-protect by hardwiring a pin to 5V is nice. It might be very helpful for some packs where rigorous protection of code and data is wanted, while still having a chance to undo it at will if after some years a bug or other error needed fixing in the content of a pack. I usually have a RAM pack in Slot B, and a big flash pack in Slot C for main data lookups and any procedure I need to support new work (a bit like a store of DLL's in a modern system). A big flash pack might do well with a hardwired protection like this, it beats trying to do it by removing the driver because that's never certain anyway, Other packs can end up loading a flash driver. There are times when it pays to know that NOTHING can harm that storage short of a lot of brute force.
That write-protect by hardwiring a pin to 5V is nice. It might be very helpful for some packs where rigorous protection of code and data is wanted, while still having a chance to undo it at will if after some years a bug or other error needed fixing in the content of a pack. I usually have a RAM pack in Slot B, and a big flash pack in Slot C for main data lookups and any procedure I need to support new work (a bit like a store of DLL's in a modern system). A big flash pack might do well with a hardwired protection like this, it beats trying to do it by removing the driver because that's never certain anyway, Other packs can end up loading a flash driver. There are times when it pays to know that NOTHING can harm that storage short of a lot of brute force.