Android application to manipulate sd image from the site

I’m afraid you’re out of luck regards writing FileCore (ADFS) filesystems on Linux using the kernel driver.

Linux has an adfs module. Out of the box adfs will:
Read FileCore E/F format volumes (whose spec dates from 1988, 10 character filenames, 77 files per directory limit – E and F are basically the same, the difference only matters for floppies)
Read FileCore F+ volumes (spec dating from 1998, with long filenames and unlimited files/directory)
Convert the RISC OS 12-bit filetype information into ,xxx filename suffixes by mount flag ftsuffix=1 (Linux 3.0 and later)

If you compile with ADFS write support (marked ‘danger, experimental’) it will:
Write, modify, delete and create new files on E/F volumes
Replace the contents of files on F+ volumes

What the adfs module doesn’t have is code to handle the F+ free space map. So it cannot:
Create new files on an F+ volume
Enlarge or reduce files on an F+ volume
Delete files on an F+ volume
because it can’t allocate or release blocks from the free space pool.

That means it’s pretty useless for building modern disc images.

The best suggestion I have is to boot RISC OS in an emulator (like RPCEmu) and get that to build the images. However on Android you’re still going to need root to write the raw block device (/dev/sda or whatever) if you want to write to an SD card.

aaaaa

aaaaa

App icons can usually be found in ! AppName.! Sprites with some suffix on the name representing the pixel density compared to the standard 34×17 (eg 22 for 2 times = 34×34). They’re RISC OS sprite format.

The system sprites are in the ROM – look in Resources:$.Resources.Wimp on RISC OS for the file. I don’t know of an easy way to pull them out of the ROM without running RISC OS. You may be able to use them from CVS – look at Desktop and Wimp . Icons for non-system files are found inside the app that opens them (eg ! AppName.! Sprites(22) contains icons file_ab3 and small_ab3 for files with filetype 0xAB3). That means that you’d have to scan any apps you want to display files for.

SparkFS reads standard zip files – they just have extensions for RISC OS filetype information . It’s probably possible to build in a zip/SparkFS archive, however it’ll be slow because SparkFS will be constantly resizing and re-cataloguing the metadata.

aaaaa

Also would there be a way to make the pi boot loader to read directly riscos filesystem or is it hardwired to read fat32 ?

No.
The Beagle bootloader has an option where it can read from the start of the media but nobody ever uses that as it precludes the use of a filesystem – maybe it is a leftover from the earlier flash booting. As for teaching something as esoteric as a Filecore filesystem? No chance, there would be extfs and the like first. If it was possible that is.

precludes

not sure it is any different, in principle, from carefully arranging the RISC OS partition so that the FAT partition is (a) readable/writeable from RISC OS and (b) in its correct position for the bootloader. All RISC OS sees is the filecore partition.

aaaaa

I suppose raw booting is possible on a Beagle xM…

“In raw mode, an image can be at offset 0 or 128KB and must not be bigger than 128KB. Raw mode is detected by reading sector 0 and sector 256.”.

Space could be marked out in the SD image to hold the first stage bootloader (if marked as “bad blocks” then the whole thing can be hidden from the user) and this is loaded by the OMAP to initialise the board and retrieve the ROM image from the FileCore “partition”.
So, yes, on an xM (possibly Panda etc as well?) it could be done.

Don’t know about the Pi, not enough documentation.

That said, I think a better use of resources (in the long term) would be to make FileCore “partition aware” so it could coexist with other partitions on an SD card; for instance a 4GiB card could be built (thinking of the xM where the user button can select what to boot) that contains the little FAT boot partition, a 2GiB extfs partition for Linux, and a 2GiB FileCore partition for RISC OS… Something like that, at least.

aaaaa

You mean like…the bounty “Filing system improvements (step 2)”?

aaaaa

aaaaa

But the way the image is made currently is weird,

Yes. You might say it’s broken in a strange way in order to make it work.

aaaaa

But if the partition system is to be made fully compliant with how partition are supposed to be made, filecore should be made to look for disc record directly in the space of the partition pointed to from the mbr, and it would not work with the current image as the disc record is at the beginning of the disc.

Don’t worry, the existing method is a quick work around for a problem.

Actually fixing the problem with proper partition support etc is the real answer.

aaaa

Maybe a trick

… could be to have an old format (full disc) and a new one (only for RISC OS 5), compatible with other systems.

And disc who would have a riscos partition not in the beginning on the disc could not be read by a riscos version who doesn’t support the partition system.

IMHO, there is no other solution.

And it’s really not a problem. ROS 3 or ROS 4 will probably never need to read such discs. And A7000/RPC users can softload RISC OS 5 too :)

Sometimes, we just need to go ahead.

IMHO, partition is also a good time for some refactoring around ADFS format (bigger and more files, bigger partitions, adaptation of map to partitioned discs, first step of TRIM support for SSD, etc.).

aaaa

The filename is shown on screen with spaces but the separater between wimp and beginner is actually ASCII character &A0 which is how RISC OS stores a space in a file name – i.e. as a hard space. The PRM 2-12 says you should not as a general rule use top-bit-set characters in filenames although some filecore-based filing systems support them, also that filenames should be no longer than ten characters and should not use fullstop, colon, asterisk, hash, dollar, ampersand, at, uparrow (exponentiation), percent or backslash. So it’s a bit out of date!

aaaaa

aaaa

The above is correct – it’s not a valid UTF-8 string. I haven’t checked, but I’d be pretty much willing to bet that Filecore just assumes the system alphabet for filenames. If you want to display them on a system which expects UTF-8 strings, you’ll need to transcode them. You might just have to take a guess at the source encoding – it will usually be Latin1 (ISO/IEC 8859-1), but if my assumption is correct, you can’t know that for sure. For maximum flexibility, you perhaps need to give the user the option of selecting their source encoding from a list of known RISC OS encodings. (See here for example – sorry, that’s from the Others. Ah, here is a better reference for Us.)

Yeah, FileCore doesn’t do any character translation, so whatever is on disc is interpreted using the system alphabet.

RISC OS (or at least FileCore?) doesn’t support spaces in filenames, so non-breaking spaces (char 0xa0) are generally used instead (and I think there are various points at which the OS/apps will automatically convert spaces to non-breaking spaces). Worth bearing in mind if you’re planning on doing any kind of filename manipulation (renaming, searching, etc.)

The string is ISO 8859/1 (usually), not any form of Unicode. You will either need to handle strings yourself or convert it on the fly.

It’ll be more fun if/when RISC OS supports UTF-8; then who knows what will be what. ;-)