Partition Manager

I’m contemplating writing a Partition Manager for RISCOS and would like to see what features people require.

Features

• A Configure app that can be put in ROM for RO5, or manually loaded pre RO5
• Written in BASIC
• WIMP based
• Support RISCOS 3.x onward, with no external dependencies
• Support MBR, GPT partition tables
• Support full disc partitioned drives without an MBR partition table
• Support partitioning of SCSIFS, SDFS, IDEFS, ADFS hosted drives
• Format/Initialisation of partitions as FileCore or FAT32
• Creation of the Primary FAT32 partition for Pi’s
• Support mapping DOS partitions to DOSDisc files in a FileCore filesystem
• Initialisation of the Pi FAT32 partition with the latest and/or last stable Pi firmware/RISCOS ROM
• FileCore partition expansion
• Support FileCore old and new maps
• Allow partitions to be reordered
• Backup/Restore partition table
• Support unpartitioned FileCore based drives (RISCOS 3.x)
• Option to Initialise a Pi FileCore partition with the current HardDisk4 image

Goals

• Provide a visual representation of disks, partitions and volumes under CDFS, SCSIFS, SDFS, IDEFS, ADFS
• Provide a simple interface to create and initialise/format partitions
• Allow the FileCore partition on the stock Pi image to be easily extended to fill the disk
• Replace HForm on RISCOS 3.x onward

In Scope

• RISCOS 3.x, RISCOS 5.x
• ADFS, IDEFS, SCSIFS, SDFS hosted drives
• Support for IDE Podules on legacy hardware
• Support for Winchester drives on legacy hardware (experimental)

Out of Scope

• Adding support for partitions to the OS
• Support for bespoke SCSI Podules
• MBR Extended partitions

Mock-up

Current Build

Available on the JASPP forum – Partition Manager

Feedback / Beta Build

Can be found here

Jon, not sure its any help but the ARMX6 already has a Partition Manager, no idea how good it is or if it would work on other machines, might be worth chatting with Andrew Rawnley. I know its unplugged by default on ARMX6

It might be worth talking to Andrew @ RComp as their ROMs contain PartMan – a partition manager. I’ve not had a need to use it at the moment, so I can’t comment on it.

Maybe add xFAT support to the list?

Support partitioning of SCSIFS, SDFS, IDEFS, ADFS hosted drives.

Would this not require also corresponding support in the FS?

One of the features I liked about the Morley SCSIFS (in my A5000 days) and Simtec IDEFS (in my RiscPC days) was that I could partition a drive into multiple partitions. This meant that I could use all of the space of a 1GB SCSI drive on RISC OS 3.10 by having it as two partitions, and I could avoid silly LFAU wastage on RISC OS 3.70 by breaking a 3.7GB drive into eight (!) partitions.

Another few nifty features of Simtec’s IDEFS (which might be an idea for the partition manager but would also need support in the FS) were:

• Ability to specify a drive as not to be automatically mounted. This was useful either for drives with more than eight partitions, or for people who didn’t like a cluttered icon bar. The drives could be mounted/dismounted from the filer’s iconbar icon.
• Ability to specify a drive as “locked”, inaccessible until a password is entered.
• Thinking of the GDPR, perhaps an extra level of locking where a partition is encypted in some manner?

Also, perhaps:

• Ability to rearrange the partition table (obviously without moving the actual partitions). Some devices only look at the first partition they find.
• Will this be old format (MBR) or new format (GPT) partition table?
• Ability to alter partition sizes (where useful) and merge two partitions to be one larger.
• Ability to save/load partition tables and boot blocks (for backup).

Sorry Chris – I hadn’t seen yours while I was checking the ARMX6 modules to get the module name…

I’m also assuming a new HForm may be required?

Linux EXT2/3/4 partitions?

I would prefer if it were written in C for portability, but in any case the the partition format needs to be extremely well documented so I can add support in DiscKnight.

That sounds comprehensive, but are you aware of this bounty that’s underway?

An entirely new HForm is planned, with new interafces, amongst other things, so can I suggest contacting info@riscosopen.org to see if co-ordination is possible?

I used to like the partition manager I had on my A4 and A410 way back in the dim and distant past.
Watford Electronics DFS, I think.

I would prefer if it were written in C for portability

What’s non-portable about BBC BASIC?
It’s probably more portable from RO version to RO version than C.

Number of BASIC programmes with ARMv7+ problems vs. number of C programmes.

It’s open source, so C is not a problem. Just need to recompile the software.
On the other hand, portability of Basic… Yep, but not always (compiled, crunched, etc.).

It’s open source, so C is not a problem. Just need to recompile the software.

There’s your problem – how often do we read postings describing difficulties with libraries, make files etc.
Yes C skills are more portable than assembler skills but BBC BASIC – there are programmes around that worked on the early Archimedes that also work on the latest Pi and ARMBook.

