NVRAM

NVRAM

1. To maintain a 'clock' during times when the server is switched off, so that upon power-up the server will know what the date and time are.
2. The storage of important system variables, such as the server's station number and the printer server 'name'.
3. Upon error, the error information is written to the NVRAM. I'm not entirely certain how you would go about extracting it, but it is there...

The NVRAM requires a continuous supply to keep the data intact. This low-current supply is provided by a NiCad battery that outputs 3.6V. The battery is charged by a constant current source from the +5V rail while the power is on.
When the power goes off, the battery powers the NVRAM and also pulls the !CE line high, which disengages the data and address lines in the device, offering a further reduction in the power required to maintain the configuration.

The small cylindrical crystal near the battery (in the E01S, probably similar for E01) provides the time base for the NVRAM. As is common for watches and the like, it operates at 32.768kHz. The variable capacitor near the crystal allows for fine-tuning and, when the server is undergoing testing, the test point (TP1, by the NVRAM chip), can be used to ensure that the ticker is running at exactly 1.024kHz.

The NVRAM's address register is mapped in to memory at &FC00, and the data register is mapped in to memory at &FC04. In order to access the NVRAM, you will need to poke bit 3 of the "Miscellaneous Functions Latch" (at &FC08).

NVRAM allocations

Default values

If the battery's charge is marginal, it is possible for bogus data to be stored in the NVRAM and the server will use sensible defaults but not clear the contents of the NVRAM. A suggested workaround is to use !FSUtil to "test" the NVRAM. The first operation it will do is read a copy of the current contents into memory. It will then write zeroes into NVRAM and attempt to read them back. As soon as !FSUtil starts to read back the data, you should switch your FileStore off. Don't worry - !FSUtil will crash whinging about not being able to read back the information.
Now when you switch your FileStore on, it will detect that the NVRAM is blank, and will then write defaults, which are as follows:

The remaining bytes, 50 to 63, are not cleared by the FileStore as they are not used.

The FSUser check byte

In code terms, this would look like:

calcbyte% = 0
carry% = 0
FOR offset% = 36 TO 46
  calcbyte% = calcbyte% + cmosarray%?(offset%) + carry%
  IF calcbyte% >= &100 THEN
    calcbyte% = calcbyte% - &100
    carry% = 1
  ELSE
    carry% = 0
  ENDIF
NEXT

The check byte value is &61. This is hardcoded into the FS ROM.

Here is a JavaScript-enabled way to calculate check bytes. Feel free to view the document source and look at the code.

There is a caveat to be aware of. I do not currently know if the FSUser command clears existing data or if it simply writes new data.
For example, if you:
*FSUser JESSICA
*FSUser AMY

Would the FSUser name area look like this:
A  M  Y  <-
41 4D 59 0D 00 00 00 00 00 00
or like this:
A  M  Y  <- I  C  A  <-
41 4D 59 0D 49 43 41 0D 00 00

NVRAM read code

  LDA  #5
  LDX  #(<address> MOD &100)
  LDY  #(<address> DIV &100)
  JSR  &FFF1 ; OSWORD
  RTS

  buffy%?0 = &A9
  buffy%?1 = 5
  buffy%?2 = &A2
  buffy%?3 = address% MOD 256
  buffy%?4 = &A0
  buffy%?5 = address% DIV 256
  buffy%?6 = &20
  buffy%?7 = &FFF1 MOD 256
  buffy%?8 = &FFF1 DIV 256
  buffy%?9 = &60

The code used by !FSUtil to read the NVRAM is:

SYS "Hourglass_On"
FOR loop% = 0 TO 63
  cmosbuffer%?loop% = FNcmosfetch(loop%)
NEXT
SYS "Hourglass_Off"

DEFFNcmosfetch(addr%)
  LOCAL rec%
  FOR rec%=0 TO 5 : buffer%?rec%=0 : NEXT
  ?buffer%=addr%
  PROCcmosassemble(5)
  SYS "Econet_DoImmediate", 2, &E800, fsstn%, fsnet%, cmoscode%, 10, 10, 2 TO erp%
  IF (erp% <> 0) THEN call error handler...
  SYS "Econet_DoImmediate", 2, &E900, fsstn%, fsnet%, buffer%, 6, 10, 2 TO erp%
  IF (erp% <> 0) THEN call error handler...
  SYS "Econet_DoImmediate", 3, &E800, fsstn%, fsnet%, 0, 0, 10, 2 TO erp%
  IF (erp% <> 0) THEN call error handler...
  SYS "Econet_DoImmediate", 1, &E900, fsstn%, fsnet%, buffer%, 6, 10, 2 TO erp%
  IF (erp% <> 0) THEN call error handler...
=buffer%?4

The two 256 byte blocks of memory are &E800 and &E900, both of which are MOS code, but are part of the copy loop and, apparently, are not used after the boot sequence so it is theoretically safe to use these pages for user code.

The final thing is the cmosassemble function, which is:

DEFPROCcmosassemble(readwrite%)
  cmoscode%?0 = &A9
  cmoscode%?1 = readwrite%
  cmoscode%?2 = &A2
  cmoscode%?3 = &E900 MOD &100
  cmoscode%?4 = &A0
  cmoscode%?5 = &E900 DIV &100
  cmoscode%?6 = &20
  cmoscode%?7 = &FFF1 MOD &100
  cmoscode%?8 = &FFF1 DIV &100
  cmoscode%?9 = &60
ENDPROC

The value of readwrite should be 5 (as shown in these examples) to read the NVRAM, and 6 if you wish to write it.

All of this code is seriously unoptimised. It was designed to read or write bytes one by one from the NVRAM, and essentially a complete read or write operation means going through the motions 64 times!

An easy optimisation would be:

• Assemble code to read all 64 bytes at one time and write them one by one to the data area.
• Poke this code to the code area (&E800).
• Poke 64 bytes of null bytes to the data area (&E900).
• Execute the code on the FileStore.
• Read back 64 bytes from the data area.

The 146818

This is better shown on the schematic below. This is from the E01 as it is less cluttered than the E01S' circuit diagram. The address decode logic has been omitted as it would more than double the size of the picture.