battery-backed SRAM

We had a PDP-11 with core memory and the entire thing was treated as non-volatile. I recall one of the users saying it could be halted, powered down and back up picking up right where it left off like putting your laptop in sleep mode except no recovery wait.

Yes. A tech at my first job (in the medical research department of the University of Melbourne) maintained a PDP11/40. During the two years I was there, there were two occasions where he debugged the hardware by manually single-stepping through the micro-code.

That's dedication! Very smart guy, who for some reason always said "ternimal" when he meant "terminal"; he didn't seem to be able to hear the difference even when it was pointed out.

Clifford Heath.

VMUnix used to do that. Later, a colleague was working on smart extensions to the HP-UX kernel panic dump, because they had built systems with 24GB of RAM, but disk speeds were still so slow that a full dump would take 24 hours - just to shut down! Clearly not acceptable, so he was charged with building in some smarts to figure out what most likely went wrong and what information might be most useful in tracking down the cause.

Clifford Heath.

As I recall, on the operating system I worked on in college, core was normally reinitialized after a reboot.

The "software check" (system-crash) routine in the OS would dump all of core memory out to a reserved area on the swapping/paging device before restarting, in order to allow post-analysis of the crash. At most, a few words of core memory might be preserved across the reset and reinitialization process.

PDP-11 has a power fail interrupt, which saves all (volatile) CPU registers into the stack in core and then halts the processor. Upon power restoration the same interrupt was executed gain, the saved registers were restored from the core and off you go from the next instruction as nothing had happened. Of course, there might be some issues with the RTC :-) i.e. a time gap.

Also hardware single stepping was not an issue, it worked fine.

Later systems with DRAM main memory with _memory_ battery backup (but not CPU battery backup) worked as well when CPU power was lost, just continue from next instruction.

I also worked with a DDP516 system from the 1960's which was supposed to have a write protected core area for some critical software "BIOS". Unfortunately sometimes the write protection failed, either by write protection failure, or possibly a memory controller failure due to power failure. After each core location read that memory location had to be written back. A power failure at this stage might cause problems.

After such a failure, one had to load in the key-in-loader into specific memory locations. before the computer would be able to read a few meters of paper tape and then execute the disk loader to load the OS. Fortunately the key-in-loader was only 16 words, so entering it with front panel binary switches was not an issue, since soon you could do that by hart.

At the small company I work, we have a old Cheap time clock. I works. Has a 3032 battery for backup, receintly changed it and it's good for another 10 years.

Cheers

Not quite - the processor can be restored to what it was doing before the power disappearance, but the peripherals are quite off the original situation when the power returns.

The processor is actually quite lost if power drops when an interrupt service is being run. If we just continue the served periphera may be quite astonished.

We could do something like that. Serial flash chips are huge, so we could also rotate the write address so we don't wear out one spot. But the fram looks cool, without tricky programming. Per bit, it costs a few thousand times flash, but we don't need a lot of storage.

Long ago, around the turn of the millennium, I built a gizmo called Footprints that used an Atmel flash chip as a reasonably giant circular buffer built as a singly-linked list, LIFO fashion. I didn't pay too much attention to power failure issues, but good wear levelling was automatic in that architecture. It took about 5 kB/s worth of data, which was pretty easy to deal with.

Cheers

Phil Hobbs

I had a PDP-11/35 (and a /34 and /45, though with semiconductor memory) that we rarely reloaded the core. We just halted it and powered it off when we went home. In the morning we just toggled in its start address and hit the reset button and it was up and running. We didn't reload core because it could take an hour with the teletype and the technicians got pissed when we did. ;-)

I'd have thought that the endurance would be more than adequate then, particularly if you wait until the knob twiddling has ceased for a short while.

Sylvia.

This situation is tailor-made for FRAM (ferroelectric RAM). We have been using 512 bytes FRAMs in process instruments to collect some log data sinc the first FRAMs started to be available. The chips are written once a second, and there has been no failures yet.

You can filter so that only new setups are written, but it is IMHO not necessary if it feels too complicated.

Some of the instruments are writing in a journaled fashion: first write to the journal, where the write is going to happen and what to write, then copy the data from journal to the final location and last mark the journal entry obsolete. Even this has not caused undue write wear.

FRAM does sound like the best way to go. We could save the current instrument setup periodically, every second maybe, and not worry about endurance. I'd like to write two or four copies in rotation, just in case something goes wrong, like a bit error or a powerfail during a write.

Something like this would do nicely:

We will also probably have a Linux file system in parallel flash. We could save the current setup as a file, and hope that the file system does some wear levelling for us, but then we are wearing out the entire flash chip.

Setup changes can also come from USB or Ethernet, and there's no telling how often some user might change things, like sweeping a pulse amplitude or something. So change detection has its own hazards. The FRAM periodic save thing is appealingly mindless.

The chips I'm using are FM24CL64 and FM24CL04B, but they are with I2C interface. SPI is probably better: There is a situation when the I2C bus can lock up if the bus master is reset at an inappropriate moment.

I still have a PDP-11/10. Its core memory keeps the content forever (well, the last program that was stored, still ran after like 20 years of power down when I got it). Core memory is huge by today's standards however :) Frank

Google tormat memory

The PDP-11 could be shut off when running, and resume at power-on, not requiring a re-boot.

The IBM 360 saved information that could be recovered at power-on, but they didn't support restart without re-IPL'ing.

I'm pretty sure the Data General Nova line also saved core contents when powered down.

Going way back, PDP-8's, LINCs and other machines all saved core on an orderly power-down, I think most of them also did so on an unscheduled power fail.

Jon

No, even further! At least some models could be left unattended, suffer a power fail, then come back up and continue right where they left off, with nobody to even press a switch.

I know I did this with our 11/45 a few times. The OS needed to save a bunch of device status when notified of the power fail and then restore the devices to the right condition when recovering. This was standard stuff for RSX-11M, which was used for process control.

Jon

There are filesystems in Linux tailored for parallel Flash, called MTD devices (Memory Technology Device), JFFS2, YAFFS and others. They worry about wear leveling for you.