Mass storage - why backup battery?

Comments

• roko

  February 2010 edited February 2010

  RetroTechie wrote: »

  ....So: what the hell do you need RAM for on an interface like this, and why does it need battery backup? I've seen this mostly mentioned in combination with software called ResiDOS, but maybe there's other software that works like it.

  Part of the 'why and how' lies in the past, there once were days when SRAM was available for hobbyists and FlashRAM still had to come. Apart from that, I think it is the developpers prerogative to use whatever he/she thinks is appropriate. This results in the situation that only 'proselytes' can find an interface which is perfect (for them). True techies usually have to build their own funny stuff, welcome to the club...
• ingo

  February 2010 edited February 2010

  S-RAM can be read and written with the same speed as D-RAM of the spectrum. It is mostly used to hold (parts of) the operating system. So after ones it is booted it remains in the battery backed S-RAM to be used every day. Flash-ROM has to be writen using special ways. Some times it can only be written in defined blocks while you can write S-RAM randomly without special writing conditions. S-RAM is cheap and fast. And Li-batteries lasts a long time.
  
  I think that are the reasons.
  
  Greets Ingo.
• velesoft

  February 2010 edited February 2010

  RetroTechie wrote: »

  There are these mass storage devices for ZX Spectrum, and on many designs you see a backup battery powering an SRAM. Can anyone explain what this is for, why it is needed? :-?

  
  SRAM can be connect in low 16kB of adress space instead original ZX rom. Some systems/programs in this sram memory use writing to low 16kB(this is impossigle on flash eprom...). CPU stack ans registers backup can be also in this memory.
  
  And BATTERY BACKUP = possibility power-off computer without data erasing in sram memory. User don't need install any system/software to sram after each power-on. Complette this sram memory can be backup also to IDE disc, but it's must be used manually before power-on computer and it's slow if memory backup file is big.
  
  ZX MMC+, DIVIDE PLUS, MB02+, ZXCF and PROFI INTERFACE use battery backup sram.
