256K RAM Pack

[amenjet]

I've made a batch of 256K RAM packs that have been sent off to Peter for sale.
In the process of doing that I made some extras, but unfortunately four of them have a PCB manufacturing fault that caused tracks to be cut. I have added wires and the packs are OK, but they could have reliability problems so I am thinking of donating to the forum as demo hardware or, if there's no interest in that then perhaps selling them. There's no case with these, if you want one then a standard datapack case can be used, but it has to be cut to fit the PCB and battery holder.
Any comments?

Andrew

[Martin]

Andrew

I think putting them up for loan is a great idea... I've created a special 'On Loan' forum thread in this hardware section and started the ball rolling with my spare XP. I have an LZ out for repairs at the moment and will add that when I get it back, this might be handy for XP users to see if they want to upgrade to an LZ.

Sincerely
Martin

[Zenerdiode]

I know some of Andrew’s testing of the RAMPAK is in the 64Kb thread (maybe admin, @martin could move it here?) but I think @Andrew was asking for as much SIZING information as possible?

If it helps, when I was a young’un in the late 80s I had an XP(LA) and used a 32K RAMPAK. It’s all I had, I bought the Organiser with my paper round money haha! But I needed some external storage as I was playing around with machine code programming. SIZING events of that RAMPAK were completely random, I had no top-slot devices and a fresh Duracell 9V. I didn’t use to chuck the Org about; in fact I think the greatest mechanical shock it got was if I closed the keyboard cover too harshly.

Could we re-vector PK$SETP to prevent a SIZING of the PAK, so the RAM could be read later to see what was corrupted? Although reading the Tech Ref, PK$SETP only checks the first byte of the PAK and if $FF, will then SIZE the PAK…

[amenjet]

That's an interesting idea, if it is possible to redirect the vector then the pack would be corrupt and maybe recoverable, if it is just the first byte that gets written erroneously.
Another way of protecting the data I thought about was to have a latch on the pack that write protects the data and is powered from the battery. You clear the protect before you write and set it when done. Then there's a 'lock' during other times. This does mean special code is needed, though, which isn't good. It could maybe be controlled with a timer, but then you have the problem that there's not a lot of room on the pack PCB.

Andrew

[Martin]

Hi all watching...

The Ram Pack test report 'post' @Zenerdiode referred to is on page 2 (here)

Martin

[1333david]

Hi These larger Rampacks sound great, but I just have a couple of questions:

In the PSION Rampack leaflet it mentions to remove the Rampack if inserting something into the top slot. I have a 32k Rampack and had an issue once with re-sizing when inserting the comms link. Is this Psion advice still relevant to the larger packs or should I presume the risk is negligible?

Is there any way of knowing the status of the battery in the Rampack before removing from the Psion? I guess best practise would be to move the data before removing the Rampack but I know I'd probably not do that!

Kind Regards,
David

[amenjet]

Hi These larger Rampacks sound great, but I just have a couple of questions:

In the PSION Rampack leaflet it mentions to remove the Rampack if inserting something into the top slot. I have a 32k Rampack and had an issue once with re-sizing when inserting the comms link. Is this Psion advice still relevant to the larger packs or should I presume the risk is negligible?

The advice is still sound. I have tested the 256K Rampack and resizing events are not as frequent as with an original 32K Rampack I also tested, but do still occur. I added circuitry to the 256K Rampack that wasn't on the original Rampacks (actually two distinct circuitry features, one using an extra CE on the RAM chip and one that holds the WE line high using the battery voltage even when the pack is removed) that is designed to try and prevent resizing events. Although better than the original 32K Rampack those event do, unfortunately, occur, and I cannot pin down exactly why. I decided to release the packs as they are at least as good as the originals.

Is there any way of knowing the status of the battery in the Rampack before removing from the Psion? I guess best practise would be to move the data before removing the Rampack but I know I'd probably not do that!

Kind Regards,
David

