Partition Support

Could we have a bounty for this please?

(Or even for a new partitioning/formatting tool for creating ADFS partitions with a normal MSDOS partition table, such that the first partition would work with current systems, this should allow new machines to dual boot with non RO systems, or allow a large USB drive to be split for use with other systems.)

A new formatting and partitioning tool would be pretty simple to do, if you were happy with a scheme whereby the FileCore partition was always at the start of the disc and was not included in the partition table. That is, the partition table would describe a partition or partitions starting part way through the disc and the preceding space would be devoted to FileCore. I have done this myself manually when setting up a BeagleBoard to dual boot to RISC OS and Ubuntu. The FileCore partition would be readable on any RISC OS machine, but the other partitions would not be. Similarly the FileCore partition is assumed to be unallocated space when the drive is mounted in Linux. I have not tested whether Windows and the like are happy with this kind of arrangement.

Stipulating that the tool would be able to format the foreign partitions as well as allocate them would make the task harder, of course, though FAT16/32 partitions are quite easy to create. I don’t have experience of others.

This might be judged to be a bit of a bodge, though, as “proper” partition support would have some part of RISC OS understanding the partition table, and the FileCore partition(s) being a real partition. In the bodge I am using, the FileCore disc starts at the very start of the disc as normal. It just relies on the fact that the location where the partition table is expected by MSDOS happens to be unused by FileCore.

The bodge would be quick and easy to do, but would slightly complicate the proper partition support if that were written later.

Any opinions?

IMO the bodge approach is too trivial to justify a bounty. What we really want is a proper solution. I’d suggest that partition support is developed in several phases:

Phase 1 would be creating a “partition manager” module that’s designed to sit between the hardware drivers and the filing system modules. It would support creating and manipulating partition tables, but not contain any code for manipulating the actual contents of the partitions (i.e. it would be able to create a partition table entry for a new partition, but it would rely on an external filing system module to format the partition). Phase 1 would also involve creating a simple testbed where the partition manager talks to a fake hardware driver that just stores the data in block of memory, or perhaps as a regular file on disc.

Phase 2 would involve integrating FileCore support. The ideal way to do this would be to modify FileCore so that it can act as a client of the partition manager, but that might be tricky due to the fact that FileCore will need to maintain its legacy interface. So instead it might make sense to take the route of creating a module that can act as a middle man between the two systems – from FileCore’s perspective the module will be a regular FileCore client, but instead of being a traditional hardware driver it would instead talk to the partition manager. The module would automatically create new instances of itself whenever new FileCore partitions are discovered by the partition manager, thus working around FileCore’s floppy/HD limits.

Phase 3 would involve modifying one of the existing FileCore clients (e.g. ADFS, SCSIFS) to interface with the partition manager instead of FileCore. This would then satisfy the basic requirement of the bounty – the ability to use partitioned IDE/USB drives with FileCore & RISC OS.

Additional phases would involve modifying other filing systems (e.g. DOSFS), developing user-friendly partition manager tools for users to use, etc. But to keep things simple, these probably don’t need to form part of the initial bounty.

Can I direct you guys to this topic?

if you were happy with a scheme whereby the FileCore partition was always at the start of the disc and was not included in the partition table. That is, the partition table would describe a partition or partitions starting part way through the disc and the preceding space would be devoted to FileCore.

I think it would be essential to support a hybrid legacy scheme like that. However I was thinking that the “legacy” area should be marked in the partition table.

If the MSDOS partition table is actually situated in the FileCore area, should it be protected somehow? (i.e. if you filled the partition, would it overwrite it?)

What I was thinking of the first step, would be a new hform that has new predefined sizes (500MB and 2GB old format and 128GB and 256GB new format) plus manual choice. It would create a partition table with an entry for the FileCore partition (there are plenty of unused description numbers)

This would produce a drive that could easily be subsequently further partitioned on other OSes (or with a future RISC OS partitioner).

This would be a useful step forward, and I would think be a prerequisite for Jeffrey’s plan. (Phase 0?)

I think Jeffrey has the right kind of idea on the structure. A partition needs presenting as a logical disc to the user and existing file system interfaces (much as it is in Windows), and then data is directed to the correct place on the disc through a driver of some kind.

Although RISC OS (from the other thread) only supports 8 discs per file system, most discs only have a few partitions so it’s not a deal issue for now. The 64bit changes are rather more important for using large discs. 64bit Image file system support for large FAT32 (and proposed TBAFS64) discs could then make use of all the available space.

Jeffrey previously indicated that a re-write of Filecore into C might be prudent. With the hassle of trying to add 64bit code in Assembler (particularly when all the registers are used) I tend to agree this might be the only realistic way forward.

Although my time is currently focused on TAG 3D and BASIC, I might be interested in assisting with this later in the year.

the hassle of trying to add 64bit code in Assembler (particularly when all the registers are used)

Simon Proven (author of the Ursula extensions to FileCore) had a good suggestion for the problem of register allocation when disc addresses are enlarged – simply to pass around pointers to the new 3-word disc address blocks instead. So you’d only need to spill registers when doing manipulation on the values, which is relatively rarely. So I don’t think that’s as much of an issue as you might assume.

I wasn’t disagreeing with Jeffrey’s main approach.

However what he refers to as a bodge, would be an important stepping stone. And it would be part of a final solution for RISC OS 5 on a RISC PC.

e.g. 2GB Old Filecore partition plus big New filecore partition
(The old partition would be all RO 3.7 could see and would be needed to soft load from, and also would be useful to allow the original system to be used.)