• Winston

  February 2010 edited February 2010

  Whether it be RAM or ROM has nothing to do with how you bank switch with a Spectrum. Whether you have RAM, ROM or anything else, there is only one place it can be mapped on an unmodified Spectrum - between 0x0000 and 0x3FFF by holding ROMCS high. The NVRAM on these devices *is* bank switched, and it appears as you'd expect in the memory map where the main ROM would be.
  
  ResiDOS requires NVRAM, it won't work with anything else, therefore ResiDOS devices use NVRAM. It's really a software design choice as to why NVRAM is used on the ZX-CF and other ResiDOS devices. It's only ResiDOS devices that need it - see the standard DivIDE, it uses an EEPROM and some RAM, and has no battery backup.
  
  There is more than one way to do it. Some devices use NVRAM, some use some type of ROM (EPROM, EEPROM or flash). It's just what tradeoffs the designer decided to make at the time - there is no One True Way to do memory for Spectrum peripherals.
  
  Personally, I'm not so keen on NVRAM - it's expensive, and flash has been around for a long time now and works very well. The advantages and disadvantages can be summed up as:
  
  NVRAM advantages:
  * Easy to write to. Simple LD instructions can store your configuration.
  * Fast to write to - same speed as normal RAM.
  These advantages make NVRAM very useful for storing state between power cycles. See the ResiDOS task manager for a good use of this.
  
  NVRAM disadvantages:
  * TOO easy to write to - easily corrupted by glitches on powerup/powerdown unless purpose-built NVRAM (such as that from Dallas, now ST) or the extra electronics is added to ensure the power supply is stable before allowing write enable to go low. Very easy to accidentally overwrite your OS if the program running crashes unless a write protect circuit is added (more components, more PCB space, or more CPLD resources that could be put to other use). Sadly I've stopped using my ZX-CF because the NVRAM gets corrupted so frequently.
  * Expensive - purpose built NVRAM in small quantities costs around ?15-?20 for a paltry 32K chip even today. Home made NVRAM (SRAM plus a battery backup) requires a great deal of PCB space, and in small volumes PCB space is very expensive - although "roll your own" NVRAM will be cheaper than a Dallas NVRAM chip. (The Dallas chips typically also come with a clock).
  
  On the other hand, we could use flash:
  Flash advantages:
  * Very robust. You can program it THEN solder it to the board, and the data is still there. Very resistant to corruption, the way bytes are written virtually guarantee it will never be accidentally corrupted either by poweron/poweroff glitches nor software crashes.
  * Small and cheap. Doesn't need much PCB space, doesn't need a separate battery, about an order of magnitude cheaper than NVRAM.
  * You can still program it in-system. For example, the Spectrum loads the Spectranet's firmware, the initial programming from a tape, subsequent ones over ethernet. I don't even own a flash programmer device. All the flash chips I've ever used have been programmed by the target system (not just Speccy stuff).
  
  Flash disadvantages:
  * Writing isn't so fast - you can't just LD (HL), A to set a byte, you have to send an unlock sequence first. Also, if you need to modify a byte, you have to copy the entire sector (however big that may be) into RAM, erase the entire sector, and write the whole lot back. Obviously if the process crashes, or someone yanks the power out in the middle of this cycle...bye bye everything that was in that sector. For these kinds of reasons, it's not going to be great for the equivalent of the ResiDOS task manager.
  
  The disadvantage of having to copy/erase sector/modify in RAM/write back is easily hidden by a software interface, so it's not such a big deal. The massive advantages for storing the firmware that flash has meant - at least for me - it was the obvious route for the Spectranet. I'm more than happy with the tradeoff of having to write some code to program the flash, and do the copy/erase/modify/write cycle against having more complex hardware and a larger, more expensive PCB - and most of all, to have extremely robust nonvolatile memory for the firmware. On the subject of the task manager, I think the point is a bit moot today - mass storage is fast enough that there's no need to save state to RAM. For example, the Spectranet saves a 128K snapshot in about 2 seconds to a network filesystem which is hardly a huge burden.
