Rescuing an old FileStore

In the beginning...

This proved to be more problematic than I expected because the A5000's keyboard was acting up, and it kept crashing (Abort on instruction fetch) as the boot attempted ipconfig for the eth0 device.
I decided to revert to the A3000. Didn't have a mouse for it, but I had been given a Watford Electronics infra-red mouse. Hooked that up, it was a bit jittery but otherwise fine. It had been unused for a long time too, so the CMOS RAM needed to be reset. I thought orginally that the harddisc problem was the stupidity of HCCS's "Armstrong Walker" IDEFS allowing it to accept a "scan for drives delay" of zero seconds (as it would upon memory clear). It should have trapped this and defaulted to something like five seconds, as looking for a harddisc for zero seconds is obviously bogus. After correcting this, it still didn't want to work. Asking IDEFS to report on devices found, it hung up looking at the details of :4.

Well. The thing had been left in a damp place (i.e. my bedroom, average humidity 78-90%) for five years. The disc is probably seized up. I took the lid off the A3000 and rested my ear on the drive. A strange noise. Certainly sounds like the heads are trying to move, but are 'stuck'.
So I turn off the computer and take the harddisc expansion card out. It is broken right? I found a large spanner and hit the drive on the side, about in line with the centre of the platter (a third of the way along, in other words). Not too hard. Not hard enough to break a CRT but about hard enough to break a window.
The harddisc went back into the A3000. I don't have a clean room and I can't afford data recovery for what is probably mostly unimportant data. It's all or nothing, right? I flicked the power switch on the A3000 and was treated to a most horrendous noise from the harddisc for a few seconds, and then the computer crashed - "Address exception at &0".
I turned off, checked the 4Mb upgrade was in snug, and powered up. It started, and - ta-dah! - there was Amy on the icon bar. The harddisc was quiet, faster than I remembered (I always recall the A3000 being kinda slow as it is only 8Mhz), and the harddisc seemed okay, nothing messed up, all files accessible, verifies without error.

I wouldn't recommend that you whack your harddisc with a spanner, but if it is either that or chuck it in the bin... give it a try. It might work for you?

...there was light

I switched on the FileStore. The green light came on, followed by the red light. This meant that the CPU had started, taken the reset vector, and executed exactly three instructions. ☺

Sadly, that is as far as it went. The FileStore is supposed to copy the contents of the 64Kb EPROM into RAM, then look for harddiscs, then check the floppy discs. Only it didn't. It sat there with the red light on.

Maybe it is in Maintenance Mode?

I took the switch out (hence the hole in the front panel in the above picture). I then had to retrace the circuit diagram and probe the connections in order to ascertain how the thing worked. I would then use some hook-up wire to 'short' the sensor output to +5V or 0v (as applicable) to trick the server into believing the door flap was closed.

Then something rather odd happened. I took a digital photo - the one you see above. Can you see the white glow from the door flap sensor? This is because CCD imagers can 'see' infra red. Quite useful for testing remote controllers - simply point one towards your video camera and press a button on the controller. You'll see the flashes in the camera's viewfinder.
Anyway, this meant that half of the flap sensor was actually working.

After some probing, I found the connections, which I detail here:

I was now able to hook a small LED in between the flap's 0v and the sensor output - remember, if you look in an LED there will be a 'big bit' at the top of one leg, and a 'smaller bit' at the top of the other leg. The 'big bit' connects to 0v.
With the LED in place, I found a reflective surface (which happened to be that spanner!) and waved it in front of the sensor. Hey-presto! It responded! Holding the spanner in the correct position, the LED went out.

So the server works then?

Not to be out-done by a little sensor, I cut out a small strip of cooking foil and taped it in place, shiny side up, like this:

Wait, how did you log in?

The network icon will display "!254".
You can then issue commands such as *FSFormat 4 FSDisc (more details here).

When it is time to return to normal mode, *Bye yourself and then close the flap.

Logging in as a user - Syst (still no password) - I was able to run my !FSUtil software (refer to the BudgieMgr suite) to check and set up the server configuration.

If !FSUtil crashes...

