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.
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'.
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 lightNow 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.
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.
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.
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:
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.
The network icon will display "!254".
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 awayI 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 futureThere 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.
For now my FileStore has a new home atop the Ethernet hub.
AddendumTurning 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
You'll also need the EPROM images (v1.40.00, © 1989 Acorn Computers).
Step Two - program it
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.
Step Three - check it
An easy way to check, the MOS, in the upper block has forty bytes of code (data?) at the start, followed by loads of
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
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?
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
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.
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?
A quick way to set a sane stateMy 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 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)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.
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.
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.