• RetroTechie

  February 2010 edited February 2010

  velesoft wrote:

  And BATTERY BACKUP = possibility power-off computer without data erasing in sram memory. User don't need install any system/software to sram after each power-on.

  That also applies to Flash ROM, and Flash memory is perfectly adequate for storing system state that must survive reboots / powercycles. Saving registers/stack in SRAM: yes (perhaps, if code isn't smart enough to avoid the need), but doesn't need battery backup.
  

  ingo wrote:

  S-RAM can be read and written with the same speed as D-RAM of the spectrum. It is mostly used to hold (parts of) the operating system.

  For system software, that's a liability, not a feature. And (according to Winston), users do get bitten by it. How often do you (need to) update system software anyway?
  

  Winston wrote:

  It's just what tradeoffs the designer decided to make at the time - there is no One True Way to do memory for Spectrum peripherals.

  True, but a designer should also weigh increased hardware cost/complexity against the need for it, and the effort to code around things. Given the ease of software development vs. building hardware, there is an optimum: the cheapest/simplest/smallest hardware that can do the job, reasonably efficient, without ridiculous efforts on the software side. More complex, and cost suffers. Too simple, and efficiency / software support suffers.
  
  Summarized: the SRAM + backup battery is needed because of historical reasons (most of which no longer apply), and because existing code isn't smart enough to use a simpler/cheaper HW setup?
  
  In that case, there is only 1 way forward that makes sense: simplfy the hardware (into Flash EPROM, memory card, and glue logic), and re-code the interesting parts of the software to work with that simplified hardware. Not worth the effort? At first glance, maybe not. But every build of a hardware interface that has more parts + board space on it than necessary, is also effort that could have been spent elsewhere. The effort for building hardware repeats every time an interface is built (100 interfaces = 100 times the extra, unnecessary effort + parts). Re-coding a piece of software can be a one-time effort.
• ingo

  February 2010 edited February 2010

  RetroTechie wrote: »

  In that case, there is only 1 way forward that makes sense: simplfy the hardware (into Flash EPROM, memory card, and glue logic), and re-code the interesting parts of the software to work with that simplified hardware. Not worth the effort? ...

  Not at all, I think. I prefer to build interfaces using hardware components that may exist also at life time of the spectrum. For me it is a historical peace of hard- and software which is worth to be kept. I like to use it from time to time and I like to build hardware for it or program some code. I like to load software faster than from tape but disks and harddisk were also available in the 80s. but I would not use modern controller or special circuitry where classic hardware does the job. It is a bit philosophy - my philosophy as a collector of old technology.
  
  Greets Ingo.
• roko

  February 2010 edited February 2010

  RetroTechie wrote: »

  In that case, there is only 1 way forward that makes sense: simplfy the hardware (into Flash EPROM, memory card, and glue logic), and re-code the interesting parts of the software to work with that simplified hardware. Not worth the effort?

  Your description fits exactly the simple CF interface of Pera Putnik: http://piters.tripod.com/zxcf.htm It also describes the extension I use: one FlashRAM, one GAL, a CF Card, and featuring full Opus DOS.
  But now the difference: where I respect Pera's hardware design, I like mine. Where I find Pera's DOS quite interesting, I enjoy my solution. And I expect Pera to think vice versa. Is this worth the effort? Yes I think so, you may call it hobbyistic...

  RetroTechie wrote: »

  But every build of a hardware interface that has more parts + board space on it than necessary, is also effort that could have been spent elsewhere. The effort for building hardware repeats every time an interface is built (100 interfaces = 100 times the extra, unnecessary effort + parts). Re-coding a piece of software can be a one-time effort.

  
  I agree with that of course, but these 'measurements' are taken along professional standards only. In fact, and I make a nasty shortcut here, all the time spent on hobbying "could have been spent elsewhere" i.c. more professional. Same for the parts used. Other factors than economics play a decisive role, we all have our personal interests and drives for doing what we do. What's the alternative then, hobbying under supervision of a board of professionals, so that no single drop of 'effort' is lost? I am afraid that it is not clear to me what your point exactly is. And yes, I too have seen hardware projects that I regard as 'good' but IMV would still have gained from a few professional hints. I think that all we can do is creating an open and positive atmosphere on the forum so that people feel invited to have their thoughts discussed in an early stage? (bverstee did, bravo for that, Ben!)
• Winston

  February 2010 edited February 2010

  ingo wrote: »

  but I would not use modern controller or special circuitry where classic hardware does the job. It is a bit philosophy - my philosophy as a collector of old technology.

  
  So I take it you use MFM and RLL drives, not the new fangled modern IDE stuff with a lot of the controller integrated onto the disc itself :-)
• zxbruno

  February 2010 edited February 2010

  It's that old topic all over again. How modern can the interface be without turning the Spectrum into a dump terminal... Where do you draw the line... :)
  
  Personally I think the expansion port is there for a reason. To expand a very small, simple computer into something a lot better. To date, the only interfaces that I don't plan to have are the Turbo Sound FM (but the Turbo Sound with 2 AY chips is fine) and the General Sound. If the thing sounds too much like a Commodore Amiga I don't like it. But I'm all for ethernet, usb, sd, mmc, flash and similar things.
• Winston

  February 2010 edited February 2010

  RetroTechie wrote: »

  Summarized: the SRAM + backup battery is needed because of historical reasons (most of which no longer apply), and because existing code isn't smart enough to use a simpler/cheaper HW setup?

  
  And it also enables things like the ResiDOS task manager (which saves the *entire* state of the machine between power cycles).
  
  It's not a black and white issue. There are advantages and disadvantages for each approach, it just depends on what tradeoffs you are willing to make.