The only defence you can bring is to reference compiled code?
I’m not convinced crunched code is that limiting in portability, maintenance yes definitely.

Portability as in I do most of my development not on RISC OS (for all the reasons previously discussed), including DiscKnight which is written in C. It would be very useful to be able to create RISC OS partitions in image files on Linux and then run DiscKnight on them. If its written in BASIC, I either have to port it to Linux first, or use real discs on RISC OS which are slower and less flexible.

Thanks for your suggestion that I’ll need to rewrite the image filing system to overcome the 2GB limit before I can start, I’ll take it under advisement.

The PartMan module in git is associated with SCSIFS.

https://gitlab.riscosopen.org/RiscOS/Sources/FileSys/SCSIFS/PartMan

Built it and on the Titanium, removing all SCSI drives and inserting an empty SCSI formatted 128GB pen, proceeded as follows.

*help PartMan
==> Help on keyword PartMan
Module is: PartMan         0.16 (20 Jul 2018)

Commands provided:
ListPartitions


*gpttest 0
Formatting SCSI ID 0 with 2 partitions size 7397ffb
Completed

*listpartitions 0

Found 2 disc partitions
SCSI ID:00 Start 00000004 Size 07397ffb SCSIFSdisc 0
SCSI ID:00 Start 07397fff Size f8c68001 SCSIFSdisc 0
*

From the iconbar icon I now see this disc title, SCSI::Filecore1.$ which Free shows as 58GB. The other partition is unseen.

PartMan uses GPT (modern) parition tables not MBR. For consitancy, I suggest doing something similar. Although MBR is still understood, any modern non-RISC OS system will be using GPT by default these days.

David Pitt – I think your problem with using the partitions may be that ROOL “unpicked” one of the SCSIFS changes such that ROM builds of SCSIFS that don’t have PartMan don’t have the extended partition SWI. Unpicking this fix allowed SystemDisk to work again, I believe, although puzzlingly it works fine on my ARMX6 with (or without) PartMan and extended SWI, so I don’t really know why it was needed (or why SystemDisk couldn’t be made compatible, or a better, universal SWI parameter set agreed). Anyway, I suspect that is your problem. I think it was done in such a way that SCSIFS+PartMan ROM build = extended partition SWI, whilst SCSIFS without PartMan gives “old school” partition swi. (Someone may have a better recollection than I).

@Andrew I am at the moment using a RAM build of PartMan. My next trick should be to get it into the ROM.

For Ti (and other?) you can try Tonis stuff around partman…
Download!

ROOL “unpicked” one of the SCSIFS changes such that ROM builds of SCSIFS that don’t have PartMan don’t have the extended partition SWI. Unpicking this fix allowed SystemDisk to work again, I believe, although puzzlingly it works fine on my ARMX6 with (or without) PartMan and extended SWI, so I don’t really know why it was needed (or why SystemDisk couldn’t be made compatible, or a better, universal SWI parameter set agreed).

I thought that we’d explained this at the time, but reading the commit notes from the unpicking, the short answer seems to be that the change to SCSIFS which has been “unpicked” assigned “new significance to R2, which was previously undefined”.

That’s not a great thing to do, because anything calling a SWI will expect to not have to set up registers that aren’t defined as parameters. If R2 is defined as “not used”, then suddenly becomes a PartMan-specific parameter in an OS update, then anything which calls the SWI and is unaware of the change¹ will very likely “[fail] in various amusing ways” as the commit notes put it.

How they fail, or whether they fail at all, will depend a lot on how they were using R2 at the time of the call, and how the system is set up.

That’s why you don’t ever just decide to make an additional register significant on an already existing and documented API call. If a new call (ie. a new reason code) isn’t an option, you’re into the murky Wimp territory of passing “magic numbers” into other unused registers so that at least there’s “only” a 1 in 2 ³² chance of things happening by accident.

ETA. Oh, and it’s not SystemDisc’s problem to be fixed: the OS shouldn’t be getting changed in ways that gratuitously break existing software. From someone who actively promotes running with Alignment Exceptions off and not using High Vector ROMs, the idea that we should fix the software after breaking the OS seems inconsistent at best…

¹ Which is pretty much anything.

For Ti (and other?) you can try Tonis stuff around partman

Thanks, I can now see both partitions as separate disc icons.

I forget and I have not uploaded Tonis (Anton Reiser) Partition Tool. For bigger devices it is possible to use the space behind filecore as FAT32.
The partman stuff only works with SCSI not with SATA on Ti.

I’ll try to address most of the points above.

not sure its any help but the ARMX6 already has a Partition Manager

