Removing FRAM71 Memory Modules?

[Dave Frederickson]

What's the best way to remove a FRAM71 memory module from the configuration string?

It sounds like a trivial question and that simply POKEing zeros into the appropriate place in the config string is all that's necessary. This is like pulling out a physical memory module without FREEPORTing it first.

FREEPORTing the module first and then POKEing zeros in the config string does remove the module safely, but what happens when the F-Blocks are reused? Unlike volatile memory modules, FRAM never forgets! A reconfigured F-Block that was previously FREE'd this way will come back to life as an IRAM or ROM. What's worse is if the the F-Block was part of a multi-Chip module and the module is reconfigured with missing Chips. The 71 is likely to crash.

I suggest that a better way might be to FREEPORT the module, POKE zeros over the IRAM identifier, then remove the module from the configuration string. This way when the F-Block is reconfigured it comes back as RAM and is erased.

Has anybody experimented with this?

Dave

[Hans Brueggemann]

(10-17-2015 03:02 PM)Dave Frederickson Wrote:  What's the best way to remove a FRAM71 memory module from the configuration string?

It sounds like a trivial question and that simply POKEing zeros into the appropriate place in the config string is all that's necessary. This is like pulling out a physical memory module with FREEPORTing it first.

Well, that somehow would give the impression that you could place those zeroes just anywhere in the configuration string, which is not the case. the configuration string must be contiguous. putting zeroes in the middle of the config string masks out the remainder of the config that follows after the zeroes.
for example,
"9394959600.." gives 4 x 32KB RAM, while
"9394009600.." gives only 2 x 32KB RAM, and the RAM at F_Block6 will be ignored.
the reason for that is how HP-71B's config routine interacts with FRAM71's "DIN/DOUT"- handling at power-on: a CHIP in FRAM71 that has its config nibble set to zero is considered to be "not there" (will not respond to an "ID" command) and also will not pass on its "DOUT" dasy-chain signal to the the following chip. thus, the HP-71B doesn't get any further ID response and assumes that there are no more chips to be configured. so, for the above example, the chip formerly known as "95" won't be detected, and chip "96" never gets the "DIN" signal, because "95" doesn't pass it over to "95".

[Dave Frederickson]

Hi Hans,

So the "appropriate place" would be at the end of the configuration string, taking out any other modules as necessary.

For sake of arguement, let's say the module is at the end of the configuration string.

How would you safely "remove" a RAM device?

Dave

[Hans Brueggemann]

safest way that comes to my mind is:
1. FREEPORT(5.xx) // if it is IRAM already, skip this step
2. CLAMPORT(5.xx) // kill all contents of that port, and make it empty RAM
3. POKE"2C000", "...00" // POKE two zeroes into the rightmost positions of the config
4. power cycle

[Dave Frederickson]

When the port is CLAIM'ed in Step 2 memory will be reconfigured. Depending on the size and port number this could be at a low memory address where there could be programs. There's no guarantee that the CLAIM'ed RAM will be empty and the file chain could be corrupted.

As with a physical memory module, devices must be FREEPORT'ed before being removed.

Think of this as a 32k memory module vs a 64k memory module with a battery. When a 32k module is removed it soon looses it's contents and when plugged back in reappears as RAM. The 64k module doesn't loose it's contents and comes back as an IRAM. In the case of FRAM71, maybe only half an IRAM.

My technique reconfigures the device to RAM before being removed from the configuration string so it behaves like the non battery-backed memory module.

Dave