Using an emulator to read / modify a real RiscPC image

[PacificState]

I just bought a RiscPC with 4.39 installed, and an IDE hard drive. I'm aiming to firstly back up the hard drive, then install a compact flash card - which I understand may involve some hacking of the card and/or modification of the ADFS driver with the resources from RiscOS 5.

On the way, I'd actually like to import the drive image into an emulator - potentially (as I've done with my Amiga) so it can be updated and moved back to the CF card. I'm not sure of the best combination to do this, though, with this RiscOS version, or if the image mounting is possible - would (say) ArcEm let me do this if I dump the ROMs from my machine?

[IanJeffray]

I just bought a RiscPC with 4.39 installed, and an IDE hard drive. I'm aiming to firstly back up the hard drive, then install a compact flash card - which I understand may involve some hacking of the card and/or modification of the ADFS driver with the resources from RiscOS 5.

On the way, I'd actually like to import the drive image into an emulator - potentially (as I've done with my Amiga) so it can be updated and moved back to the CF card. I'm not sure of the best combination to do this, though, with this RiscOS version, or if the image mounting is possible - would (say) ArcEm let me do this if I dump the ROMs from my machine?

ArcEm emulates Archimedes, not RiscPC. But I'd recommend just using SparkFS or similar to zip up the drive contents, rather than messing about with a drive image in any case.

I strongly suggest you don't start trying to mix and match bits of RISC OS 5 in to 4.39. Stick with what you've got - it's more appropriate than trying to bend time. Depending on the specific CF card you use, you may need to load a patched ADFS module - but not one from RISC OS 5. You certainly won't need to "hack the card" - but if you've also got a network card in the machine, in the dedicated 'NIC' slot, then you will need to modify the CF/IDE adapter as described here.

An altogether better solution is an IDE podule of some kind - the onboard IDE on a RiscPC is just terrible.

[PacificState]

Thanks! To clarify:

- 'I strongly suggest you don't start trying to mix and match bits of RISC OS 5 in to 4.39.' Yes - this was a reference to installing !System from https://www.riscosopen.org/content/downloads/common, but it sounds like you don't recommend it

- I wrote without sufficient coffee, so I was definitely referring to modifying the adapter rather than the card itself

Otherwise, I was unaware of issues with the onboard IDE - can you elaborate or point to me to a thread? Would the ZIDEFS podules on eBay be more suitable, or is there otherwise one that's recommended?

[IanJeffray]

- 'I strongly suggest you don't start trying to mix and match bits of RISC OS 5 in to 4.39.' Yes - this was a reference to installing !System from https://www.riscosopen.org/content/downloads/common, but it sounds like you don't recommend it

I definitely don't. Others do. YMMV. It won't [AFAIK] do what you're talking about anyway (fix ADFS).

Otherwise, I was unaware of issues with the onboard IDE - can you elaborate or point to me to a thread? Would the ZIDEFS podules on eBay be more suitable, or is there otherwise one that's recommended?

ADFS for IDE is poop, really. Slow, and sucks for compatibility. And the problem with softloading a newer ADFS that is a bit more compatible becomes a bit of a Catch-22 situation as you may imagine (where do you load the ADFS module from...). The general advice I'd give though, based on my own painful experiences with this, is stick to 8GB or smaller CF - I've had reasonable success with Cloudisk branded cards (and have had 16GB cards get corrupted shockingly easily).

Yes, a ZIDEFS podule is a basic decent 16bit IDE interface - IanS here on *. occasionally has them at much more reasonable prices (screamingly cheap, IMO!) though
I'm not sure anyone's done any proper performance tests between different solutions, but there are faster options such as the Yellowstone RapIDE - though none in production now AFAIK.

[IanS]

Yes, a ZIDEFS podule is a basic decent 16bit IDE interface - IanS here on *. occasionally has them at much more reasonable prices (screamingly cheap, IMO!) though

Bit more than occasionally - viewtopic.php?p=233356#p233356

(I use a DOM in my RPC

)

[IanJeffray]

Yes, a ZIDEFS podule is a basic decent 16bit IDE interface - IanS here on *. occasionally has them at much more reasonable prices (screamingly cheap, IMO!) though

Bit more than occasionally - viewtopic.php?p=233356#p233356

Ah, sorry. Cool.

(I use a DOM in my RPC
IMG20220809214117.jpg )

