Reading RO USB sticks from Win/Linux

Is it possible to read USB sticks direct – that are in RO format – on a Win/Winux computer.

ie for reading off data for VRPC/ro5.25 – RiscOSM.

Thanks

“Direct” as in “a Filecore implementation for Windows that works like a native filing system”? Not that I know of. For Linux, there is David Boddie’s Python FUSE “ADFS” implementation: https://bitbucket.org/dboddie/adfslib and https://bitbucket.org/dboddie/fuse-adfs

Not sure if that works for “big” discs or only for floppies.

Personally, I am working (from time to time) on a tool (mainly to get to know Filecore a bit better – know your enemy!) implemented in Java that understands E/E+/F format disc images (both floppy and harddisc) to avoid having to configure and start an emulator to find out what is stored in there. To read directly from a real hardware device, I guess it would need some interesting JNI lib doing SPTI…

Oh there is so much fun trying to fake unsigned types in Java.

You can mount a RISC OS format stick on a Linux machine quite easily if you are familiar with the “mount” command. You might need to use the “-t” option to specify the format as “adfs”.

For example, I stuck one of our RiscOSM USB sticks into a Linux laptop and did

ls /dev/sd*

This listed the following devices:

/dev/sda
/dev/sda1
/dev/sda2
/dev/sda5
/dev/sda6
/dev/sdb
/dev/sdb1

This told me that the stick was the device at /dev/sdb as with no sticks plugged in only the /dev/sda… ones are listed (the hard drive in the laptop).

Then as the user root I did

mount -t adfs /dev/sdb /mnt

Where /mnt is just a mount point already created in the root directory. After that I could do

ls /mnt

and the contents of the RISC OS format stick could be seen. To unmount the stick after use

umount /mnt

Note that the “umount” command really is called that and not “unmount”.

The “normal” way to read ADFS filing systems with the mount command as Matthew suggests, though traditionally ADFS support didn’t seem to get included in kernels or supplied as a kernel module in many distributions.

My ADFSlib and FUSE implementation is only for floppy disks and isn’t 100% reliable, though it hopefully does a reasonable job with most disks. I looked at the code fairly recently because I wanted to translate it into another language.

It’s interesting to read Steffen’s complaint about unsigned types in Java. I recently watched a video from the early days of Go (golang) – or perhaps I read slides from a presentation – that cited the lack of unsigned primitive types in Java as a cause of trouble in getting a Java git implementation to work efficiently.

The mount command to get ,xxx filetypes is:

mount -t adfs -o ftsuffix=1 /dev/sdb /mnt

This is read-only. The write support is unfinished, so it’s disabled.

You may need to

sudo modprobe adfs

if ADFS isn’t available by default.

The ,xxx filetypes option could be very useful. Thanks, Theo, I wasn’t aware of that. If you make the mount point to be somewhere inside RPCEmu’s HostFS directory then the emulator might be able to read and copy the files directly without loss of filetypes.

That should work. But I think you can also symlink /dev/sdX to RPCEmu’s hd4.hdf and have RPCEmu use the raw block device. The advantage is it uses the native RISC OS Filecore (with read and write support) rather than the read-only Linux implementation.

Personally, I am working (from time to time) on a tool (mainly to get to know Filecore a bit better – know your enemy!) implemented in Java that understands E/E+/F format disc images (both floppy and harddisc)

…and it now seems to be good enough to parse any E/E+/F format image I threw at it. I guess there is no collection of “edge case” images around?

Does anyone have a few D format images (floppy and harddisc)?

Does anyone have a few D format images (floppy and harddisc)?

If you don’t have a RiscPC or similar handy, I could format a floppy to D format and send you the image, is that what you’re looking for?

If you don’t have a RiscPC or similar handy, I could format a floppy to D format and send you the image, is that what you’re looking for?

Thanks for the offer Andrew – I can easily create “synthetic” images via one of the emulators (I hope!), I was more interested in “real world data” if someone happens to have them. Especially D format harddrive images. No need to specially produce one for me!

I wonder if one of the early games ADFs are actually D format? Or possibly the Arthur welcome disc – when was E format introduced? Arthur or RISC OS 2?

when was E format introduced?

Arthur supported L and D format (did it also do S and M?).
RISC OS 2 introduced E format.
RISC OS 3 brought in F format.

Font Directory Pro internally uses D format to hold its font partition, so analysing the !FontFS.Data.Fonts file from any existing install will give you megabytes of test material.

I didn’t encounter many floppy discs in D format from the 32-bit era. I think the disc accompanying the Dabs Press book Archimedes Assembly Language is L format. The original A3000 application and support discs appear to be D format.

