32k RAMPAK

[amenjet]

It turns out that the reason the RAM chips were slow in arriving was that I hadn't actually ordered them...

Depending on which exact 32K chip was used in the 32K RAM pack it looks like the 256 RAM chip has much lower standby current. Something between 5 and 100 times better. Probably down to more modern technology in the IC. Real world testing will show what reality has to say about it.

Andrew

[amenjet]

It is worth remembering that Rampacks are volatile, because any surge or disruption in power supply can result in losing all data, for example removing a Rampack whilst the organiser is switched on, or plugging a Comms Link in on a powered organiser. The main thing to remember is always BACK UP any important data before removing a Rampack. The problem of the battery running low is always going to be a problem, but at least having a replaceable battery makes it easier, and it is not a problem as long as any data is backed up.
There is nothing worse than seeing the dreaded “Sizing Pack....”, when you haven’t backed up the data from a Rampack.
I assume the 256k uses more battery power than the 32k, but I have never checked it out.

I think you should be OK with power dropout as the RAM pack has its own power supply. Fast transients could cause a problem I suppose. I'd be more worried by the WR signal (active low) going active for some reason while the organiser is powered down or during RAM pack removal. The RAM pack is never powered down so always looking for that WR signal. Also, don't put the bare PCB on a conductive surface...

Andrew

[amenjet]

I’m starting to have a go at the hardware side of things, (definitely inspired by Andrew) so I have laid out a 32k RAMPAK on breadboard. I deliberately went with the DIP equivalents to make it easier to wire. It’s been a long time since I’ve used breadboard, started all neat, then address and data lines are strewn all over the place!

I only made one tiny mistake, I omitted a link from the positive busbar on one side to the other. Link in; and it SIZED the pack and is working perfectly. I’ve omitted the battery, but interestingly when monitoring the supply from the PSION - 4.5V - if I remove the PSION battery, it takes a long time for the voltage to decay. Even getting down to 1.5V, the HM62256 held its memory.

Did you design your own circuit or use one from the Internet? i had a quick look at the 32K schematic on Jaap's site today and noticed a problem with it (specifically pin 1 of IC5A), which led me to think of you.

Andrew

[Zenerdiode]

Did you design your own circuit or use one from the Internet? i had a quick look at the 32K schematic on Jaap's site today and noticed a problem with it (specifically pin 1 of IC5A), which led me to think of you.

Yes, I used the schematic from Jaap’s site and I spotted that at the design stage. How can you pull a pin low with the input to a NAND gate?

But following the logic through, IC5A is used as a NOT gate; so when OE from PSION is high, WE is low and vice versa. Simply join pins 1&2. Here’s a copy of my check marking:

CF78A202-0DED-4D0E-A196-284E742BBD61.jpeg

BEDBD98A-E752-4424-9E9A-64CFBDF885E7.jpeg

Also, the HN58C256 shown is an EEPROM and does not work. Although the address and data setup times are in the nanosecond range, the total write cycle time is 10 milliseconds and must be too long for the PSION firmware. A bit like using a Flash Memory chip, the pk_xxx routines will have to be re-vectored. It states in the TechRef manual for the Flash Paks this is done, however I can’t find any of the vector addresses.

For my own experimentation I’d like to re-vector pk_setp to at least ask if I want to re-size a Pak. Does anyone know the addresses for the pak routines?

[amenjet]

Yes, I used the schematic from Jaap’s site and I spotted that at the design stage. How can you pull a pin low with the input to a NAND gate?

But following the logic through, IC5A is used as a NOT gate; so when OE from PSION is high, WE is low and vice versa. Simply join pins 1&2. Here’s a copy of my check marking:

Ah, good, so you did spot that. Yes, I have used the inversion of OE as WE as well and that must be the correct wiring, surely?

Andrew

[amenjet]

Also, the HN58C256 shown is an EEPROM and does not work. Although the address and data setup times are in the nanosecond range, the total write cycle time is 10 milliseconds and must be too long for the PSION firmware.

A bit like using a Flash Memory chip, the pk_xxx routines will have to be re-vectored. It states in the TechRef manual for the Flash Paks this is done, however I can’t find any of the vector addresses.

For my own experimentation I’d like to re-vector pk_setp to at least ask if I want to re-size a Pak. Does anyone know the addresses for the pak routines?

i didn't spot that an EEPROM chip is in the schematic. That's a bit odd. Presumably the organiser uses a different programming algorithm when it has seen a HWID of 1 (RAM pack) for the datapack and as you say, it won't work.

If you want to re-vector pk$setp, then I think you need to replace (or chain) the SWI vector 'bta_swi' listed on this page:

https://www.jaapsch.net/psion/sysvars.htm

Andrew

[Martin]

Chaps..

I'm watching the conversation from afar.. I don't really understand it but that said I do feel responsble for keeping the Technical Reference Manual Page up to date... So if you end up with a definitive schematic for the 32K Rampak then I could replace the one I have (here).

Sincerely
Martin

[amenjet]

Connecting pin 1 and 2 of IC5A does look to be the correct circuitry. It would be nice if KICAD files rather than image files were available as a PCB can be made directly from that without having to transcribe the image to a file and then create the PCB, which is more error prone.

Andrew

[Martin]

.
I realise that the 'topic' has moved on since Peter's comments about fact that Rampaks have a tendency to unexpectedly resize themselves. With this in mind I've completed some 'Backup' and 'Restore' tests and placed the results in a separate thread (here) so an not to distract from this topic.
.
In good faith
Martin

[amenjet]

I've never actually owned a RAM pack, but a few have passed though my hands, and I have some non functional MRAM and FRAM datapacks and a non functional 256K rampack, but are they really that unreliable? The flash packs I have seem to be bulletproof and I'd have thought the RAM packs would be the same, unless there was a large mechanical shock. The EPROM datapacks seem to last decades from what I've seen, with no data loss, what is the reason for the RAM pack problems, anyone know?

Andrew