The fix is simple. Load the !FSUtil code into edit and look for the following code:

  SYS "NetFS_ConvertDate",fstime%,rotime%
  SYS "OS_ConvertDateAndTime",rotime%,timestr%,68,"%24:%MI:%SEh, %DY/%MN/%CE%YR"

  SYS "XNetFS_ConvertDate",fstime%,rotime%
  SYS "XOS_ConvertDateAndTime",rotime%,timestr%,68,"%24:%MI:%SEh, %DY/%MN/%CE%YR"

And then what?

Disaster strikes!

Ten minutes pass.

Twenty minutes pass.

By now I'm digging out the service manual. I switch off to hook up my multimeter to measure the current consumption, as per the fault finding guide. Switch on, it boots.

Then the penny drops. It was the NiCad battery, wasn't it? The server obviously was getting junk from the NVRAM and probably crashed. Perhaps, without any charge in the battery, it was behaving as if there was no NVRAM (and I believe the server will 'hang' waiting for data?).

After leaving it awhile, there was some charge in the battery and the server started up with default settings, probably having noticed the configured station was likely to have been 'zero', which is invalid.

So if your server appears to hang when you try starting it, leave it on for around fifteen minutes and then switch it off and back on.

Humming away

In the future

One of my pet annoyances is that the server does not appear to want to talk to harddiscs that do not have the "(C)Acorn" string in them someplace special. I hope to work around that, and possibly replace floppy disc :5 with a small-size harddisc (to keep it all internal to the one box, I no longer have the E40S box). I hope the power supply is up to that! I know the missing drive won't be a problem as I can *MaxDrive 4 to tell the server that it only has the one floppy.
We'll see...

For now my FileStore has a new home atop the Ethernet hub.

Addendum

Upgrading the firmware (2007/09/03)

Examining in the ROM dumps, they looked substantially similar to that which I had installed, so I decided to burn an EPROM and try out the newer version.

As an aside, embedded in the MOS is the following:

The Stacking FileStore was devised and created by the following; Ram Bannergee, David Burling, Brian Cockburn, Carl Dellar, Joe Dunn, Laurence Hardwick, Andrew Hinchley, Steve Love, Glen Nicholls, Mike Oakley, Brian Robertson, Hugo Tyson, and Jes Wills.

Step One - find an EPROM
The first thing to do was to find a suitable EPROM. The FileStore holds the server code and MOS in a 64K EPROM (which represents the totality of the 6502 addressing space). Using some clever code, this is all copied into RAM at power-up, and from there the 6502 sees only the RAM. The EPROM is mapped out, forgotten about, no longer required.
What this means is that we need a 64K EPROM. For some reason, the marking on these sorts of EPROMs is the number of kilobytes multiplied by eight, sort of "kilobits". Therefore, we require a 27512.

You'll also need the EPROM images (v1.40.00, © 1989 Acorn Computers).

• filestore_fs.dat - goes in lower 32K &0000-&7FFF
• filestore_mos.dat - goes in upper 32K &8000-&FFFF

Step Two - program it
The next stage is the hard one. Fire up your EPROM programmer and burn the ROM. For this I was planning to use the BBC micro and the FileStore as the filing system, however I appear to have mislaid (read "lost") the ROM for the EPROM programmer. Therefore I dragged out the old A5000, complete with dodgy keyboard, and hooked up the EPROM programmer. I'm surprised (but very pleased) that I can run the programmer system under !65Host. No, it isn't the compatibility of the BBC micro emulation that worries me, it is that the expansion podule version of the "1MHz bus" apparently runs at 2MHz...?

