Q: Which file systems does RISC OS support?
A: RISC OS supports its own FileCore file system, as well as some non native formats such as FAT (FAT12 or FAT16 or FAT32).
Q: How do I remove my disc safely?
A: Click MENU (middle mouse button) on the drive icon and select ‘Dismount’, it is now safe to remove the disc.
If the drive was using the FAT32FS module you may notice that its name changes from ‘FAT32_0’ to ‘:0’ also.
Q: How can I format my disc so that RISC OS is able to read it?
A: RISC OS currently only formats drives with its own FileCore format using the HForm utility. If you plan on exchanging data with other systems you should go for FAT32 on Windows/Linux/MacOS.
Q: I have a spare USB hard disc. How do I use this?
A: Plug the drive into a spare USB port, it will be handled by SCSIFS as a mass storage device.
Q: What are the size limitations of the FileCore format?
A: FileCore supports up to 2 29 sectors, a sector is most commonly 512 bytes, giving 256GB as the upper limit.
Note that the controller used on the Iyonix motherboard can only use fast UDMA access to the first 128GB of the drive, the upper 128GB will use slower PIO accesses.
FileCore 3.61 and later allow for the maximum size of any individual file to be 0xFFFFFFFF bytes (4GB minus 1), earlier versions were limited to 0×7FFFFFFF bytes (2GB minus 1).
FileCore 3.63 and later support sector sizes of 2kB and 4kB within the same 2 29 sector limit as before. Therefore the maximum drive size it supports is 2TB, though this does require the underlying filing system to talk to 4kB supporting hardware.
Q: How can I enlarge the RISC OS Pi SD card image to use the full SD card?
A: SystemDisc is part of the DiscTools suite, and is a general-purpose tool for managing the system software on modern RISC OS systems. SystemDisc allows you, easily and quickly, to initialise new SD cards for booting your RISC OS system, entirely from within RISC OS. It creates a two-partition SD card which can use all of the available space on your SD card. See this forum thread for a solution that adds a third FAT32FS partition on the original 2G SD card image where there is still free space on the SD card.
Q: Can I have an icon on my iconbar for my Fat32 filesystem?
A: Use ‘AddTinyDir’ to add an icon to your iconbar. Something like this should do the trick:
FAT32FS:mount -p2 :16 { > null: }
AddTinyDir FAT32FS::fat32_16.$
Assuming that your FAT32FS module is loaded in predesk (which is the default place to put it) you can pop the above commands in an obey file and either run it manually, or add it to the boot sequence to add the folder to your iconbar.
Q: Can I have a temporary RAM file system?
A: Yes, RISC OS provides RAMFS, which can be controlled from the !Configure utility.
Alternatively, the 3rd party add on !Memphis is a RAM based file system that auto-sizes to provide a cache for commonly used files. An option is available to automatically cache the !Scrap directories, which can lead to an improvement in performance for applications like !NetSurf which make a lot of use of this area.
Q: The Risc PC stores configuration settings in battery backed CMOS RAM much like a PC BIOS does, how is this done on the newer platforms?
A: When RISC OS first starts up the hardware abstraction layer (HAL) attempts to detect the presence of a hardware CMOS widget . This addon fulfils the same function as the chip in a Risc PC, but doesn’t need a battery backup.
If the CMOS widget is not found then a region of memory above the ROM is examined to see if a properly checksum’d CMOS settings file has been loaded there by a ‘fatload cmos’ command in the script run by the OS loader.
The USB system is fired up in a minimalist way so that the keyboard can be recognised. If the delete KEY is held down then the factory default settings for the CMOS are established.
If no key is pressed then the settings loaded (from a CMOS widget or via ‘fatload cmos’ command) are used.
The rest of the ROM modules are then started, which on systems with SD card interfaces may include the module ‘SDCMOS’. This module emulates the CMOS memory by saving it to a file on the SD card, but as it is not loaded until after the rest of the system has started cannot be used for some of the more advanced uses (like unplugging modules that conflict).
Note: Versions of SDCMOS prior to 0.10 suffered from duplicating the functionality of the fitted hardware, leading to performance issues and multiple inconsistent copies of settings being saved.
Q: The Risc PC keeps time via a battery backed clock chip, how is this done on the newer platforms?
A: The Iyonix and BeagleBoard include a clock chip too, though the BeagleBoard may require a battery fitting as the circuit board is usually sold without.
The PandaBoard and Raspberry Pi can optionally fit an RTC plugin module, purchased separately. The time can be manually adjusted using the ‘Time and date’ configuration plugin, or set to collect the time from a network time server. The network time server will be called during the boot sequence, so if no network connection is present the time will be wrong.
The Raspberry Pi will also use a timestamp (held in the “RISCOS.IMG” ROM) updated each time the computer is successfully shut down, to try to restart a software clock – though of course this will be appear to be ‘frozen’ when the power is removed.