Painless way of copying Filecore hard disks for archiving

Having tidied up my spare room, I have 3 RiscPC systems that have been in storage since 2007. They worked when I disconnected them just before I moved house. I popped the lid off the two single-slice units (one Arm710, one StrongARM) and the battery looks fine, no furring. But I couldn’t see down into the case of the 4-slice machine (StrongARM, 128+2MB RAM) to determine the battery condition.

Anyway. 4-slicer has 3 hard drives in it (2x 1.2GB IDE, 2GB SCSI). The single-slices each have an IDE drive, 210MB on one and 420MB on the other. One of the single-slicers has no NIC fitted, the 4-slice has a 10Mbit card, the other single-slice has a CTA/Simtec 100Mbit.

The problem being that all these systems were set up on an AUN network with an A5000 running Level 4. I haven’t run them for so long that I cannot remember where anything is. So what I want to do is archive off everything to, say, a unix box. I want to do this using a file-based method, not simply grabbing an image of the disk.

So, what’s the recommended method out of:

1. Assuming the system will boot, mount an NFS share with OmniClient (I’m sure there’s a copy of that on at least one system) and copy everything across.

2. As 1 but use SMB/LanMan instead. I gather there’s some issues with LanMan on the newer versions of Samba though.

3. Connect the disk to a USB-IDE interface and mount it on a system that supports Filecore, eg NetBSD. Some of the disks are in F format, some are in F+. I managed to softload the RO4 filecore on 3.7, and in the case of the machine with the Simtec NIC I also flashed it into the ROM on the NIC so the boot disk could be F+. (This won’t solve the SCSI disk problem though, but I think that only has some old Fidomail stuff on it.)

4. Some other way that I haven’t thought of.

Anyone suggesting using DOS floppies to transfer stuff will suffer death from a thousand cuts!

I’m leaning towards transferring this lot over the network, but the question is which protocol would be a. fastest and b. most reliable? The options I have are SMB, SCP/SFTP or with some tweaking on the server FTP or NFS.

Suggestions gratefully received. If successful, I intend to release a whole stack of source code for RO apps that I wrote years back as I no longer have any commercial interest in the platform (although I still follow it as a former user).

3. Connect the disk to a USB-IDE interface and mount it on a system that supports Filecore, eg NetBSD

You have a Raspberry Pi, don’t you? In case you haven’t noticed, a Raspberry Pi can run RISC OS, and RISC OS supports Filecore :-)

So if you have a USB-IDE adapter handy then that would probably be the easiest & fastest way of copying everything off the IDE discs, assuming you don’t mind the hassle of stripping the RiscPC’s down so you can actually get the discs out. Not sure what to do with the SCSI disc though – you can buy USB to SCSI adapters, and theoretically they will work with RISC OS, but I haven’t actually heard of anyone using one. But short of shelling out cash for something you’ll only use once I suspect the easiest approach would be to try booting the machine and then squeeze any files you’re interested in into the spare space on the other two drives.

Note that one alternative to OmniClient and LanMan is Sunfish, although it uses NFS rather than Samba and so may need a bit more tweaking to make sure NFS is enabled on a modern Unix box.

Anyone suggesting using DOS floppies to transfer stuff will suffer death from a thousand cuts!

OK, The old Beebug serial transfer link then :-)

Seriously, SMB or possibly NFS sounds the best options.

If you have a Pi, couldn’t you just copy using the normal acorn network protocols?

For one off connections to linux machines, I have found Moonfish on RISC OS and mounting the nfs from the linux command line to be easy and reliable.
Moonfish only needs to be told what directory to share, eg Public directory.
On a debian/ubuntu type of linux

sudo apt-get install nfs-common
mkdir AcornStuff
sudo mount 192.168.0.42:/Public AcornStuff

It should also be easy to share the whole drive with ADFS::HardDisc4.$ in Moonfish and mounting just 192.168.0.42:/

Changing the ip address to that of the Moonfish machine, and the correct RISC OS drive name of course.
Moonfish setup will let you drag and modify the RISC OS HardDrive path.

I do have a Pi, except I only picked up the 4GB Noobs card. RO needs the 8GB card (unless I write out a custom one).

Sounds like that might be the best option, booting into RO on the Pi and slinging everything across the network.

As I said in the OP, if I can get everything dragged off the 4-slice RPC (which was my development machine) there’ll be some interesting sources released into the public domain. Anyone remember FidoMail?

If you have a Pi, the best is probably to use it as a NFS server, under RISC OS. I do that on my Pandaboard. It’s a bit a surprise, but as NFS + web server, RISC OS is rock stable.

I’ll probably use it soon as media server soon, with remote control via OSCliD. The only problem is the FTP server : it crashes after a few hours. Strange.

Ah, FidoMail…I still miss it. When Fidonet died and Internet Mail/Usenet took over, it was a long and hard way from the extremely nice user experience FidoMail provided to the harsh reality of ReadNews, TTFN, Newsbase and finally Messenger (Pro). Only real problem of FidoMail was its limit of the 16 MB message base.

I guess Fido people migrating from DOS still miss the nicety of GoldED…