For those using older solutions, such as a setup like mine... It is slow and nailbitingly worrisome process, knowing that you are running something beyond its specs and an error will require a tedious quarter hour under the UV eraser (the EPROM or you, doesn't matter, your mind will be equally frazzled either way). You find yourself willing it on, hoping and praying that all will be okay.
Then after the verification is complete, you give it permission to "experience a minor hiccup" just to make believe that it has "got it out of its system", as if by some miracle of modern science it was ever going to give you a say in the matter, peon!

Step Three - check it
Finally both blocks are programmed, and just as a little exercise for the bladder muscle it is time to load a block back into the programmer's buffer memory... and check that you've got them the right way around - file server stuff in the lower block (&0000-&7FFF) and the MOS stuff in the upper block (&8000-&FFFF).

An easy way to check, the MOS, in the upper block has forty bytes of code (data?) at the start, followed by loads of &FF bytes. From then on it will be all &FF bytes until offset &E800 (or &6800 relative) when the MOS begins. I list the MOS first as it is probably the last block you programmed...
The lower block, the FS code, will begin with a bunch of &FF bytes as well. If you go to offset &0200, you should see a copyright message, and the firmware identification at offset &6965.

And there we have it, one shiny new EPROM (erm, from around 1989) programmed with a shiny new version of the FileStore's firmware (erm, from around 1989 also!). Well, it's the sentiment that counts...

Step Four - fit it
With nervous caution, it is time to disrobe and defile the FileStore. Whip it's lid off and, using a big-ass screwdriver and quite a lot of care, prise the old EPROM from it's position and remove it. If you're an old-hand at doing this, you shouldn't bend any of those legs either. But do not bother yourself with imaginings, for that EPROM has probably lain in place for the better part of a decade and a half. Only a fool would attempt to flip it out with reckless abandon.

Some way or other you'll get it out. Good. Now gently position the new EPROM in place and gently press it home. The notch goes towards the back of the unit. In other words, the EPROM fits in the right way up. Hopefully you made a note of this when removing the old one?
Go around, several times, with the brightest light you can find and ensure everything is just as it should be. If any legs are incorrectly positioned and are sticking out, this is a danger as data can leak out and form a corrosive mess on the circuit board. This is a Bad Thing.

Here's a picture. Sorry it is crappy, what do you expect for a simple VGA-quality digital camera and a torch?

Here is a better picture. It clearly shows the new EPROM, plus the new battery (described below):

Step Five - let it roll
Without putting the FileStore back together, in case anything is wrong, power up.

What I can tell you is that the FileStore used to start up in about 12-15 seconds 'from cold'. It now gets itself going in six.
Furthermore, it used to 'hang' for ages if the NVRAM was corrupted. It appears that if the NVRAM is messed up at all now (perhaps using a global checksum?) it will blank everything that is/was there and write sane defaults.
Sadly, it still does not work faster than the internal clock's 1µs mark/4µs space. I tried a 2µs space and it'd have been cool if it worked, but...

I have not noticed anything else that this version of the server does differently, but I've not exactly examined in detail. Perhaps it does something I'm not able to test, such as support for harddiscs larger than 60Mb?
If you know more about this version of the firmware, please contact me!

A quick way to set a sane state

Edit it as necessary, and then just run it (no need to log on first) to set your server's configuration to a 'known' state.

REM >fspoke
REM Rick Murray, 2007/09/03
REM
REM HAS *NO* ERROR CHECKING, add this yourself. :-)
REM
REM ASSUMPTION: You are using the 'default' server;
REM if not, then poke the desired server in front
REM of the login name, like "0.252 Syst" or whatever.
REM

REM Set SUPERVISOR login name and password below
login_name$ = "Syst"
login_pass$ = ""

REM Initial login
OSCLI("I Am " + login_name$ + " " + login_pass$)
REM No need for "Net:" prefix to commands as
REM "*I Am" automatically selects NetFS.

REM Okay, set up the basics [edit as necessary]
OSCLI("FSMode M")
OSCLI("FSUser SYST")
OSCLI("FSMaxUser 8")
OSCLI("FSMaxDrive 5")
OSCLI("PrPage Y")
OSCLI("FSMode U")
t% = TIME : REPEAT UNTIL (t% + 300) < TIME
OSCLI("I Am " + login_name$ + " " + login_pass$)
OSCLI("PrName FSPRNT")

REM Now set the RTC from the host's RTC
DIM rotime% 5, fstime% 5
!rotime% = 1
SYS "XOS_Word", 14, rotime%
year% = FNrtcbcd(rotime%?0)
IF (year% > 90) THEN
  year% =- 81 + year%
ELSE
  year% = 19 + year%
ENDIF
month% = FNrtcbcd(rotime%?1)
day% = FNrtcbcd(rotime%?2)
hour% = FNrtcbcd(rotime%?4)
minute% = FNrtcbcd(rotime%?5)
second% = FNrtcbcd(rotime%?6)