If you send me an e-mail, I’ll try to set you up with some floppy disc images that might be useful. It’s also worth asking on stardot because some people there are using ADFS with hard drives on systems that pre-date E format, so there may be D format images available to try.

Hi,

I previously wrote in this thread…

Personally, I am working (from time to time) on a tool (mainly to get to know Filecore a bit better – know your enemy!) implemented in Java that understands E/E+/F format disc images (both floppy and harddisc) to avoid having to configure and start an emulator to find out what is stored in there.

and now…it is nearing completion (as in: first viable version with a sensible feature set, as software is obviously never really “complete”). So I am looking for testers.

Limitations include non-handling of files with load/exec address, the absence of proper error handling, the fact that the whole image must be loaded into memory (so you need a lot of main memory and patience for those multi-gigabyte harddisc images), lack of a meaningful progress indicator beyond a wait cursor, optimistic filename conversion and probably a lot of other things.

The tool currently has a command line interface and a (simple) graphical user interface.

If you are experienced in running Java-based software on Windows and/or Linux and/or MacOS (the tool is not yet nicely packaged up, just a runnable Jar and two start scripts, so you need to know how to integrate the Java runtime correctly into your system and it is of advantage to know usual parameters e.g. for memory parametrization of the JVM) and have some filecore images ready to check, please mail me (or reply to this post in the forum).

Please note that I have not yet decided how this tool (working name: FilecoreImageReader) will be distributed once properly finished and tested. It might end up as a commercial or shareware or donationware piece of software. So if you are unhappy to invest your time in testing a tool that might end up being non-free, please do not apply as tester.

If you just want to say “Hey, I would be interested in such a tool and a cool feature would be abc”, please do not hesitate to tell me.

Have fun
hubersn

Many Acorn User cover discs are in D format as it is more space efficient

Many Acorn User cover discs are in D format as it is more space efficient

Are you sure that it wasn’t because at the time that they were in D format, they contained 8-bit material for use by 3.5"-equipped 8-bit systems?

I think the Acorn User discs were L format, so they could be read on the Master Compact. I’m not sure what happened later on.

I think the RISC OS 2 welcome discs might be D format, and images could probably be found somewhere. Also any software for Arthur is likely to be D.

I believe S and M worked into the RISC OS 2 era, possibly as far as RISC OS 3.1, but you couldn’t format them.

Progress update: my Java application now also supports D format. There are no longer any memory limitations, so your 256 GiB image will be read just fine. Progress indicator now exists, filename conversion is better (but not optimal), better handling of filetypes (compatible with RPCemu), drag&drop support…

More features are in the pipeline – an integrated Sprites viewer and an integrated BASIC detokenizer to be able to directly inspect files with such content. And a text viewer, too. ZIP is next on the list, not sure if Spark (classic ARC format) will be easily possible. Draw files are a long way off.

I also experimented with direct device read, not much success yet.

There are three outstanding problems before I can release a first version – there is an endless loop with certain E format structures when parsing the directory entries, there is a miscalculation of certain checksums, and one of my many disc images is not correctly detected as a valid image (but reads just fine with the emulators). And there seems to be a problem recognizing certain ArchiEmu-created harddisc images. I should stop adding new features until these problems are solved…

> not sure if Spark (classic ARC format) will be easily possible.

I’ve got some Java code that will read Spark, ArcFS and PackDir archives. It should be easy to add Squash support as well. I seem to remember struggling with CFS files, but I forget why.

It will need tidying up, but I can send it to you if you are interested.

Hi James,

I’ve got some Java code that will read Spark, ArcFS and PackDir archives. It should be easy to add Squash support as well. I seem to remember struggling with CFS files, but I forget why.

Oh, I would be very interested in this (given an acceptable license for the code).

It would be really cool to get some RISC OS formats into mainstream Java libraries. Like getting Sprite support into Apache Commons Imaging and Java ImageIO, and Spark support into Apache Commons Compress.

> Oh, I would be very interested in this (given an acceptable license for the code).

OK. Give me a few days to dig it out and see which bits need some TLC, and I’ll give it to you. I’m happy for it to be licensed under any license you wish.

Hi Steffen,

I have knocked the code into a working state. How should I send it to you?

Hi James,

why not put it up on GitHub (assuming you are the mjwoodcock with the nspark project)? You can of course also email me at

steffen huber-net.de

Thanks for your work! I have done some more work yesterday to integrate the Sprite viewer, the Text viewer, the BASIC detokenizer and the generic “no understood format” HexDump viewer for us old-school people. So I am ready to have a go at Spark archives.