Ouch! Ouch! Ouch!

http://youtu.be/tPq7OF3fkcE

I think I had better check my old boxes soon…

I pulled mine from the loft quite recently.

Both RiscPCs had leaky batteries – which I snipped off – but there was no visible damage to the motherboards. They both seemed to only need a wipe clean.

However, one didn’t boot, with floppy drive light flashing what I think was video interrupt timing failure. :(

The other booted and, but (after a while and a good old root around) the hard drive failed. I swapped in the drive from the other to have a look through that one. (That was the real purpose of getting them down – to look for some stuff, as well as check the contents of some floppies I’d found).

The A3000’s battery looked absolutely fine – but I don’t seem to have its monitor (nor either of the two monitor leads I had – not that the leads mattered; if I had them, I’ve nothing to connect it to!). I did power it up, and it sounds okay, but you never really know. I didn’t remove its battery, but when I put it back I stored it downside up – so if it does go funny, it’ll do more damage to the keyboard than the motherboard.

That means – short of finding more floppies or CDs in previously unexplored corners of the loft (or the Cupboard of Doom) – the only place left for me to seek out missing stuff is the A3000 hard drive. :(

I recently got a Pi with a view to shifting all my old RiscPC stuff onto that. I had four RiscPCs that I’d bought cheap when my former employer downgraded from them to PCs not long after I left. I’d been using one of them every now and then and knew that one was working okay, but thought I’d get rid of a couple of them (to the Cambridge Computer Museum), very likely to use for parts – but found all four of them still worked fine, despite having been neglected for best part of a decade in three cases. The batteries of all four were a bit furry, but fortunately they’d not leaked onto the board. I hope the museum has dealt with the batteries on the two I gave to them; I’ve done the two I’ve kept (off-board NiMHs) and they’re doing fine.
(I haven’t got round to sorting out their networking yet – they were talking to each other but not to the Pi until I tried to make them talk to the Pi; now they don’t talk to each other either. Ho hum. The Pi talks to the internet no problem with dynamic allocation; with a fixed address the RiscPCs can see it’s there on ShareFS, but can’t actually read its hard drive, and the Pi can’t even see the RiscPCs are there. I can probably sort this out myself when I get my thinking cap on, but any hints would be gratefully received! I’d be very happy just to get the RiscPCs talking to the internet & email myself, which is how I transfer stuff between the PC and the Pi. The current communication from RiscPC to Pi is a bit crazy: floppy to the PC (usually with a Spark archive on it) then email to the Pi!)

then email to the Pi!

The irony, I do this a lot these days thanks to the iPad’s solid refusal to talk to anything that isn’t Apple. For instance, Bluetooth send and receive? Forget it. Plug’n’play USB connectivity? Forget it (iTunes is horrible). Plug’n’play photo device? Forget it (all too often I get a list of zero sized files so I must reconnect it, more than once).

So I find it quickest to get photos to my PC is to email them to myself, pick them up on my phone and Bluetooth them to the PC (saves loading Thunderbird). For documents? Google Drive is the intermediary. Thanks to the iOS sand boxing, network sharing just won’t happen, period.
Sometimes I wonder if this isn’t a retrograde step as Apple’s mindset seems to be stuck back in the ’80s…

Anyway, long story short – sometimes emailing stuff to yourself is the simplest way. ;-)

You could use Google Drive to transfer photos too (any type of files at all, really) always provided that you have sufficient room—but the default allocation is quite generous anyway.

You can’t of course access Google Drive from a RISC OS box—it won’t recognise the browser. It will work with Midori on the Pi (on Linux) though it thinks it’s an outdated version of Google Chrome…

AIUI iDevices pretend to be photo devices. There used to be (maybe still is) a library libimobiledevice for Linux that helped with this—if you used t it was best not to upgrade iOS until the developers had a chance to produce a new version of the library…

Plug’n’play photo device? Forget it

I’ve never tried an iPad, but I was surprised a few months back to see that an iPhone behaves like a standard MTP device, and was fully readable by my MTP app.

If you try it, please let us all know how you get on.

any hints would be gratefully received!

The first suggestion is to give all the devices on your LAN fixed IP addresses. Then you can put them in the Hosts file, which you can share across all devices. That’s much easier than dynamic allocation.

After that, it should be standard network handle cranking. You should be able to ping each device by name from every other device; if you can’t get that far, then we need to look at the symptoms for each dvice that won’t play.

Yup, I know all that from non-RISCOS networking. My problem at the moment is changing any but the least significant byte of the IP addresses of the two RiscPCs. This is probably that I don’t have the correct drivers for the cards. *SetStation seems to set the least significant byte and randomize the others…
(and ShareFS only shares between devices “on the same network”, that is, with the same top three address bytes).

But thinking about that does give me an idea: I’ll try giving the Pi the same top three bytes as one of the RiscPCs, since I do have control of them on the Pi…don’t remember whether I tried that before.

I have my RPi connected to my RiscPCs using ShareFS and this works OK for transferring files (fairly slowly but then RISC OS files are usually very small and compact). All are on the same IP subnet (10.0.0.x). The RPi receives its IP address from a DHCP server and the Risc PCs are configured with fixed IP addresses.

Just looked and the RPi is not even configured in the Risc PC’s (static) hosts file. But it still works – I get the RiscPC drive icons appearing on the RPi icon bar by magic :-) To get the RPi drives to share their files back onto the RPi you need to enable the RPi share(s) manually from the command on the RPi line IIRC. Details are on this forum passim.