Unfortunately, no, not on this design.

[Martin]

Hi These larger Rampacks sound great, but I just have a couple of questions:

In the PSION Rampack leaflet it mentions to remove the Rampack if inserting something into the top slot. I have a 32k Rampack and had an issue once with re-sizing when inserting the comms link. Is this Psion advice still relevant to the larger packs or should I presume the risk is negligible?

Is there any way of knowing the status of the battery in the Rampack before removing from the Psion? I guess best practise would be to move the data before removing the Rampack but I know I'd probably not do that!

Hi again David

Check out the 'memory used for devices' in the Using Large Capactity Packs paper (here). If Jaap was still active he would be able to confirm (or not) my supposition about plugging and unplugging devices... As my artcle states any device when 'booted' ([ON] is pressed) places some code in the low RAM area used for devices and it is stored sequentially...

For example consider this boot code infor stored sequentially from beginning to end
(beginning)[Comms Link info][Flash Driver info][RAM Pack info]-----(end)

REMOVE the Comms Link and press [ON] the Comms link info is removed and the other 'stuff' is shunted up to take its place... I think it is this 'shunting' that upsets the RAM pack.

(beginning)[Flash Driver info moved up][RAM Pack info moved up]-------(end)

I've had no problem with this setup...
(beginning)[RAM Pack info][Spreadsheet info][Flash Pack info]-----(end)

When I plug in the Comms Link (either Serial or USB)
(beginning)[RAM Pack info][Spreadsheet info][Flash Pack info][Comms Link info]--(end)

and unplug it again later..
(beginning)[RAM Pack info][Spreadsheet info][Flash Pack info]-----(end)

The Comms Link info is just removed from the (end) no shunting required.

By the way while the Comms Link is connected I 'unmake' my (made by Andrew) 256K Rampak to a dated OPK file so I have a fairly recent backup just in case.

and finally finally... With Andrews replaceable battery Rampak - It is easy to 'unmake' the data stick a new battery in and reMAKE it.

Sincerely Martin

[Zenerdiode]

I’m so sorry, Martin, but it doesn’t quite work like that. RAMPAKS have a hardware byte encoded into them, which informs the OS that it is a Rampak. There are no drivers required for them, so if you ‘boot’ a rampak in on its own, check Utils>Devices and it will still show 0 bytes.

Also, when devices are booted by pressing ON-Clear, all devices are removed from memory first. Then the priority byte is checked in each device and the highest priority is loaded first. If there are two devices that have the same priority, they are loaded in the order of B: C: D:. The exception is the Flashpak that has the highest priority, but leaves a little bit of code behind when unbooted. This is why you have to use the FP menu to remove everything.

[Martin]

Thanks Chris... I'm learning something everyday.. How do you know the priority byte for each device?..

And I get it that a Rampak doen't boot code what I meant was that the 'spreadsheet' boots code and a top level menu item call. It's just that if I 'install' that first then I never get the dreaded 'resizing'.

Is there a list of priorities in the tech ref manual?

Sincerely Martin

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
EDIT / UPDATE

Hi again Chris...

Thanks again for the heads up regarding 'Device Priority' (Device Number)... I found it in the Technical Reference Manual and Jaap has a list of those he's found. From his list it appears that the pocket spreadsheet is one of the first devices to 'boot' after the Flashpak but before the Comms Link..

I'll need to edit the 'using large capacity packs' paper to reflect this.

Thank you again
Martin

Selection from Jaaps List.. Higher number boots first..

No. Device
09 Formulator
0A Concise Oxford Spelling Checker, OWI interface
0B Thesaurus and Spelling Checker
50 HB Games Pack
90 Bootable packs using Boot.BIN from the Organiser Developer kit.
C0 RS232 Link, Comms Link, Paralink (later versions)
C2 Psion Printer
C8 Pocket Spreadsheet
F7 Flashpak
F8 Flashpak