Glenn: You don’t need an 8GB card for RISC OS Pi. Just grab the official RC11 (non-NOOBS), which works on 2+GB cards.

Steffen – we lifted that limit soon after taking it over from Thomas Olssen (who originally wrote it), along with the “max 256 message areas” limit. Took some doing as both the area ID and message offset were folded into a 32-bit word.

If memory serves, myself and a chap called Miah Gregory (wonder what happened to him?) managed to extend both to a 32-bit unsigned, giving a max heap size of 4GB and a similar number of message areas.

We also implemented a Wimp message API, allowing external programs to access Fidomail’s message base (the thinking being ArmBBS sharing the database). Unfortunately the whole network fizzled out shortly afterwards…

Richard – you need an 8GB card to use the NOOBS installer. I may just pick up a 2GB card for RO, and leave the 4GB one with NOOBS/OpenELEC installed.

Have just ordered another SD card for RO, and an IDE-USB adaptor. Will keep you posted.

Update – the 8GB SD card has arrived (I just used NOOBS to install RO, given that at present I’ve had 3 hours’ sleep out of the past 24 I figured it was easier just to do it that way). The Pi has gone straight onto my network, DHCP enabled, and joy of joys, OmniClient is included in the distribution. (Shows how long since I used RO as a serious desktop OS – OmniClient had to be bought seperately back in those days.)

It’s connected to my Samba/NT domain just fine and I can read and write to the shares on the server. So, just waiting for the USB IDE adapter and I can yank the disks out of the machines upstairs and get everything archived.

Further update:

Have now copied the entirety of “Wallace” (the secondary hard disk) to a Samba server. I stripped the machine down to extract “Gromit” (the primary) from the base tray. The battery on the RPC’s motherboard looked like a sci-fi B-movie prop.

The good news is the furring seems superficial, so I’ve snipped the battery off and cleaned the board up. It looks fine on a visual inspection so I might try powering it up later. If the board still works I’ll source a new battery. Am I right in thinking that it’s a rechargeable type on those machines?

Am I right in thinking that it’s a rechargeable type on those machines?

Yup

http://acorn.chriswhy.co.uk/docs/Acorn/Manuals/Manuals.html#TRM

last link on page (zip file) set of pdf files

circuit diagram sheet 1 of 7 bottom left shows the battery circuit. APDL do a replacement that sits off board with no chance of knackering the board if the replacement dies. (They also do a on board version)
Since you snipped off the legs of the old cell you have done half the replacement sequence in the off board cell replacement.

You could spend more and replace the disc with solid state stuff

Great, so it’s just a standard 1.2V NiCd cell (and a NiMH replacement can be dropped in). I can get those from Farnell for about a quid each, probably less if I buy a job lot. Might replace all of them with off-board batteries just to be on the safe side (there’s two more RPCs, two A7000s, 3 A5000s, an A4000, 2 A3000s, an A3010 and a couple of dozen A3020s kicking around here).

I have a small carrier board with a pair of 2GB CF cards installed, ready to go into the machine as long as it still works. I also have another one with 2×512MB ready to go into the A5000 which has the ColourCard and FPA10 fitted.

Unfortunately it was worse than I thought, the motherboard in the 4-slicer was terminal. However, the good news is I managed to get everything off the hard drives.

Further good news is that the StrongARM card, 2MB VRAM and both 64MB SIMMs work, having tried them in a second RPC motherboard.

The only problem now is that all my distribution code was MakeApp’d then Squeezed, and won’t decompress on a 32-bit system. I may have used Crunch rather than Squeeze (higher compression ratio) but obviously I have the sources so all is not lost.

all my distribution code was MakeApp’d then Squeezed

Please do not take this comment to be derogatory, but I am really puzzled why BASIC programmers go to the trouble of concealing their source code. The days of commercial competition on our platform, when authors needed to conceal their sources, are surely long gone. The same applies to the need for compression because of scarce memory resources. The only consequence, in most cases, is that every time there are hardware changes software is irrevocably lost. Or is there some primal instinct to scuff out the traces of one’s footsteps lest the hunter track one down? The sources of a program are not only useful for rebuilding it on new hardware, but are educational for newbies who want to learn to program. As that wonderful book, SICP (Structure and Interpretation of Computer Programs), points out, programs should chiefly be addressed to human beings. That computers can understand them too is useful, but not the main point.

I’m guessing he realizes that now, but also the impression is that the code dates back to those days.

but I am really puzzled why BASIC programmers go to the trouble of concealing their source code.

Maybe some people would like to hide the fact that they still code like it was a BBC Micro (no whitespace, run on lines, single letter variable names, …).

;-)

The same applies to the need for compression because of scarce memory resources.

The same could be said for all the crunched apps supplied by default. Time to provide them in plain source form?

Crunched apps do work quicker. My philosophy was “always assume you’re running on an ARM2 system in mode 28”.

As for MakeApp/Squeeze – most of my stuff ran from an application server. Why haul 200K of BASIC across an Econet network when you can run 80K of crunched BASIC that’s then squeezed down to 40K.

Maybe some people would like to hide the fact that they still code like

A goldfish with learning difficulties? (actually I’m not quite that bad, I think)