REM Now twist these dates/times into FS style.
fstime%?0 = day% + ((year% AND &F0) << 1)
fstime%?1 = month% + ((year% AND &0F) << 4)
fstime%?2 = hour%
fstime%?3 = minute%
fstime%?4 = second%
SYS "XNetFS_DoFSOp", 28, fstime%, 5, 5

REM All done!
END

:

DEFFNrtcbcd(val%)
  LOCAL out%, temp%
  out% = val% AND &0F
  temp% = val% AND &F0
  temp% = temp% >> 4
  out% += temp% * 10
=out%

Changing the battery (2007/09/09)

My tip, if this affects you, is to unsolder the positive side first. This is split into two thinner legs that you should be able to remove without too much bother. Then snip off the other larger leg close to the board and use your iron and a solder-sucker (if you have one) to tidy up the mess.

You will need to confirm with your board using a multimeter, but for my E01S, the track with the big leg of the battery running closest the edge of the board was negative. The inner track with the double-leg was positive. Locate any NiCad battery that packs away 3.6V (a fairly common voltage, oft used for NVRAM protection, you could try salvaging an old computer?) and hook it in place of the battery you just removed. A few neat solder jobs and all will be perfect.

Here you can see the battery pack (from an old laptop) that I have installed into the FileStore. A piece of Scotch tape can be seen holding the battery pack in place to stop it clunking around.
Is it just me, or does the sticky on that Scotch "invisible" tape smell like pineapple?

In the future...? (2008/12/21)

If you have, or know who has, the rights to the sources for the E01S firmware, please get in touch! I very much doubt there is any commercial value in this whatsoever, given that increasingly, even from people who know of Acorn kit, I hear "what's Econet?". To me it seems shocking that the ROOL bloke replied not knowing what a FileStore is, but we have to face the fact that it's a bit of kit some 20 years old.

Why am I so eager for the sources? Well, the FS appears to be dependent on two specific models of Rodime SCSI harddisc. A 40Mb and a 60Mb. That's MEGAbytes. What I wish to do, as fix-it #1 is to remove such dependency and make it so that it can use any SCSI harddisc, even if it is limited in what it can address (like only using 60Mb of a 512Mb drive?). This dependency is annoying as I have a 20Mb drive from an Apple and a 200Mb drive from the old MDFS, and yet the FileStore won't speak to either. Somewhere around I have an actual Rodime of the correct type, but the FileStore won't talk to it because one of the drive controller pages needs to be set up in a specific way. It's a lot of protectionist nonsense, I suppose to prevent DIY upgrades of the FileStore different to that which Acorn wished to sell (for I bet the E40S unit cost rather more than a 40Mb SCSI harddisc!).

The second thing I would like to do? I plan to rip out all printer-related features, remove the printer functionality, and replace this with a small DIY module to talk SPI to an SD card. Again, we may be limited in a cheap 1Gb SD card (which you can buy for as little as €5) being a 60Gb 'harddisc'. I plan to remove the SCSI code and replace it with SD interface code and make the card 'appear' as a harddisc. And in place of the printer code? I plan to extend the *Format functionality so that it can format the SD card without running special software on a client machine. Additionally, when I have a better understanding of the system internals, I would like to make a RISC OS front-end to perform drive management services, both for the SD card and also for SCSI devices; much akin to the map checker (etc) only more up to date.
Please note that there is no intention whatsoever of PC compatibility. The SD card will be converted to FileStore format (bye bye FAT), and furthermore it appears as if SDs use 512 byte sectoring and the FileStore uses 256 byte sectors. I may work around this by simply discarding the excess 512 bytes of each sector. I'll need to see how the SCSI drives work... At any rate, the use of an SD card means a complete setup can be achieved in the one box (and yes, I know SDs are 3.3v), less noise, fewer moving parts, reasonably quick (not that anybody ever accused the FS of being quick!), more up to date. And most importantly? There are loads of SD cards around. We aren't going to be tied to an obsolete device with a finite (and definitely expired) lifetime.

But all of this is dependant on having the source code to the E01S firmware, for I have no intention of working backwards from a ROM dump. Ten years ago, maybe. But I don't have that kind of time nowadays. Sorry.
So, I repeat again: If you have, or know who has, the rights to the sources for the E01S firmware, please get in touch!
Thank you.