Note that the very early RPi RCxx releases had issues that stopped ShareFS from working correctly.

I hope this helps,

Ralph

I don’t think ShareFS even looks at the hosts file. As long as the stations are all “on the same network” and sharing, all works. Or used to. But I can’t set the top bytes on my RiscPCs – probably just that I don’t have the proper drivers for the cards (different types) in them. Each network card has stayed with the same machine all along, but the hard drives haven’t. Don’t worry – I’ll sort it eventually. It’s not actually all that important to me for now – I’ve already moved everything I want to do at the moment onto the Pi.

Only later versions of RISC OS SELECT or 5.20 can do DHCP on a RiscPC so it will be using the Acorn default IP Address of 1.×.×.x MASK 255.0.0.0

You can’t change easily the address and mask without being able to run !Configure AND have a softloaded ETHERA (the last letter A will need changing to the correct letter for the NIC used). UniBoot has the necessary I believe.

If you need to get the correct boot system on to RiscPC via a network, you will have change the network to the RiscPCs subnet at least temporarily.

My problem at the moment is changing any but the least significant byte of the IP addresses of the two RiscPCs. This is probably that I don’t have the correct drivers for the cards. *SetStation seems to set the least significant byte and randomize the others… (and ShareFS only shares between devices “on the same network”, that is, with the same top three address bytes).

*SetStation is for Econet/AUN. Never ever ever let AUN near anything else. It uses extremely non-standard addresses (Class A, netmask &FFFF0000) in the form 1.<network>.<net>.<station> so the Econet address #1.254 (file server on net #1) would become something like 1.1.1.254 in AUN. The problem is, that IP address exists, in Brisbane [http://db-ip.com/1.1.1.254] so if your AUN machine is connected to a router, perhaps communications are failing because your packets are ending up in Australia?

For Access and TCP/IP – have you tried this? http://www.riscos.org/networking/riscos.html

For myself – I used to use SMBserver and OmniClient. Described here, but note that it is JURASSIC http://www.heyrick.co.uk/mynet/index.html – have a giggle at the bits regarding setting up Windows 3.11!

With a more modern setup… frankly… I WiFi stuff around and either use a USB key to the Pi or drop the files on a local server and pick them up with NetSurf.
My Livebox supports sharing USB devices “\\livebox\etcetc” but for some reason OmniClient can’t “see” any of this. More fiddling required.

Ah – thanks Rick – that explains it. Sadly, I don’t have USB on the RiscPCs. PC/Pi communications aren’t a problem using email, it’s only the RiscPCs I’ve got problems with.

