Battery Backing SRAM, for z80, Instead of EEPROM

[rwgast_lowlevellogicdesin]

So I have been working on a basic z80 system, I have eproms/eeproms laying around, but Im trying to make this as simple as possible right now. I have a 65KB SRAM (http://pdf1.alldatasheet.com/datasheet-pdf/view/167846/SANYO/LC3664AML.html) chip. What I'm wondering is it feasible to just use all the address space with this one chip and battery back it? This way in the beginning I don't need to worry about any latching, glue logic, or burning eeprom/eproms, I don't have an eprom programmer, only UV eraser so I will have to build an eeprom programmer which is a totally separate project .

I know Nintendo games use CR2032 battery's to keep the SRAM backed up, but these chips are 5v, so im wondering how I can use 2032s to back up the SRAM. Do I need to use two to make 6v, and then regulate it with a switcher, or will 3v hold the data usually? Also Is it as simple as connecting a 2032 to the rams VCC and then the 2032 ground to the main board common ground. I've read some articles saying that without a proper backup circuit you can corrupt the ram etc..

[moffy]

Sorry, my Japanese isn't any good (I assume that is the language), but it looks like the typical standby current is about 1ua at 3v. That is what the battery needs to supply. But I'm just guessing as I can't read the datasheet!

[rwgast_lowlevellogicdesin]

Well Ive got these too, http://courses.cs.washington.edu/courses/cse477/99sp/docs/W24257A.pdf, there 32K so i mean they'll work too. It doesnt say anything about a stand by voltage from what I can see.

[mikerj]

Is it as simple as connecting a 2032 to the rams VCC and then the 2032 ground to the main board common ground.

What do you think will happen when the SRAM is fully powered up with 5v on it's rails?  You need some way of preventing the cell being charged by the 5v rail, and also preventing the cell trying to power everything else on the 5v rail when power is removed.

[Pavl]

It's possible if you really want to. You will still need a way to program your boot code into the SRAM though? I experimented with this once - soldered two wires to the RAM chip for power and swapped it between my programmer and the CPU circuit. Both on breadboard. Use diodes to separate the battery backup and other power supplies.

[T3sl4co1l]

All the SRAM I've seen, it guarantees to retain state down to fairly low voltages (2 or 3V), and in practice, will even retain state down to very low voltages (under 1V?), even down to 0V for some time.  Once you're below 2V or so, you'll start seeing a nonzero bit error rate.  Especially in the presence of radiation, say.

Be careful to lock out !CS and/or !WR in read-only address ranges, or while in backup mode.  Sooner or later you'll make a mistake, and the program will write over itself, and you'll have to reload all 64kiB.

I once built a Z80 project, using a 2kiB NVRAM.  I first tried using it for RAM as well, but found the above problem was annoying.  So I strapped !WR high, and added a [normal, volatile] SRAM in the next memory block.  That worked fine.

Tim

[Kjelt]

So do you want the entire memorymap mapped to one SRAM or just the program part (code)?
If the latter what you are doing is build an epromemulator, write the SRAM with the code from the programmer (you don't have but still need) and set it on read only (hard switched is best) than execute code. You need a small other sram for data which is preferred.
If you want the first you have a big problem seperating the data and code space and since the data space needs write access the chance is high you will at some time overwrite or corrupt your program code, good luck with debugging 

[free_electron]

there's plenty of srams with extreme low standby currents.

maxim has little chips max 69x series that do exactly that. connect 5 volt and a battery . the chip gives a reset out , CS in and out and Vout.

the ram gets power from VOUT.
the cpu reset pin goes to the reset out
and the CS signal from the cpu foes through the max69x s well


The 69x monitors incomping suuply. if that starts to drop below a certian level the max will block access to the sram to prevent data corruption. Drop even lower and it will throw the cpu in reset
it will seamleslly switch power from 5 volt to battery

at power restoration it will restart the cpu.


there's plenty of other manufacturers that make these chips.
simply google for 'microprocessor supervisor'

[rwgast_lowlevellogicdesin]

I acually have a very nice 1MB ST nvSRAM, the problem is the battery is built in and as soon as you apply voltage to it, the back up battery starts its "10" year life cycle. So i dont want to use it for some experimentation. I also have some MicroChip Supervisors for holding the reset line down during boot up, they may be able to be rigged to work with SRAM. http://ww1.microchip.com/downloads/en/DeviceDoc/21370D.pdf. How about a comparator and a logic gate, seems like a simple solution?

I planned on just using one SRAM chip for code and data, its not a permanent solution though, just a way to get me running instructions quickly without having to build an eeprom burner.

[T3sl4co1l]

If you're not going to play with it, what are you going to do?  Leave it on the shelf for ten years? The battery isn't going to get magically better before use.  I suppose they might have a lockout to extend shelf life, but life of NVRAM is almost always limited by battery self-discharge anyway.  I have >20 year old NVRAMs which still retain data.  10 years is the guaranteed minimum at the specified temperature, and expected life will always be higher.

Tim

[tiltit]

Hi I have also been working on a Z80 computer recently. I used a 28c256 eeprom. It can be programed at 5V, no need for a uv eraser, and it even has the same pinout and works almost the same way as the sram in my system. You could even write a serial bootloader where the z80 just writes the program into the eeprom as if it was ram, but you may have to find a way to slow the system down a bit.
I did try writing to the 28c256 from the z80 as if it was ram and it worked, even at 4Mhz. Not sure how reliable it is tho.

[free_electron]

I acually have a very nice 1MB ST nvSRAM, the problem is the battery is built in and as soon as you apply voltage to it, the back up battery starts its "10" year life cycle. So i dont want to use it for some experimentation. I also have some MicroChip Supervisors for holding the reset line down during boot up, they may be able to be rigged to work with SRAM. http://ww1.microchip.com/downloads/en/DeviceDoc/21370D.pdf. How about a comparator and a logic gate, seems like a simple solution?

I planned on just using one SRAM chip for code and data, its not a permanent solution though, just a way to get me running instructions quickly without having to build an eeprom burner.

homebrew doesnt work. you need two things : work at extreme low power and work down to very low voltages. that's why we have special chips that are designed for that purpose

as for those nvsrams : there is a way to put them back into sleep. ( losing the data ) you need to write a certain sequence to a certain memory location to trigger it.

for most of these devices it is 55 aa 55 aa to the top memory location , uninterrupted in one access cycle. ( which normal cpu's can't do as they toggle the CS ) . you need to brew a little circuit with some ttl chips to put that pattern on the pins of the device.

i remember dallas had an appnote on how to do it

[C]

One idea to keep in mind is that while the CPU can normally read from one location, It could easily write to many locations at the same time.
My old Z80 computer had it's video ram mapped to the same address as normal ram. Some call this shadow ram.  On reads of video ram the Z80 was reading normal ram. On writes to video ram, the CPU had to wait to sync up to what the video controller was doing so not to glitch the display, and would write to both video ram and normal ram at the same time.
It also had two banks of 64K ram. It could divide ram in to banks. One address range could be common between banks so a write to this address range was a write to both banks at the same time. Simple thing that makes using more than 64k easer.
This system only had a 512 byte boot rom yet it could boot scsi hard drives or from floppies. It could have 8 floppy drives attached. Single sided, double sided, single density, double density, 5 1/4 or 8". A dip switch set which drive, the rest was in that 512 byte boot rom. So you really don't need much boot code to get started.

The PDP-11's I worked with back them had no boot roms. They were suppose to run 24/7/365  and also had magnetic core memory that should retain it data during power off. So while adding the boot rom option would have been a costly nice idea, you could enter a 32 word program in from the front panel and get it started again if all else fails. 

For example some of the old turbodos slave CPU cards had no boot rom or eprom. On reset the CPU was stopped. The reset caused the master Z80 to load the boot code into the slave CPU and then release the reset line. The master Z80 used the slave's DMA signals to do this. A simple but powerful idea. Some slave cards had no IO and relied on the master Z80 for IO and off card needs. This also allowed fancy slaves that could take some of the load off the slaves and the master.

An Intel development system I used back then had a reset button and a boot button. The boot button cased a processor reset and enabled a eprom for read only access. Stage one was to read from rom and write to the same address.

So boot program can be small if you can get more from some place.

In case I missed it, what else have you got to get the Z80 running.

Have you thought of having a Arduino or STM32 discover or something else like this load your boot code in ram? After boot this something could be some or all the Z80's IO you could need.
No battery backed ram would then be needed. Just a little harder to get started, but could be a great time & cost saver later.

C

[22swg]

I worked on hardware eons ago ( cash registers) they had 3v  nicad battery soldered as backup. The main consideration was random writes to ram at loss of power 5v . design usually included an interrupt driven from low voltage detection that saved current data and inhibited ram access..