RISC PC compatible harddrives

Hi,

Can anyone tell me which 160Gb (formatted to 128Gb) hard drives are compatible with the RISC PCs on-board IDE controller?

Many thanks,

Lee

In a RiscPC I think the largest we ever used was 80GB and it must be 10 years since we could last buy compatible drives.
IIRC they were Seagate and a change in the firmware meant models that previously worked stopped working reliably.
If a drive fails to format(Initialise) the first time with HForm but does on the second attempt then our experience is that it will be unreliable, hanging the computer randomly:-(

We have a few 40GB (PULL) IDE drives and possible one or two s/h 80GB that are RPC o.k. but they are now silly money due to their rarity.

IDEFS interfaces seem compatible with a much larger range of drives!

I managed to get a RISC PC recently which I am refurbishing (slowly), the hard disc was knackered.
I managed to get an 80GB drive off amazon for £8.99
http://www.amazon.co.uk/gp/product/B000OUG65E

It works fine and more importantly the grinding noise has stopped ;-)
I still need to get around replacing the PSU (which I got from CJE) as that isn’t sounding too healthy and solder the new battery in (again CJE), once I summon up the courage, which leaked [I cleaned it up and it’s just about OK for the moment]

I was impressed that I could actually buy one, and especially the price – in fact I may buy a couple more just because I can. (just ordered 4!)

I was recommended not to go above that for “compatibility” reasons (but 120GB should work in theory I think….maybe???)

My Risc PC has a Western Digital WD1600AAJB which works 100% reliable (formatted down to 128 GB). It gives a strange error in HForm when formatted the first time, so you must format it two times.

I also had Samsung 120 GB and 160 GB models working on the internal IDE in various Risc PCs with various versions of RISC OS, without problems.

Thanks for all your replies…
Steffen is that Western Digital 160GB the blue version? and can you remember which models of Samsung drives worked? I’m planning on building a RISC PC Jukebox so need the largest drive I can get.
Thanks again.

I had a look for the various Samsung HDs I had connected at various points of time to internal IDE Risc PC. This is what I found:

• SP1213N (120 GB)
• SV8004H (80 GB)
• SV1604N (160 GB)
• SV1204H (120 GB)

WD: ISTR a blue label, but it was bought well before WD split their range into green, blue and red. I am pretty sure that there is only one variant with the given model id.

Thanks a lot Steffen. Your a star :-)

Ive managed to find one of the aforementioned hard drives so fingers crossed it should work.

My next question…. What would be the easiest and or fastest way to get 100Gb of mp3’s from a NTFS formatted drive on to the ADFS drive?

Ouch! That’s going to be painful which ever way you do it. Splitting the files up and putting them onto floppy would be the most painful way ;-)

But seriously the quickest way would be to copy the files onto another Fat formatted HD and put the drive in the RISC PC.
That assumes your using RO 5.2x and it works with solid discs. Or that the version of RO can handle it…

You could use Omni or LanMan98 and share the disc on windows, but at RISC PC speeds that is going to be like pulling teeth, as the fastest theoretical speed you’ll get is 100Mbit (i.e. 11-12MB/sec), I’m fairly sure I don’t get anywhere near that on my RISC PC. (oh for a dual 10Gig ethernet port, not that nearly any disc can keep up with that!)
But if you have the time it’s the easiest.

I’d be interested to see what other suggestions there are!

Hmmmm…write everything onto one BD-R XL and use the Blu-Ray drive in your Risc PC to read it back via CDVDBurn :-)

Seriously: I would recommend making the MP3s available on an NFS share and copy it via Sunfish. Only works if you have an Ethernet card of course.

If you don’t have an Ethernet card, I would recommend using a Fat32 formatted HD as a transfer medium and using Fat32FS to copy the files.

The next best thing would be DVD followed by CD – but think about it, 700 MB of data per CD translates to nearly 150 discs…and finding a compatible drive nowadays is a nightmare.

Hahaha I like floppy idea.. Could even use 800k discs to make it that little bit harder ;-)

If I load RISC OS 5 onto the RISC PC will I be able to access a FAT formatted harddisc via the onboard controller?

My other thought was formating the drive on the RISC PC and then using a linux box to do the transfer… Does ADFS support on linux extend to hard discs?

