Topic: Core for the S-100 Bus
Date: 2016 MAR 29
Ferroelectric RAM is a type of nonvolatile memory that uses tiny magnetic domains on silicon to store bits of information, similar to how magnetic core memory does so using magnetic toroids. It is a static, nonvolatile memory requiring no refresh, no backup battery, and devices exist that can be accessed similarly to how conventional static RAM, with a few changes. Modern devices hide the destructive read nature of FeRAM behind integrated controllers.
I became aware of commercially availale FeRAM around 2010, when a friend mentioned wishing he’d chosen it over MRAM for a project. Samples were ordered from Ramtron, then the largest supplier of FeRAM. I switched over to their serial-access FeRAMs in a number of data logging projects with excellent results, but had a few 8K and 32K parallel FeRAMs in SOIC surface mount packages sitting in the samples bin. It seemed the perfect fit to build a S-100 board with FeRAM, as the nonvolatile nature would make front panel operation a little more practical, much in the way development and debugging could be done on earlier computers with core memory.
Six years later, and I’ve just now finished implementing a prototype FeRAM board! There were a few challenges to oversome:
- Address latching on Ramtron devices
- Write inhibit during powerup/powerdown
- Protecting memory from writes during operation
For technical points, the FM18W08 datasheet is of course the best reference.
Address Latching
Address latching wasn’t much of an issue, but did keep the FM18W08 FeRAM from being a drop-in replacement for the 62256 SRAM that my prototype started life with. The FM18W08 latches its address lines on the falling edge of /CE, meaning that it’s /CE which sets the address as valid, not /OE or /WE. To work with the FM18W08, we need to gate /CE with MWRITE or SMEMR from the S-100 bus, since MWRITE and SMEMR go high only when the address bus are valid. This can be expressed as:
(MWRITE ∨ SMEMR) ∧ BOARDSEL ⇒ CE
In this expression, BOARDSEL is a condition generated by address decoding elsewhere on the board. CE, the conditioned Chip Enable, comes out positive, so we’d need to invert it to get /CE. Easy to do with 7400 series TTL logic.
My prototype is a simple 32K setup, so BOARSEL is generated as follows:
¬PHANTOM ∧ ¬A15 ⇒ BOARDSEL
This also means the board will respect the /PHANTOM line, which allows base memory to be overlaid with something else – boot ROM code, in the case of my IMSAI.
Write Inhibit
Write inhibit is necessary on any nonvolatile memory system – even floppy disks. A lack of write inhibit during power transitions and restarts can corrupt data as the microprocessor enters undefined states with the ramp-up or collapse of various power supplies. This is why you’re never supposed to power-on or power-off a vintage computer with a floppy disk in the drive!
Battery-backed SRAM often overcomes this problem with an internal cutover circuit. Other systems, including most modern PCs, receive a “Power OK” signal from the power supply and/or a “Power Fail” signal to indicate impending power loss. The S-100 bus presents a special case in this area, as you have a large unregulated supply coming up, plus a number of small, independent regulated supplies coming up at their own rates. The IEEE-696 standard provided /PWRFAIL on pin 13, but early systems like the IMSAI and Altair don’t supply a /PWRFAIL signal.
The FM18W08 does include its own write inhibit circuitry, but it is a wide-voltage device, operating from 2.7V to 5.5V. The lower end of this spec leave plenty of room for problems with a 5V nominal system – below 4.5V, operation is undefined and may include spurious writes.
My solution was to monitor the local regulator on the FeRAM board, then wait a predetermined amount of time before releasing the /PRESET signal and allowing writes to the FeRAM. This was accomplished using a Maxim ICL7665 voltage monitor and a 555 timer for the delay. /PRESET and write control was accomplished using a DPDT relay, with MWRITE routed through the normally open contacts, and pulled to ground through a 4.7K resistor. I included a LED to indicate when write inhibit was released.
In practice, this seems to work fine, though on further reflection it seems monitoring the 8V rail on the bus would be the better approach. Especially on powerdown, a lightly loaded board will drop out of regulation slower than a heavily loaded board. Future revisions will take this route, perhaps also monitoring the +/- 16V rails as well. Presumably the 16V rails come up quicker than the 8V rail, but all three are required for old CPUs like the Intel 8080.
Protecting Memory During Operation
The original Altair 8800 bus definition included PROT and UNPROT lines for controlling the write inhibit for blocks of memory. This let you toggle in a program and write-protect the code sections before running it – a runaway program often trashes its own code, which means toggling everything in again. I wanted to implement this functionality in a flexible way, allowing operation with the original Altair layout as well as with systems that didn’t support PROT and UNPROT (the IMSAI doesn’t, without modification that puts the power switch on the rear panel). Additionally, write protect status should survive power loss, since the memory does.
While one could use battery backed low-power CMOS flip flops, a default-to-protected strategy, or a manual switch, I decided on latching relays. Latching relays are available in several varieties including units with a permanent magnet that holds the contacts in their electrically set positions with electrical power removed. Perfect! The latching relays could be set through PROT and UNPROT front panel controls, if present, or switched over to use an output port for other machines.
This feature is not yet implemented, but will be included in the current prototype. Wait for Part 2!
BASIC reloads averted