Ah that's interesting - very nice - I've never seen a nice little adapter like that. Reliable, I guess? I did get hold of a few 4GB DOMs - nominally for use if we ever hack Wizzo to allow 8 partitions - but never tried one in a RiscPC like that. What I -did- try a lot, and ultimately gave up in a huff, were SATA DOMs (readily available in 16GB at sane prices) but I found no SATA to IDE adapter that ADFS liked.

[IanS]

Ah that's interesting - very nice - I've never seen a nice little adapter like that. Reliable, I guess?

The adapter was made in kicad to make use of 44-pin DOM's on an earlier revision of the IDE podule - viewtopic.php?p=225989#p225989

As it's only using a 40-pin header to plug into the motherboard which are narrower than an IDC connector, it's easy to get it offest by a pin when inserted in the socket.

[sirbod]

To clarify/expand on some of what Ian Jeffray has said.

Firstly it's perfectly acceptable to update !Boot using the latest version from ROOL. In fact, the more people that do it - the better chance we have of finding and reporting issues to ROOL.

There's pros and cons though. The pro is that you get the latest versions of many core OS Modules and any additional features/patches that have been backported to 26bit RISC OS. The con is that you're using Modules that are being actively developed, so new bugs can creep in - I've reported several this month for example. The other main con is that you will need to use the RO5 HardDisc4 ZIP as your base HD contents, then copy back anything need from your old HD from !Boot (Choices for example) as not every update has made its way into !SysMerge (aka System Resources / PlingSystem).

There's two stances here. If you're a strict "retro" person, then you won't want to use anything beyond RO3.71/4.39 and probably don't want to be using the latest patches from ROOL - stick to the original official OS and official patches subsequently released. The other stance is to keep your system up-to-date with the latest from ROOL and run the risk of things breaking.

I personally use both stances, for all my main test systems I keep them up-to-date from ROOL and report back any issues. I keep a few systems as stock "Acorn" purely for comparison. My RiscPC are multi-boot via Softload so I can switch to any specific OS version from 3.70 up for testing, with RO3.71 being my default OS as it was the last official Acorn OS released.

Using the latest HardDisc4 from ROOL will patch ADFS - that patch was rolled in within weeks of me reporting the root cause of the HD issues. Be aware however that patching ADFS might not work, depending on what is broken.

The ADFS patch does two things, it reduces the size of DMA transfers to IDE and increases the response timeout. The DMA issue can lead to "Broken Directory" errors and only affects writes - this can be patched whilst the OS is loading. The response timeout however must be patched before ADFS attempts to read data. You'll immediately know if a CF is affected by the timeout issue as it simply won't boot and might struggle to read it.

If your CF can be read by "stock" ADFS - you can in-line patch during boot. If it can't be read, you'll need to inject the patched ADFS into the OS via another method such as via a NIC Podule or worst case resort to an external IDE. Be aware however that some external IDE also suffer the same issues as ADFS - it all depends on what version of ATA they're written for. Anything based on ATA-1 will more than likely suffer the same problems as ADFS if it's strictly following the ATA-1 spec.

At some point, I'll update the Sticky post in the Hardware forum and detail which cards are safe. The community haven't feed that information back to me yet, so its a bit hit and miss unless you're a seasoned veteran or ask on the forum.

With regard to the NIC issue Ian mentioned, your mileage will vary. I've only had it become an issue with two IDE devices attached and even then its only certain devices. Two old IDE HD for example won't exhibit the issue, but an old IDE and a modern CF probably will. It can be resolved with a hardware fix as detailed this post from IanB. Essentially ATA-1 needs the "Ready" controlled, which was changed later in the ATA specs, so not all IDE devices control it as ATA-1 spec'd IDE controllers expect. Unfortunately on a RiscPC the Ready line is shared between IDE and the NIC, so when you get the issue the NIC will stop working.

[IanJeffray]

If your CF can be read by "stock" ADFS - you can in-line patch during boot.

I do this on a few machines, but it has the very annoying side-effect of significantly increasing boot time as the drive map has to be read twice. With a decent size CF, that takes quite a number of seconds -- then if you're softloading Select over 4.0 (because nobody's come up with a solution for Adjust in ROM any more) that doubles the time yet again - FOUR complete reads of the drive map happen, causing the boot to take a really painful amount of time.

IDE podule FTW.