I have got a 10Mb NIC in the RISC PC so worse case scenario I could transfer over that but I dread to think how long this would take… And it would probabaly need babysitting for errors :-(

If you’re doing serious work using windows shares, or want reliability I would strongly recommend investing in LanMan98 (and use the standalone version).
For me using the standard ROOL Omni is unreliable and prone to missing files – this could be just me and my “unique” environment, and my “skills” at finding bugs.

FYI, what I’ve done is connect a 2TB drive to my router (netgear) formatted with ext3 (ntfs is way too slow on them) and use LanMan98 for RISC OS to connect to it and I can access all my data from my PandaBoard, RISCPC, OpenELEC on a pi and my wife’s PC (Windows). I’m getting 10MB/sec which isn’t great considering it’s gigabit, but it’s good enough (it was 2MB/sec using ntfs, but that’s the router support for it) and the pandaboard/Pi and RISCPC are close or at there limit at 10MB/sec.
And if you want something quick (or reliable…I could go on…) you don’t want to use Windows anyway.
I can easily back it all up from my Wife’s PC using a USB blueray disc.

If you don’t have an Ethernet card, I would recommend using a Fat32 formatted HD as a transfer medium and using Fat32FS to copy the files.

Does Fat32FS work with ADFS? I thought it only worked with SCSIFS (i.e. USB attached drives)

If I load RISC OS 5 onto the RISC PC will I be able to access a FAT formatted harddisc via the onboard controller?

Not really. DOSFS is limited to disc sizes of 2GB (or 4GB with the latest version of RISC OS 5), and Fat32FS probably won’t work with drives attached to the motherboard IDE.

Does ADFS support on linux extend to hard discs?

There’s partial support, but not enough for what you’d require (more info here)

If you’re after a fast transfer speed, I think your best bet would be to forget about using the RiscPC for any of it – the onboard IDE and the network interface are just too slow for the amount of data you’re talking about. Instead the approach I’d be tempted to try would be to create a 100GB ADFS disc image for use with an emulator (e.g. RPCEmu), and then use the emulator’s HostFS support to copy the files onto the ADFS image. Then write the image to a real hard disc for sticking inside your RiscPC. This does mean you’re going to be copying twice as much data, but it’ll all be done locally on a nice fast PC instead of over a network to a 20 year old relic of a bygone age ;-)

Unfortunately this approach may be a bit fiddly to get working correctly. It is possible to take an image of an ADFS hard disc and mount it in RPCEmu, but it needs some fiddling to get it into a format which RPCEmu is happy with (I’m not sure if that’s due to RPCEmu being fussy or the common disc imaging tools being insufficient). I’m yet to try taking an image from RPCEmu and write it out to a hard disc, so I’m not sure what’s necessary to go in the other direction. The first sector will definitely need trimming, but can the boot block be left as-is, or does it need restoring from the original? (assuming you created the image from the same drive you’re restoring to). Or can you calculate a new one?

That HostFS idea is genius!

“a 20 year old relic of a bygone age” – as against a x86 PC which is a 30 year old relic with massively fudged hardware.
(You are right, but I just can’t resist a dig at x86 hardware – it’s dismal)

The HostFS-ADFS-image-idea is great in theory. However, RPCEmu is not really reliable writing ADFS images, and is very slow to do so (compared to a Risc PC, it is still quite fast). And you’ll have to find a PC which still has an IDE port – last few motherboards I have seen were S-ATA only. So you need an adaptor, either S-ATA-IDE or IDE-USB. And that is only the fun on top of the fiddling Jeffrey described.

I still favour the NFS idea. With your 10 Mbit/s network card, you will get around 800 KB/s with Sunfish, which is basically FTP speed. So you’re looking at a 36h transfer time for your 100 GB, which seems quite acceptable compared to endless emulator-fiddling-trial-and-error.

To give you an idea of how slow RISC PC hard disc transfers are, I’m copying 2GB from one disc to another. It’s taken over 45mins (might be over an hour and a half when it finishes).
I’m thinking it maybe quicker to try copying the files using vi and learning how the filecore filesystem works off by heart.
Shessh it’s slow!

I could be wrong, but my guess is copying over the network is going to be quicker than between hard discs.
Copying over the network seems the best way.
NFS is damed good for local copies (I’ve had around 300MB/sec across a dual gig network through NFS, without the server breaking a sweat [I suspect the switches may have nearly melted though!])

I’ve had around 300MB/sec across a dual gig network through NFS

“dual gig network”??

If you’re talking about a trunk connection of two gig lines (or indeed 8 lines) then transfer between two devices will max out at about 900Mb/s

It was two gigabit ethernet cards, the actual speed was slightly less, around 270MB/sec but using dd gave me up to 350MB/sec (NFS caching at play)

It was two gigabit ethernet cards, the actual speed was slightly less, around 270MB/sec but using dd gave me up to 350MB/sec (NFS caching at play)

lower case b in Mb/s please.
MB would be bytes and would require transfer on the single link of approximately 3Gb/s for 300MB/s

BTW, once the endpoints know the destination the transfer is MAC endpoint to MAC endpoint which doesn’t load share across LACP groups, etherchannel, MLT¹ etc. OK, too much detail, I’ll get me coat…

¹ Nortel² proprietary multilink trunking

² Avaya these days