As far as I’m aware it’s not part of the main RISCOS build and being bespoke to ARMX6 doesn’t really approach what I’m proposing, which is all a partition manager that covers all OS versions and Filing systems.

Linux EXT2/3/4 partitions?

Obviously the partition manager will be able to view and delete Linux partitions, but I don’t intent adding support to create any partitions other than FAT32 and FileCore.

I would prefer if it were written in C for portability

C is not really that portable, as DDE is not free. That issue aside, BASIC is portable back to RO 3.x without the need for any external dependencies.

Whilst we’re on the subject on C source, I don’t suppose you would consider making the ARMalyser source available so I can extend it?

the partition format needs to be extremely well documented so I can add support in DiscKnight

MBR and GPT partitions are well documented. You probably don’t need to add support to DiscKnight for this project, but you would want to consider adding support in parallel to the partition bounty.

are you aware of this bounty that’s underway?

Yes, the bounty is to add partition support to the OS, which is a whole different beast to managing partitions.

Where this does overlap is that I intend to remove the need for HForm completely and handle formatting FAT32 and FileCore partitions within the partition manager.

Would this not require also corresponding support in the FS?

No. That’s covered by the partition bounty.

From a RISCOS perspective, the partition table is outside of the FileCore disk space so RISCOS is blissfully unaware of any partition tables.

One of the features I liked about the Morley SCSIFS (in my A5000 days) and Simtec IDEFS (in my RiscPC days) was that I could partition a drive into multiple partitions

I can’t speak for the SCSI interfaces, but I suspect the IDE interface Modules handle partitions in proprietary ways. As far as I know, they don’t use a traditional partition table and probably use onboard CMOS etc.

To add support for them, I’d need folk to donate the relevant cards to me so I can code and test support bespoke to each interface.

My guess would be that the accompanying Module that comes with the card presents a section of the drive to ADFS, such that ADFS thinks it starts at sector 0. I’m guessing they’re getting around the 512mb limit by using LBA internally.

In theory its pretty easy to put a partition shim Module in front of IDE/ADFS and use an actual partition table, this is way down the list though and not really part of the partition manager.

As for legacy SCSI interfaces, it might be worth partitioning a drive, shoving it into a modern machine and see if the partitions are visible before considering how to support them.

Ability to rearrange the partition table

Easily enough. I’m not sure if the standards allow for out of order partitions, but it shouldn’t affect RISCOS. Not a lot of use for your examples though as none of the legacy interfaces support MBR.

Will this be old format (MBR) or new format (GPT) partition table?

MBR initially, GPT can be added later. My main driver for this is to solve the 2GB Pi image limitation.

Ability to alter partition sizes (where useful) and merge two partitions to be one larger.

I’ll add extending FileCore partitions if the space after is unallocated. To merge two, you’d simply delete the second and extend the first.

Ability to save/load partition tables and boot blocks (for backup)

Saving the partition table is simply a case of saving the first sector (MBR) or first 34 sectors (GPT.) eg SYS “SDFS_DiscOp”,,1,0,&10000,512 – will read the partition table on a Pi.

PartMan uses GPT (modern) partition tables not MBR. For consistency, I suggest doing something similar.

The GPT partition table should also contain an MBR partition table for compatibility reasons, the MBR should contain one partition with the system ID &EE to indicate a GPT partition table is present.

I’ve added it to the list.

Where this does overlap is that I intend to remove the need for HForm completely and handle formatting FAT32 and FileCore partitions within the partition manager.

That is the best news I’ve heard all year, the number of problems raised on these forums is an indication of the level of the problems people have with HForm

Given that PartMan seems to have found uses well beyond the ARMX6, it is a shame that a mutually acceptable extension (akin to other RISC OS extended SWI APIs created by Acorn and ROOL) hasn’t happened. That way, we’d avoid compile-time specific changes. Since both elements are in the open source tree, I’m sure something could be agreed/designed to allow it to work in a mutually agreeable manner. This would surely benefit everyone :)

Given that PartMan seems to have found uses well beyond the ARMX6, it is a shame that a mutually acceptable extension (akin to other RISC OS extended SWI APIs created by Acorn and ROOL) hasn’t happened

I’m not sure I understand what you’re saying :|

I had a look at the PartMan source earlier, it looks okay as a CLI interface but only handles SCSIFS. I expect the reason for this is that SCSI was the only filesystem being used on the fork it was coded for, but really the underlying issue is the fact we’ve yet to abstract the filesystem in RISCOS. Having to write bespoke code to get physical device size, write/read sectors etc. as is currently the case, is quite frankly dumb.

I’m planning to split off all the filesystems into separate libraries to abstract them, so the partition manager itself doesn’t have to know which filesystem it’s handling.

I note John chose a GUID for FileCore, I’ll retain that for consistency.