By: David Hess (davidwhess.delete@this.gmail.com), August 2, 2022 10:24 pm
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on July 30, 2022 10:43 pm wrote:
> David Hess (davidwhess.delete@this.gmail.com) on July 30, 2022 3:44 pm wrote:
> > David Hess (davidwhess.delete@this.gmail.com) on July 29, 2022 8:59 pm wrote:
> >
> > Last night I remembered another computer system which could start up exactly where it
> > left off after power loss; this was a feature of some systems which used core memory.
> > It was a small step from relying on core memory for program and data storage, to including
> > circuits to safely shut down and restart after power loss by saving CPU state.
> >
> > This could also have been done with a microprocessor and CMOS SRAM or even DRAM, but
> > I do not remember any systems which did it that way. Someone must have though.
>
> This is before my time but in the core memory days booting was kind of a pain
> in the ass, was it not? Even if you had the luxury of a hard drive you probably
> had to either toggle in a bootloader or load it via paper tape.
>
> That was probably the main reason that was used, not necessarily because they wanted to pick up where
> they left off - but if the PC, SP and registers were themselves stored in a type of core memory (or
> there was a big capacitor or something allowing a split second for them to be saved to core memory)
> then I guess theoretically it could simply pick up where it left off once power returns.
Core memory was contemporaneous with SRAM, DRAM, ROM, PROM, UVEPROM, and floppy disk storage. The oldest systems I worked on booted a monitor from UVEPROM which then booted from floppy disk, but embedded systems ran directly from UVEPROM. It was the mini-computers which commonly had core memory but they also booted from floppy disk or UVEPROM. Any combination was possible in an embedded system. Toggling in a bootloader was optional by then.
Low power CMOS SRAM suitable for battery backup did not exist yet though. It was sometimes done anyway with huge batteries to give only hours to days of backup time.
For an embedded system running from ROM and/or core memory, there was plenty of time after detecting loss of power to save the processor state, which is still the case today for many embedded systems. Back then it might be no more complicated than subroutine entry and exit.
> David Hess (davidwhess.delete@this.gmail.com) on July 30, 2022 3:44 pm wrote:
> > David Hess (davidwhess.delete@this.gmail.com) on July 29, 2022 8:59 pm wrote:
> >
> > Last night I remembered another computer system which could start up exactly where it
> > left off after power loss; this was a feature of some systems which used core memory.
> > It was a small step from relying on core memory for program and data storage, to including
> > circuits to safely shut down and restart after power loss by saving CPU state.
> >
> > This could also have been done with a microprocessor and CMOS SRAM or even DRAM, but
> > I do not remember any systems which did it that way. Someone must have though.
>
> This is before my time but in the core memory days booting was kind of a pain
> in the ass, was it not? Even if you had the luxury of a hard drive you probably
> had to either toggle in a bootloader or load it via paper tape.
>
> That was probably the main reason that was used, not necessarily because they wanted to pick up where
> they left off - but if the PC, SP and registers were themselves stored in a type of core memory (or
> there was a big capacitor or something allowing a split second for them to be saved to core memory)
> then I guess theoretically it could simply pick up where it left off once power returns.
Core memory was contemporaneous with SRAM, DRAM, ROM, PROM, UVEPROM, and floppy disk storage. The oldest systems I worked on booted a monitor from UVEPROM which then booted from floppy disk, but embedded systems ran directly from UVEPROM. It was the mini-computers which commonly had core memory but they also booted from floppy disk or UVEPROM. Any combination was possible in an embedded system. Toggling in a bootloader was optional by then.
Low power CMOS SRAM suitable for battery backup did not exist yet though. It was sometimes done anyway with huge batteries to give only hours to days of backup time.
For an embedded system running from ROM and/or core memory, there was plenty of time after detecting loss of power to save the processor state, which is still the case today for many embedded systems. Back then it might be no more complicated than subroutine entry and exit.
Topic | Posted By | Date |
---|---|---|
RIP Optane/XPoint | Wes Felter | 2022/07/28 07:53 PM |
RIP Optane/XPoint | Rayla | 2022/07/28 08:28 PM |
RIP Optane/XPoint | Doug S | 2022/07/28 09:00 PM |
RIP Optane/XPoint | NoSpammer | 2022/07/29 01:50 AM |
NVDIMM-N | Eric L | 2022/07/29 03:36 AM |
RIP Optane/XPoint | Michael S | 2022/07/29 04:02 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:40 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:43 AM |
RIP Optane/XPoint | Linus Torvalds | 2022/07/29 11:20 AM |
RIP Optane/XPoint | David Hess | 2022/07/29 08:59 PM |
RIP Optane/XPoint | David Hess | 2022/07/30 03:44 PM |
RIP Optane/XPoint | Doug S | 2022/07/30 10:43 PM |
RIP Optane/XPoint | rwessel | 2022/07/31 05:33 AM |
RIP Optane/XPoint | Konrad Schwarz | 2022/08/02 08:06 AM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:24 PM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:26 PM |
RIP Optane/XPoint | Adrian | 2022/08/03 01:19 AM |
RIP Optane/XPoint | anonymou5 | 2022/07/29 12:50 PM |
RIP Optane/XPoint | Gionatan Danti | 2022/07/29 09:09 AM |
RIP Optane/XPoint | Mark Roulo | 2022/07/29 10:02 AM |
RIP Optane/XPoint | dmcq | 2022/07/30 03:42 AM |
RIP Optane/XPoint | anon3 | 2022/07/31 10:19 PM |
RIP Optane/XPoint | anon2 | 2022/07/31 10:55 PM |
RIP Optane/XPoint | Doug S | 2022/08/01 08:37 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 01:33 PM |
RIP Optane/XPoint | NoSpammer | 2022/08/02 03:50 AM |
RIP Optane/XPoint | Doug S | 2022/08/02 09:24 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/02 10:34 AM |
RIP Optane/XPoint | --- | 2022/08/02 10:39 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 03:48 AM |
RIP Optane/XPoint | Michael S | 2022/08/03 06:04 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 08:56 AM |
RIP Optane/XPoint | Adrian | 2022/08/01 02:15 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 06:07 AM |
Losses vs not profitable enough | Mark Roulo | 2022/08/01 10:15 AM |
Losses vs not profitable enough | dmcq | 2022/08/01 11:50 AM |
Losses vs not profitable enough | Gionatan Danti | 2022/08/01 12:34 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 02:47 PM |
RIP Optane/XPoint | Anon | 2022/08/01 03:09 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 03:32 PM |
RIP Optane/XPoint | Groo | 2022/08/01 12:28 PM |
RIP Optane/XPoint | anon3 | 2022/08/01 10:33 PM |
RIP Optane/XPoint | Groo | 2022/08/03 11:15 AM |
RIP Optane/XPoint | --- | 2022/08/03 03:05 PM |
Latency | David Kanter | 2022/07/29 06:35 PM |
Operating system and driver overhead | Eric L | 2022/07/29 03:44 AM |
Operating system and driver overhead | Linus Torvalds | 2022/07/29 10:45 AM |
altrernatives? | Michael S | 2022/07/29 05:17 AM |
altrernatives? | Rayla | 2022/07/29 06:49 AM |