Rescuing an old FileStore

EEA index

Error codes
Disc format
Disc image
Password file
E01 vs E01S
SD card

Misc h/w
Misc info

In the beginning...

So I was talking, by email, to Johan the other day (mid-August 2007) about various FileStore related things. And, well, I got to thinking that I ought to dust off my FileStore after leaving it languishing in a box for over five years.

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

Now that I had something to talk to the FileStore, I set about starting the FileStore. I connected it and the A3000 back-to-back with a drop lead, as the FileStore's own clock would kick in.

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.

FileStore status indicators


Maybe it is in Maintenance Mode?

It would do that if you boot up with the front flap open. When I obtained this FileStore, it was on the basis that the door open sensor was broken. So I wired in a switch to allow me to choose the state of the door. That was, like, nearly a decade ago. The switch had stuck and I didn't know in which way.

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:

FileStore front panel jumper connections

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?

By this time, the server had started to respond. When the spanner told the server that the door flap was closed, it looked for floppy discs. I then closed the door flap and nothing happened.

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:

Fixing the sensor
Now the server had determined when the flap was open or closed. I was able to find two DD floppy discs and format them.


Wait, how did you log in?

Okay, let's back up a step then. Switch the server OFF. Open the flap. Switch the server ON. Count to fifteen (about the length of time it takes to perform a full start-up) and then, on the station, log in as "Syst" with no password.
If you are planning on breaking into an active working FileStore using this method, I would be surprised if it works.
This is because the FileStore has a command which lets you change the user that you can log in as while the server is running in the "flap open" mode (and basic security protocol would require any decent network administator to change this to anything other than "Syst"), therefore it would then only work if you logged in as Aurelie or Brittany or whatever.

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...

You may find that !FSUtil crashes (error in or around line 1199 or 11990) when you attempt to read the real-time clock. This is because the default date of the FileStore clock is 1900, but NetFS does not like dates prior to 1981 (when time started according to Econet).

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"
Modify the code by prefixing an 'X' in front of the SWI name as follows:
  SYS "XNetFS_ConvertDate",fstime%,rotime%
  SYS "XOS_ConvertDateAndTime",rotime%,timestr%,68,"%24:%MI:%SEh, %DY/%MN/%CE%YR"
This instructs BASIC to ignore errors and return with the error flag set, instead of raising an error.
The result of this is that !FSUtil will show some bogus values for invalid dates, but you can at least then instruct !FSUtil to then set the correct date and time (taken from the RTC of the station that is running the software).


And then what?

And then I turned it all off and watched the lovely German film Mostly Martha (review here) for about the third time.


Disaster strikes!

The next day I go to boot the FileStore and it hangs, again, with the red indicator. This time I know it knows it is supposed to boot up in user mode. Only it doesn't.

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

I have not made much further use of the server at this time, however I have left it on and running during the daytime for the last two days in order to refresh the battery. This morning it started without a problem, and I think it'll behave now, at least for the lifetime of the charge in the battery. Note to self: I'd better turn on that old PC as well - same reason.


In the future

There are some interesting concepts in the "idea" stage, but these ideas have to take time to become. In any case, I think you can say that there is life in the cream-coloured critter yet.

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.

My FileStore's new home



Replacement NiCadTurning on my FileStore a week later, it 'hung' at the red light for about fifteen minutes, then started. What, is that some sort of insane time-out?
I think we can assume that the NiCad battery is suffering a somewhat excessive internal leakage (perhaps some corrosion?) and thus can't hold current for very long. It works overnight, but not over a week. I suspect I'll have to unsolder the battery and fit one liberated from an old laptop. It isn't the same, it is a three-mini-AA type (pictured right), but 3.6V is 3.6V.


Upgrading the firmware (2007/09/03)

While Googling for any additional information on the FileStore, I happened upon a ROM set that claimed to be version 1.40.00. I figured this may have been a worthwhile upgrade from my v1.33.

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.

There you have the reason for the 'Hugo' directory markers and the 'JesMap' map sector markers. ☺

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).

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...?

A5000 and programmer.
The programming process for this setup needs to be done in two passes, the lower 32Kb and the upper 32Kb (as the programmer has 16Kb onboard, and 16Kb in the BBC micro is used).
I did borrow, many years ago, a really cool EPROM programmer that connected via serial port and offered a 'terminal' to upload/download EPROM images, and it could hold, if I remember, 128Kb on-board. As if that wasn't enough, it had buttons on the front to control it, and an LCD too, so EPROM-to-EPROM copy was possible without a computer attached. If you have something like this, then making up a new EPROM will probably be a trivial matter.

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
Programmed EPROM.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?

The EPROM in place.

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

The EPROM in place (better picture).

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...

My !FSUtil makes several assumptions about 'safe' places to poke data and code for extracting information from the heart of the server (i.e. NVRAM bytes). Not only will !FSUtil fail to do it properly, you may also experience server errors and/or crashes. In many cases the server will appear to be okay, but !FSUtil will have received bogus data.
In short, if you use !FSUtil, don't...

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

My NVRAM is prone to 'failure' due to the original battery being old and not able to hold charge for any length of time. I fitted a new battery, but before I did so I wrote a program to poke in a sane state to the server...

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 HAS *NO* ERROR CHECKING, add this yourself. :-)
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 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("FSMaxUser 8")
OSCLI("FSMaxDrive 5")
OSCLI("PrPage Y")
t% = TIME : REPEAT UNTIL (t% + 300) < TIME
OSCLI("I Am " + login_name$ + " " + login_pass$)

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%
  year% = 19 + year%
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!


  LOCAL out%, temp%
  out% = val% AND &0F
  temp% = val% AND &F0
  temp% = temp% >> 4
  out% += temp% * 10
Download fspoke.txt (as a text file)


Changing the battery (2007/09/09)

It is not easy to unsolder the battery as the metal leg connects to a larger lump of metal which connects to the metal of the battery itself. This is further hampered by corrosion which affects the conduction of heat from the soldering iron.

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?

The new battery pack in place.

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

It has been a long time since I have done anything with my FileStore, almost a year. And it has been equally as long since I have been in contact with Johan; but this doesn't mean I have given up. I am still trying to track down sources for the FileStore firmware, as it will be so much simpler than a disassembly, especially as I am not that practiced in 6502 code.
My most recent pointer was somewhere that suggested that RISC OS Open may have the rights to all of the versions of RISC OS (except the 4/Select/Adjust variants) plus sources going back to the BBC Micro era. I am surprised that ROOL would have all of that, but I thought I'd ask. The reply so far? "What's a FileStore" (paraphrased). Well, of course I pointed them here! But I suspect my next port of call will be Castle!?

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.

This has its own page...

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.

Copyright © 2009 Rick Murray