Good descriptions. Thank you! We can stop one clock by starting another. I think we can safely say the high speed system clock will be taken offline/suspended in the manner described and in the capacity that's in agreement with the Propeller chip's hard wiring, which is do the work with the higher speed clock, at the required speed but no more, and pop down into rc slow mode or rc fast mode for power savings. A lot of things can happen in rc fast or rc slow modes, especially when the machine is wired in parallel, and remain transitively fast. Mike Green has defined a way to calibrate the slow clock. http://forums.parallax.com/showthread.php?133063-DIY-External-RC-Clock
Seems like Mike Green have hit the spot dead-on. They can be quite stable as long as you keep the cabinet thermally-controlled.
As far as external clocks are concerned, I just go full speed on PLL = x16 for software bring-up then brought down by steps; x16 > x8 > x4 > x2 > x1 then complete oscillator shutdown, instead running off internal oscillator. Personally, I would go with x1 for my project as MEMS oscillators are quite efficient (about 6mA). Your mileages with x1 clock low power mode varies: it simply depends on how much power your clock generator consumes. SiTime SiT8003 consumes 6mA, but again, it's the COGs' speeds that really determine the current consumption, depending on PLL clocking settings.
Oh, and prof_braino, I re-read some part of your post, you're correct about handshake protocol. It's how some industrial battery-operated equipment controllers/instruments deal with current consumption by going idle (clock slowed down) until they're awaken by the handshake data, and accepting user inputs afterward.
As far as external clocks are concerned, I just go full speed on PLL = x16 for software bring-up then brought down by steps; x16 > x8 > x4 > x2 > x1 then complete oscillator shutdown, instead running off internal oscillator. Oh, and prof_braino, I re-read some part of your post, you're correct about handshake protocol. It's how some industrial battery-operated equipment controllers/instruments deal with current consumption by going idle (clock slowed down) until they're awaken by the handshake data, and accepting user inputs afterward.
Dr. Mario: Thanks for this information. When you say complete oscillator shutdown, how is that accomplished? I thought this was not possible? You mean Cog shutdown? How would the code look?
Some oscillator allow that - you may need to check your datasheet, though. Other than that, you can pull OE / ST pin down, it just shut down active electronics - SiTime Si8003 shuts down completely since the MEMS just restart instantly, so no point in put the whole chip in idle state. The OE / ST pin can be tied to a P8X32A pin if necessary (but be careful, wrong timing between speed switch can leave P8X32A clockless or worse, the PLL can be blown).
Some crystal-based oscillator allows that too, but it takes a bit longer to stabilize concerning temperature stability (OCXO exists, in fact, if you're concerned but it's very expensive, so TCXO is the better option). Just something to take note, though.
Cog shutdown is normally accomplished by Cogstop, though.
Realtime response means "responding in the time allotted" for a given event. The system must run a a given minimum speed to process the event in the required time.
In between events, the system does not need to process any events this quickly. It only needs to "wake up" and bring itself up to speed to process the next event in sufficient time.
To conserve power, the technique is to minimize transistor state transitions. This is done in two ways: 1) stop the processor (cogstop) when possible and 2) slow the clock (change PLL multiplier, switch to RCslow, or control the external clock speed directly).
Is it true that at least one cog must be left running to listen for the wake up signal and wake the other cogs?
The "clockless" idea has to be part of the parts' design, so a prop cannot be made "clockless" internally. But a prop can generate clock signal for another prop, so we can use a prop and its generated clock signal and use it as handshaking scheme for additional props.
An external clock can be controlled by the prop software or other means. But an external part would tend to draw more power than the internal prop oscillator.
So the answer to the thread is not necessarily power based on code, but rather power based on clock speed. So the goal is the slowest possible clock during sleep, and the slowest sufficient clock during wake.
An external clock arrangement might draw more power, it this per transition or continuous? For example could a very slow and not necessarily stable or accurate external clock arrangement draw less power overall than the RCslow, and wake the system to it's very fast and accurate regular clock?
Dr Mario has the SiTime SiT8003 at 6mA; another thread talked about RC circuit and CMOS transistors. Could something like one of these run very slow and draw less than the internal oscillator?
I'm assuming this is for something like a battery powered device than can sit running for extended periods at low power mode but needs to wake up and run fast?
I remember seeing something where a devices in low power mode drew about the same as the battery was expected to loose due to shelf life. Is this something that can be done with a prop?
For example could a very slow and not necessarily stable or accurate external clock arrangement draw less power overall than the RCslow, and wake the system to it's very fast and accurate regular clock?
Prof_Braino, excellent considerations. Thank you. I've centered on this one point. I asked a similar question in this thread. http://forums.parallax.com/showthread.php?133063-DIY-External-RC-Clock I got very good answers, but my mind is still thinking about an external circuit of great simplicity, a clock from very slow to stop along with a way to make variable power draw. Yes, we can't change the internal wiring of the prop but we can add external wiring and shift the focus to there with software.
Well, I have my SiT8003 programmed for 5MHz operation, and I considered 6mA good enough for my own project, as I like to have very precise timing reference, and that stuff has better shock toleration.
That's fine with regular disposable AA batteries as they will usually supply enough juice to keep P8X32A happily operating for few days, and much longer with Lithium-Ion batteries (I have couple 18650s, and they're quite powerful - I have done a "DO NOT TRY AT HOME" torture test on it, and I didn't blow it, since I knew better - the short-circuit current: 40 Amps). I think with 18650 Li-Ion battery, it could be maybe few weeks. I am going to toy with that kind of idea (maybe a portable storage geiger counter, as I work with X-rays - it would be very handy to have one. Battery life time is very important here.)
And, prof_braino, VERY good description. And, it's possible for P8X32A to match the internal leakage current in the batteries (that they lose life on the shelf for long time) during idle state, but again, it really depends on battery size and its post condition. Will it happen with CR2032? Nah, forget it. It's considered too much in the Lithium CR2032 batteries' point-of-view. Lithium-ion 18650? Yup, it could sideline with this battery's life expectancy, and it could also last for few weeks on frequent rev-ups and idling.
And, yes, the first Cog will need to stay on, since it's a bootstrapping processor - stop it, the whole thing resets. That's how I view it, never have performed the real Cog killing task on just a Cog, but I could imagine it will do funny thing if you do that. If you have multiple Cogs operating, and you kill the bootstrap Cog, it won't happen, only if you have just one running, though.
One cog remains the night watchman. He can operate at the lowest frequency and power and keep the program going. There is a way to turn on/off chips using the watchman but it's more complex and I don't want to involve any more components.
Watchman control can be left completely to software, which save the component costs, like with some intelligent inverters containing the microcontroller chip.
The Propeller is a static chip which means that the clock can go down to zero. The chip is effectively stopped at that point, so it can't respond to external (or internal) events. You could have an external RTC with a 1Hz output and use that for a clock and the Prop would run very very slowly. You're not going to gain much though. As I've mentioned before, the RCSLOW clock is plenty slow enough to reduce power consumption significantly in the clock circuitry and, with all cogs either stopped or waiting using WAITCNT or WAITPNE/WAITPEQ, the overall chip power consumption will be very very low.
The RCSLOW is good enough for simple software routines, although a bit higher speed, RCFAST may be needed to bring some software up, then leave at it. I suggested that the oscillator can be shut down by toggling the OE pin of the oscillator with a pin from P8X32A chip, to turn it off if necessary.
I added more data on the RCSLOW setting. Three voltages, 3.3, 3.0 and 2.7. One to three cogs running, with or without a wait state. This is with the internal brownout enabled (2.6 V), a 24LC256 eeprom, room temperature. Currents measured with an HP34401 6.5 digit bench multimeter.
Each new cog executing Spin code adds 3 microamps, and each cog in a waitxxx state adds about 0.5 microamps, at 3.3 V. The base current (one single cog in a wait state) was 7.7 microamps (sample of one).
So, if a battery pack has 4 * (AA) alkaline rated 2700mAh 1.5V with six years shelf life;
and 1 cog running RCSLOW
does this mean 2700 mAh / 0.0084 milliamps = 32,142 hours, equals 1,339 days, equals 3.6 years
I.E. over three years of standby using RCSLOW and one cog?
Interesting that the voltage variance really affect the current consumption...
I think it is possible that it would last very long on 4 AA batteries, probably close to 3 - 4 years, concerning the internal current leakage inside the batteries.
And, Tracy Allen, thanks for the measurement! It's very useful in term of comparing the currents consumed by the on-die clock generator (RCSLOW and RCFAST). I would implement this for my battery-operated hardware containing P8X32A processor, for stand-by function.
I've explored these low power modes over a year. I built this MC Computer http://forums.parallax.com/showthread.php?124495-Fill-the-Big-Brain&p=1020034&viewfull=1#post1020034
to play around with low power battery operations with one Propeller chip and do programming in Binary. Yes, it can stay active for years in standby mode. Much of this play was operating the computer with the lowest possible power and observing the lowest voltage at which it would continue to function along with current draw.
Homebrewed Propeller MC Minimal Computer can
remain live in standby mode for years
Humanoido, amazing. It reminds me kinda like Mark-5 tactile-switch computer. And, I am amazed that the whole computer could stay in standby mode for so long on the batteries.
Humanoido, amazing. It reminds me kinda like Mark-5 tactile-switch computer. And, I am amazed that the whole computer could stay in standby mode for so long on the batteries.
Dr. Mario:
Thanks. The MC computer is a mix of the Mark 8 from Radio Electronics magazine (Jon Titus) and the MITS Altair 8800 computer.
Humanoido,
That's how I want my PropAltair running Zicog and CP/M to look. Never thought to have it run from batteries and sit in standby mode for years though.
No surprise you batteries last a long time, according to the picture you have forgoten to turn on the power switch:)
've explored these low power modes over a year. I built this MC Computer http://forums.parallax.com/showthrea...=1#post1020034
to play around with low power battery operations with one Propeller chip and do programming in Binary.
I feel dense when I read some of your posts Humanoido. What is the relationship between you Minimal Computer and the Prop? Is there a prop inside the box? Are you programming the Prop in Binary or the Altair?
Humanoido, I apologize - it should be Mark-8, not 5... My bad. From what I readed, Altair 8800 was the first DIY computer ever sold to the public (or was it IMSAI 8080? Either way, they were sold to public as a DIY kits - very difficult task but it hasn't stopped the original Captain Crunch - BTW, he was very famous computer hacker in the history book.)
Either way, it's a very nice thing to hear, that your own Altair-style computer did last long enough on those batteries in standby mode.
Humanoido,
That's how I want my PropAltair running Zicog and CP/M to look. Never thought to have it run from batteries and sit in standby mode for years though.
No surprise you batteries last a long time, according to the picture you have forgoten to turn on the power switch:)
I used this computer so much that many of the toggle switches wore out and were replaced. When the off switch stopped working, there was no need to replace it.
What is the relationship between you Minimal Computer and the Prop? Is there a prop inside the box? Are you programming the Prop in Binary or the Altair?
Humanoido, I apologize - it should be Mark-8, not 5... My bad. From what I readed, Altair 8800 was the first DIY computer ever sold to the public (or was it IMSAI 8080? Either way, they were sold to public as a DIY kits - very difficult task but it hasn't stopped the original Captain Crunch - BTW, he was very famous computer hacker in the history book.) Either way, it's a very nice thing to hear, that your own Altair-style computer did last long enough on those batteries in standby mode.
Dr. Mario:
Thanks. It's easy to mix up those numbers after 40 years. The Mark-8 helped launch the microcomputer world. That Radio Electronics magazine article was fantastic. I remember seeing "advertising" for the Altair and then IMSAI appeared as a second player. Altair was challenging to assemble - nothing like the efficient low power Propeller chip circuit we have today!
I liked the computing history so much (despite the fact that I am in my 20's) so I went deeper to get to some interesting fact - here's the website: www.oldcomputers.net and you will see so many old computers and some nice, interesting tidbits that goes with it. I have never used IMSAI or Altair before, but would like to try and construct one someday.
Concerning the IMSAI 8080 and Altair 8800's power consumption, they were run off thick and heavy transformer (pretty much like a microwave oven transformer except they were run at lower voltage) with linear regulators and HUGE low-dropout electrolytic capacitors - the first computers with SMPS didn't appear until 1982 - '84. They were so power-hog compared to the today's 32nm tower computer.
For you interested in IMSAI, there's the computer project in the making: www.imsai.net and yep, they're now power-efficient, and better than the original IMSAI 8800 (same key setup, though).
Would you be willing to share the schematic of your Minimal Brain for your Propeller brethren? I built an Altair in 1975, (yes Dr. Mario, before the IMSAI), and would like to know how you handled setting the address lines and then clocking the data into RAM. This would be a great small learning project for young people.
Concerning the IMSAI 8080 and Altair 8800's power consumption, they were run off thick and heavy transformer (pretty much like a microwave oven transformer except they were run at lower voltage) with linear regulators and HUGE low-dropout electrolytic capacitors - the first computers with SMPS didn't appear until 1982 - '84. They were so power-hog compared to the today's 32nm tower computer.
I remember large electrolytic capacitors that were so dangerous you could do welding with a bare screwdriver just by touching charged terminals.
Publison, here's a verbal schematic: the MC stands for Minimal Computer and keeping up with its name, it contains only a prop chip and no components. It was further simplified to run on two batteries without the regulator. There's no EEPROM. Program is stored in RAM as the power is kept on for long time periods. It has just the usual lights and switches and with the large number of available ports on a Propeller chip ends up as a direct one to one relationship, ie 16 switches and lights to 16 pins.
Publison, here's a verbal schematic: the MC stands for Minimal Computer and keeping up with its name, it contains only a prop chip and no components. It was further simplified to run on two batteries without the regulator. There's no EEPROM. Program is stored in RAM as the power is kept on for long time periods. It has just the usual lights and switches and with the large number of available ports on a Propeller chip ends up as a direct one to one relationship, ie 16 switches and lights to 16 pins.
Verbal Schematic, what that heck is that? You have nothing to show?
So.. it does absolutely nothing and is not programmable. Well that's pretty consistent of all your threads. I thought you had something to offer, instead of a pretty panel. Can we at least have a peak inside?
Funny you should mention, Humanoido, I have a salvaged 50V, 80,000uF capacitor - an interesting toy (interesting = dangerous).
In your verbal schematic - no EEPROM? It would be difficult unless you keep your main PC tethered to it, although in my honest opinion, it would be fine as long as the reset button is not pushed, or the batteries removed. I personally prefer to have something to hold the "hard-copy" so that way the computer will know what to do once it boots up - I screw up on programming sometimes so resetting may be necessary. And, the floppy disk drive saps juice from the batteries so it's also a good idea to have EEPROM (FRAM is not really needed here as Altair is basically a Turing-complete computer, meaning the input is read-only, although they're eventually modified to be able to hold whatever's inputted onto the monster 8" / 5" floppy disk drives and HUGE*** hard drives - although it wouldn't hurt to have one in there).
Otherwise, the large EEPROM is not necessary, as the operating system can be tiny as 512 bytes. 32KB EEPROM is fine for future expansion or just what it is gotten on hand.
Publison, Neat! For some reason, whenever I come over ancient computer hardwares that I can touch, it was kind of more like religious experience. Owning an Altair is certainly more than that, though - it's a piece of history! And, I definitely agree with you, constructing an Altair (at least the "me-too" clones of Today, even the one that involves P8X32A as a CPU) would be very educational for young peoples wanting to learn about the VERY early part of home computing history.
From what I have heard and readed a PDF of BYTE magazine (Sept. 1975 - "Assembling an Altair") that I still have somewhere on my second 500GB hard drive, it was very tedious task (so much ICs to be soldered and tacked onto the boards), yet you profit from the fruit of labor, and it was also entertaining reading throughout BYTE magazine as it got lot of useful troubleshooting methods on Altair too. (It also could be used to troubleshoot rather complex circuitry that involves Propeller, although the high-speed (100MHz) oscilloscope may be needed to probe the chosen wire / trace to find out what's going on here, though).
Edit: I found the mentioned magazine - I wish I could upload it to share with you guys, but unfortunately, I felt it's WAY TOO BIG for uploading (62MB) - and I have tried tarball - no change in file size (I have nearly overheated my CPU this way..... T_______T) Anyways, to save us both trouble, I have posted the link to the BYTE archival: http://www.sxlist.com/techref/article/byte/index.htm - you still can google it up if you want under the keyword: BYTE magazine - "Assembling an Altair"
Comments
Good descriptions. Thank you! We can stop one clock by starting another. I think we can safely say the high speed system clock will be taken offline/suspended in the manner described and in the capacity that's in agreement with the Propeller chip's hard wiring, which is do the work with the higher speed clock, at the required speed but no more, and pop down into rc slow mode or rc fast mode for power savings. A lot of things can happen in rc fast or rc slow modes, especially when the machine is wired in parallel, and remain transitively fast. Mike Green has defined a way to calibrate the slow clock. http://forums.parallax.com/showthread.php?133063-DIY-External-RC-Clock
As far as external clocks are concerned, I just go full speed on PLL = x16 for software bring-up then brought down by steps; x16 > x8 > x4 > x2 > x1 then complete oscillator shutdown, instead running off internal oscillator. Personally, I would go with x1 for my project as MEMS oscillators are quite efficient (about 6mA). Your mileages with x1 clock low power mode varies: it simply depends on how much power your clock generator consumes. SiTime SiT8003 consumes 6mA, but again, it's the COGs' speeds that really determine the current consumption, depending on PLL clocking settings.
Oh, and prof_braino, I re-read some part of your post, you're correct about handshake protocol. It's how some industrial battery-operated equipment controllers/instruments deal with current consumption by going idle (clock slowed down) until they're awaken by the handshake data, and accepting user inputs afterward.
Some crystal-based oscillator allows that too, but it takes a bit longer to stabilize concerning temperature stability (OCXO exists, in fact, if you're concerned but it's very expensive, so TCXO is the better option). Just something to take note, though.
Cog shutdown is normally accomplished by Cogstop, though.
Realtime response means "responding in the time allotted" for a given event. The system must run a a given minimum speed to process the event in the required time.
In between events, the system does not need to process any events this quickly. It only needs to "wake up" and bring itself up to speed to process the next event in sufficient time.
To conserve power, the technique is to minimize transistor state transitions. This is done in two ways: 1) stop the processor (cogstop) when possible and 2) slow the clock (change PLL multiplier, switch to RCslow, or control the external clock speed directly).
Is it true that at least one cog must be left running to listen for the wake up signal and wake the other cogs?
The "clockless" idea has to be part of the parts' design, so a prop cannot be made "clockless" internally. But a prop can generate clock signal for another prop, so we can use a prop and its generated clock signal and use it as handshaking scheme for additional props.
An external clock can be controlled by the prop software or other means. But an external part would tend to draw more power than the internal prop oscillator.
So the answer to the thread is not necessarily power based on code, but rather power based on clock speed. So the goal is the slowest possible clock during sleep, and the slowest sufficient clock during wake.
An external clock arrangement might draw more power, it this per transition or continuous? For example could a very slow and not necessarily stable or accurate external clock arrangement draw less power overall than the RCslow, and wake the system to it's very fast and accurate regular clock?
Dr Mario has the SiTime SiT8003 at 6mA; another thread talked about RC circuit and CMOS transistors. Could something like one of these run very slow and draw less than the internal oscillator?
I'm assuming this is for something like a battery powered device than can sit running for extended periods at low power mode but needs to wake up and run fast?
I remember seeing something where a devices in low power mode drew about the same as the battery was expected to loose due to shelf life. Is this something that can be done with a prop?
That's fine with regular disposable AA batteries as they will usually supply enough juice to keep P8X32A happily operating for few days, and much longer with Lithium-Ion batteries (I have couple 18650s, and they're quite powerful - I have done a "DO NOT TRY AT HOME" torture test on it, and I didn't blow it, since I knew better - the short-circuit current: 40 Amps). I think with 18650 Li-Ion battery, it could be maybe few weeks. I am going to toy with that kind of idea (maybe a portable storage geiger counter, as I work with X-rays - it would be very handy to have one. Battery life time is very important here.)
And, prof_braino, VERY good description. And, it's possible for P8X32A to match the internal leakage current in the batteries (that they lose life on the shelf for long time) during idle state, but again, it really depends on battery size and its post condition. Will it happen with CR2032? Nah, forget it. It's considered too much in the Lithium CR2032 batteries' point-of-view. Lithium-ion 18650? Yup, it could sideline with this battery's life expectancy, and it could also last for few weeks on frequent rev-ups and idling.
And, yes, the first Cog will need to stay on, since it's a bootstrapping processor - stop it, the whole thing resets. That's how I view it, never have performed the real Cog killing task on just a Cog, but I could imagine it will do funny thing if you do that. If you have multiple Cogs operating, and you kill the bootstrap Cog, it won't happen, only if you have just one running, though.
The RCSLOW is good enough for simple software routines, although a bit higher speed, RCFAST may be needed to bring some software up, then leave at it. I suggested that the oscillator can be shut down by toggling the OE pin of the oscillator with a pin from P8X32A chip, to turn it off if necessary.
Each new cog executing Spin code adds 3 microamps, and each cog in a waitxxx state adds about 0.5 microamps, at 3.3 V. The base current (one single cog in a wait state) was 7.7 microamps (sample of one).
This agrees with the data sheet and other results, for example, the with interesting investigation by Lawson
Prop-Limbo!-how-low-power-voltage-can-it-go!
Also data on RCFAST.
and 1 cog running RCSLOW
does this mean 2700 mAh / 0.0084 milliamps = 32,142 hours, equals 1,339 days, equals 3.6 years
I.E. over three years of standby using RCSLOW and one cog?
Did I do that right?
I think it is possible that it would last very long on 4 AA batteries, probably close to 3 - 4 years, concerning the internal current leakage inside the batteries.
And, Tracy Allen, thanks for the measurement! It's very useful in term of comparing the currents consumed by the on-die clock generator (RCSLOW and RCFAST). I would implement this for my battery-operated hardware containing P8X32A processor, for stand-by function.
Thanks for this new chart! It's so helpful and useful that I'm totally speechless now!
I've explored these low power modes over a year. I built this MC Computer
http://forums.parallax.com/showthread.php?124495-Fill-the-Big-Brain&p=1020034&viewfull=1#post1020034
to play around with low power battery operations with one Propeller chip and do programming in Binary. Yes, it can stay active for years in standby mode. Much of this play was operating the computer with the lowest possible power and observing the lowest voltage at which it would continue to function along with current draw.
Homebrewed Propeller MC Minimal Computer can
remain live in standby mode for years
Humanoido
Thanks. The MC computer is a mix of the Mark 8 from Radio Electronics magazine (Jon Titus) and the MITS Altair 8800 computer.
http://www.pestingers.net/images/Antique_computers/Mark8/re256.jpg
http://altair.ftldesign.com/altair02a.jpg
I don't know anything about the Mark 5. Can you provide a link?
That's how I want my PropAltair running Zicog and CP/M to look. Never thought to have it run from batteries and sit in standby mode for years though.
No surprise you batteries last a long time, according to the picture you have forgoten to turn on the power switch:)
Either way, it's a very nice thing to hear, that your own Altair-style computer did last long enough on those batteries in standby mode.
I used this computer so much that many of the toggle switches wore out and were replaced. When the off switch stopped working, there was no need to replace it.
http://forums.parallax.com/showthread.php?132961-Propeller-Power-Consumed-Based-on-Code&p=1020007&viewfull=1#post1020007
The MC Minimal Computer has one Propeller chip inside and programs in Binary using front panel toggle switches. Output is Binary using LEDs. I'm not programming the Altair, however I studied Altair programming to develop this project.
Thanks. It's easy to mix up those numbers after 40 years.
Concerning the IMSAI 8080 and Altair 8800's power consumption, they were run off thick and heavy transformer (pretty much like a microwave oven transformer except they were run at lower voltage) with linear regulators and HUGE low-dropout electrolytic capacitors - the first computers with SMPS didn't appear until 1982 - '84. They were so power-hog compared to the today's 32nm tower computer.
For you interested in IMSAI, there's the computer project in the making: www.imsai.net and yep, they're now power-efficient, and better than the original IMSAI 8800 (same key setup, though).
Would you be willing to share the schematic of your Minimal Brain for your Propeller brethren? I built an Altair in 1975, (yes Dr. Mario, before the IMSAI), and would like to know how you handled setting the address lines and then clocking the data into RAM. This would be a great small learning project for young people.
Verbal Schematic, what that heck is that? You have nothing to show?
So.. it does absolutely nothing and is not programmable. Well that's pretty consistent of all your threads. I thought you had something to offer, instead of a pretty panel. Can we at least have a peak inside?
In your verbal schematic - no EEPROM? It would be difficult unless you keep your main PC tethered to it, although in my honest opinion, it would be fine as long as the reset button is not pushed, or the batteries removed. I personally prefer to have something to hold the "hard-copy" so that way the computer will know what to do once it boots up - I screw up on programming sometimes so resetting may be necessary. And, the floppy disk drive saps juice from the batteries so it's also a good idea to have EEPROM (FRAM is not really needed here as Altair is basically a Turing-complete computer, meaning the input is read-only, although they're eventually modified to be able to hold whatever's inputted onto the monster 8" / 5" floppy disk drives and HUGE*** hard drives - although it wouldn't hurt to have one in there).
Otherwise, the large EEPROM is not necessary, as the operating system can be tiny as 512 bytes. 32KB EEPROM is fine for future expansion or just what it is gotten on hand.
Publison, Neat! For some reason, whenever I come over ancient computer hardwares that I can touch, it was kind of more like religious experience. Owning an Altair is certainly more than that, though - it's a piece of history! And, I definitely agree with you, constructing an Altair (at least the "me-too" clones of Today, even the one that involves P8X32A as a CPU) would be very educational for young peoples wanting to learn about the VERY early part of home computing history.
From what I have heard and readed a PDF of BYTE magazine (Sept. 1975 - "Assembling an Altair") that I still have somewhere on my second 500GB hard drive, it was very tedious task (so much ICs to be soldered and tacked onto the boards), yet you profit from the fruit of labor, and it was also entertaining reading throughout BYTE magazine as it got lot of useful troubleshooting methods on Altair too. (It also could be used to troubleshoot rather complex circuitry that involves Propeller, although the high-speed (100MHz) oscilloscope may be needed to probe the chosen wire / trace to find out what's going on here, though).
Edit: I found the mentioned magazine - I wish I could upload it to share with you guys, but unfortunately, I felt it's WAY TOO BIG for uploading (62MB) - and I have tried tarball - no change in file size (I have nearly overheated my CPU this way..... T_______T) Anyways, to save us both trouble, I have posted the link to the BYTE archival: http://www.sxlist.com/techref/article/byte/index.htm - you still can google it up if you want under the keyword: BYTE magazine - "Assembling an Altair"