Lord knows where my packets have been ending up – not Brisbane, the addresses (I can read them, I just can’t write them) are w.×.y.z where z is what I set, and w, x and y are apparently random. Presumably SetStation is setting my one, and perhaps because I’ve got the wrong drivers, stuffing the others up at the same time (as I say, Access used to work between the RiscPCs until I used SetStation. These machines used to be on the same network, but talking to the wider world, set up by the network manager at my former employers. I’m a fairly competent RiscPC hacker – particularly ARM Assembler, wrote the ARM Assembler Guide & the instruction sections of the ARM Architecture Reference Manual! – but left the networking to him and only got into networking on PCs after I left there.)

If they’d been 1.1.1.z at least my two RiscPCs would be talking to each other. I did have a go with http://www.riscos.org/networking/riscos.html but the first shot drew a blank – both RiscPCs come up with greyed-out networking on !Config, which is presumably because I’ve got the wrong drivers for the cards. I think I know what to do about that, but haven’t yet got a round tuit.

Ah – just saw Chris Evans’s post – missed it at first. Thanks Chris, I rather suspected it might be something like that. I might just stick with the floppy route from the RiscPCs – they’re basically retired, superseded by the Pi for everything I’m thinking of using RiscOS for. I’ve got !Draw & !FontEd & some of the apps I wrote myself working on the Pi, and can fix those of my own apps that don’t work (26-bit assembler stuff). My own fonts have all come over okay – but I’ll update them before I release them into the wild.

Sad to lose my old Impression Publisher articles, but I’ve got the text and images from all of them.

Could fix the relevant parts of the boot system taking files via the Pi (which talks to the wider world nae bother), email to the PC, then floppy to the RiscPCs, but I don’t know that I’ll bother…don’t want to mess with the network, would upset the rest of the family on their Macs & PCs…and the two RiscPCs are currently on DIFFERENT networks, just to be totally stupid.

Sad to lose my old Impression Publisher articles, but I’ve got the text and images from all of them.

You could always invest in a copy of Aemulor to run 26-bit legacy software.

Indeed, but for the moment I can also run it on the RiscPCs. And I’ve got printed copies of the articles as well as the text and image files. Were I ever to want to re-use bits of them, I’d have to put them on the PC somehow. It’s probably as easy to recreate them manually from the separate text and image files as to try to convert Publisher files to anything PC-editable.

I’ve already done one: Diacritical Marks & Special Characters

(Interesting. That seems to have hooked an Australian and a Nederlander… 8~)

Clive, you’d only have to change the IP Address temporarily of the computer you wanted to copy to or from. I’d think that easier than using floppies!

I thought I could do that with the Pi, but then the RiscPCs could see the Pi’s hard drive, but couldn’t open the root directory, and the Pi couldn’t even see the RiscPCs. Mystified I was. That was trying to use ShareFS.

Will try again. I might have been doing something stupid if I was tired at the time!

Depending on the Pi ROM version/Hard drive image you have I think the Pi can default to 10.×.×.x
Change the address on the Pi.
To share the Pi’s SD card you will need to use an obey file
*share sdfs::0.$ PiSD-Card

Yup, I changed the address on the Pi. I was trying to share a hard drive I’ve got on the Pi, and as I say, it’s visible on ShareFS on the RiscPCs, but then they give an error message – I forget the exact wording, but something to the effect “Wot? No disc?” when I tried to access it. And although I’d shared the hard drives on the RiscPCs, the Pi couldn’t see them at all.

But I’ll go away and have another go. I was probably doing something daft.

Here’s a thought – that hard drive is 149 GB. No problem for a Pi, but is that why the RiscPCs can’t access it? Still no explanation for the Pi not seeing the RiscPCs’ 6 GB, 4 GB, 400 MB and 260 MB drives though.

Will try sharing the SD card – never thought of trying that.

I don’t know if it’s of any help, but many months ago, I managed to get my RPi and RISCPC on the same network. I wanted to transfer some stuff from CDs and hard drive on RPC to RPi to see what might still run. I ended up creating a shared RAM disc on the RPi that the RPC would see and write to. Details are foggy, I’ve slept since!

Not sure if this is the problem but ‘Pushing’ files with ShareFS to slower RISC OS computer rarely works reliably¹.
If you want to move files from the Pi to a RiscPC then on the RiscPC ‘Pull’ the files to the RiscPC.
If you want to move files from the RiscPC to Pi it probably shouldn’t matter but pushing them to the Pi should be the most reliable.