That was MB not mbit.
You mean “Norhell” ;-) that explains why Avaya is over priced ****
Cisco uses the same kind of logic too.
Thinking back that one was server to server. An old dell server with a load of discs feeding a modern dell server with plenty of RAM using the old dell server as an NFS share for a kvm redhat box.
But you can use bonding where the MAC addresses on the card change on the fly, finding switch support for that is “interesting”, I think that’s something like adaptive load balancing?

And you can get around 120-140MB/sec off one if you tweak enough (the main one is having extreemly good cables, and maximum MTU – but that’s the starting point)
Maybe the measuring metrics were off?
I was hoping to have a go (well not me per say, pester networks) at some 10Gig switches as we had a similar NAS setup, but there was some weird ass MTU issue between the switches. We ended up having to use HP branded cisco cables, for some reason the normal HP ones nor the normal cisco ones worked.
Not enough time to play unfortunately, but the throughput on that was only about 60-80MB/sec
FCP FTW :-D

Oh and it’s finally finished copying…shessh! best part of three hours to copy 2GB from disc to disc.
Or it feels like that long!

Has anyone tried an SDXC to IDE adaptor? 64GB SD cards are now about 20 quid, and (in theory) using SD rather than CompactFlash means that, once you have a working adaptor, any card should (ha ha) work. It would need to be SDXC as SDHC tops out at 32GB. 128GB are a tad more expensive though.

We stock a number of SD to IDE adaptors (40pin Male, 40pin Female and 44pin Male) they are listed by our supplier as:
SD SDHC SDXC MMC,
SD SDHC MMC,
SD SDHC SDXC MMC,
card compatible respectively. We also have a 40pin Male on a PCI bracket I can’t currently find its compatibility list.

When we get a chance we’ll try them with a 64GB card.

Oh and it’s finally finished copying…shessh! best part of three hours to copy 2GB from disc to disc.

Not a surprise. The RiscPC’s I/O bus clocks at a mere 8MHz; and since podules run synchronous at that speed, you just aren’t going to get any better. It was… slow… even by the standard of the day. PCI (33MHz) predates it by a year, VESA (also 33MHz) predates it by two years.
But even prior to that (accounting for the design time of the hardware), it was becoming clear that the (E)ISA bus running at 8.33MHz was too slow. I guess Acorn figured that sticking with 8MHz meant all the older podules would keep on working (and indeed, in my RiscPC, they do!), but maybe it would have been great if the IOMD could switch up the clock speed of compatible podules to at least 16MHz, better 32MHz. In RISC OS land, it is common to attach additional filing systems as podules. It is a shame that the technology did not progress much over that available on the original Archimedes.

When we get a chance we’ll try them with a 64GB card.

Don’t worry if you get “Unknown disc format”¹ messages on a fresh 64GB card. IIRC, the official SDXC standard specifies the use of the (proprietary) exFAT format; though market forces may make them be sent out as regular FAT32 (and to hell with standards).

¹ Disc? DISC? Anachronism! ☺
That said, a lot of stuff still uses an icon of a 3.5" floppy disc for saving; I wonder how many of the younger generation have ever used one of these:

PS: Hey kids – I’m such an old fart, I’ve actually used one of these:

Capacity? I think it held around 160KiB.
So that means your average eight minute rock ballad weighing in at around 12MiB would require approximately 78 discs. Don’t ask about transfer time. The discs loaded in sideways and took forever to do anything. I don’t recall what sort of computer it was, but it predated the BBC Micros. I seem to recall it didn’t even have a processor, in the modern sense. I saw inside it once and I think it was the first time I had ever seen a wire-wrapped board. Specs will be something comical like “8K” clocking a dozen hertz, or whatever sounds plausible for a machine playing spelling games with dyslexic kids where the so-called computer took longer to ‘think’ than most of the kids.

Alas, for our music, back then we used these for our music (a C60 offers 60 minutes playing time, 30 minutes a side; which can also be used to hold data, running to about 90KiB/side for a C60 using Acorn’s 1200 baud encoding):

And finally, before I like shuffle off and die of old age or something¹, really serious software came on one of these:

Bigger than a USB key and holds about 16 thousand characters. That’s 16KiB. Kilobytes. Not Giga, not Mega, Kilo. Or Kibi if you want to be “correct”.
As I’m sure you can understand, replacing those would be a monumental pain in the ass (mask ROM (no window) would need to be discarded; the ones with glass windows can be reprogrammed after ~15 minutes exposure to UV light; programming can take several minutes each). Accordingly, back then we valued software that actually worked when it was released. There was no “download an update” or “reflash your operating system”. It was sold, it was installed, and people with old computers are probably still using View and EDWORD and the like today. It had to work, or a company’s reputation could be ruined.

¹ Yes, I am taking the …. somewhat, but you guessed that by now, right?