Partition Manager

I have removed the link,

You could just drop the licence file in the zip that you gave the link for. There’s absolutely no issue with limitations because it says you can do anything with the code, as long as you include the licence.

My comment was intended to help you avoid any unpleasantness, that sometimes happens on these things. Plus, if you fed back the change info to Christoph he would probably include that in the code he maintains.

It is a straight forward job in GCC should you want to build it yourself.

However, for those not familiar with compiling software and the alterations required to allow ADFS?
I get by on such things, but some users run in horror at doing anything beyond simply using software.

I started coding this up yesterday and it’s become immediately apparent that filesystems under RISCOS are a mess. There’s literally no consistency for basic things like getting the drive count, disk size, volume label or free space.

I’ve also noticed discrepancies between some documentation and reality, which I can’t explain. CDFS_DescribeDisc doesn’t match at all and SCSI_Initialise 2 the “size” field is different.

I documented CDFS_DescribeDisc, so I’m not sure what’s going on there! I’m going to assume it’s a bug in CDFaker, which I maintain, until I can test on physical.

SCSI_Initialise 2, the documentation shows the size being returned as a logical block count, but I’m seeing it being returned as bytes for the USB stick I’ve tested under RO5.29. Is there a reason for this discrepancy?

Also, the SCSI PDF linked above shows the extended length in byte 4 only, has this been extended to the word at byte 4?

Filecore’s limit is 8 devices/partitions per filing system.

(4*4 = 16) > 8

The drive is held in a 3-bit field.

It’s a pity that both the MBR and GUID partition table schemes are uncomfortable fits for RISC OS. The MBR scheme only works for drive sizes that have already been exceeded in readily available drives. The GUID scheme requires that the first 16 kiB (maybe a little more, I forget) are occupied by the partition information, so the usual boot record at byte address &C00 is occupied by the GUID table, so a GUID-partitioned drive has to be used in a GUID-aware computer.

But we have to move on, so something has to give.

so a GUID-partitioned drive has to be used in a GUID-aware computer.

That’s not such a big thing. After all, you can’t use a GB sized drive (or larger) with RISC OS 3.10, and the long names format doesn’t work with legacy Acorn versions… And just recently there was the question of HForm making a disc an older version of RISC OS 5 couldn’t read.
And so a GUID drive, just another evolution. So long as the machine can still read legacy formats, then at least one can connect older drives to newer systems.

The drive is held in a 3-bit field.

Which gives you 8 drives 0 to 7.
And from FileCore_Create means you can potentially have up to 8 floppies and 8 hard discs. FileCore_DiscOp64 however uses bits 0-7 for the drive number which would allow up to 256 drives. This replaces the 26bit version FileCore_DiscOp which uses 3 bits for the drive number.

The physical limit on MBR is 2TB.

As pointed out, GPT support requires FileCore to work within the partition limits, not the drive. The simplest way to implement that is to not touch FileCore, but virtualise the drive and have the file system translate the DiscOp’s etc to the physical partitions.

We’ve yet to see any proposal from the bounty, so it’s not clear how its going to be implemented.

I made some good progress with reading MBR yesterday and have the RO5 SCSIFS, SDFS and a basic CDFS handlers coded. I’ve got to go back and tweak for RO3.11 support, but hope to have something to at least show partitions under RO5 soon.

It’s modular using BASIC LIBRARY’s, which are scanned and imported during loading, so it can be easily extended without touching the existing code. There’s a library for each FileSystem and partition type, which simplifies the codebase.

I’ve hit a few issues I need to solve around FAT support, namely:

• How to get the free space
• How to the get volume name
• How to find the mapping to a FileCore file. This ideally needs storing on the disc somewhere
• How to dynamically mount a DOS partition

The last issue might solve the first two, if I can open the partition via the existing image file system.

SCSI_Initialise 2, the documentation shows the size being returned as a logical block count, but I’m seeing it being returned as bytes for the USB stick I’ve tested under RO5.29. Is there a reason for this discrepancy?

Testing GPT with an SSD today, SCSI_Initialise 2 is returning a size of 2*physical.

Is there a bug in SCSIFS, is the PDF linked earlier incorrect, or am I using SCSI_Initialise incorrectly? If I run the following on a 160GB SSD, it comes back with &4712A19EAF, which is 305,255,259,823 or 240GB.

SYS "SCSI_Initialise",2,0,&10000
PRINT ~?&10004;!&10008

On a 256GB USB stick, it comes back with the correct size in bytes. The documentation confuses me as it states:

highest logical block number (converted to normal)

What does “converted to normal” mean?

EDIT: Ignore all of the above, I can see I’ve misunderstood the documentation. It was just coincidence that the two drives I tested returned correct results and the other returned 2* the expected result.

PRINT ~?&10004;!&10008

Shouldn’t that be !&10008 (for the highest valid block number) and !&1000C (for the block size)?

What does “converted to normal” mean?

Little-endian (SCSI command blocks use big-endian).

What does “converted to normal” mean?

Hmmm. Unfortunate choice of words when you’ve got applied mathematicians lurking around… :D

The thing is if they’d written “converted to normal endianness” there would then ensue a debate about which endianness was normal.
Then you sit the Unix guys at one side and the Windows guys at the other and grab beer & popcorn.

Now I’d have written “converted so sensible endianness” and (having lit the blue touchpaper) retired to a safe distance.

Jon: I don’t know if this helps, but I’ve tried the SCSI_Initialise 2 command on a couple of devices: the main 120GB SSD, and an ancient 4GB USB stick. In both cases, the word at +8 (when taken as LS in +8 to MS at +11) gives a plausible value for the highest block number, and the byte at +4 is &1F (again, in each case). So I can’t see that +4 is returning what the old document states. If it were returning the MS byte of a 5 byte value, it ought to be 0 for my drives.

The word at +12 has a value of 512, as expected.

SCSIFS 1.36 (19 Aug 2020) on a Pi 3B+.

Jon: I don’t know if this helps

30 mins after my post I figured out my error and added an edit to the message. As Clive mentioned, the word “normal” threw me as I was trying to work out how you normalise a disk size! Personally, I would have added a comment below to say that although SCSI is big-endian, the values in the block are little-endian. Unless you knew SCSI was big-endian prior to reading it, its pointless information and only adds confusion.

I’ve added reading GUID partition tables today. I’ve not added every GUID type, just the main ones we’re likely to encounter on discs being moved between Linux/Windows/RO, we’re only really concerned about the partitions that RISCOS can read anyhow.

I need to add full FileCore drive support and then it should at least display volume info for SCSI, SDFS, CDFS with MBR, GPT and FileCore partitioning under RO5. Should hopefully have something to put out for testing tomorrow.

Once that’s done, I need to make sure it’s RO3.11 safe, add partitioning, initialising and ADFS/IDEFS support. I’m not sure formatting is actually required as I think it’s only Winchester drives that need MFM tracks laid down. I honestly can’t remember the last time I had to format a drive, other than for security purposes.

I’ve put PartMgr v0.14 on the JASPP forum, if people would like to try it on their machines and report back any issues.

It’s read-only, so no risk of damaging anything yet. No ADFS support yet, so newer machines only at this point in time.

Thank you for the Download. I get an error on trying to run the application, “Logarithm range at 331” (Pi4, RO 5.29, 09-Jan-21)

“Logarithm range at 331”

You have a drive that’s LBA count fills 32 bits, I thought I’d gone back and checked I’d handled negative INTs correctly but obviously missed that one. I’ve uploaded a modified ZIP that corrects the LOG error, but suspect we might get more errors.

On the Titanium PartMgr shows SCSI and SDFS drives as “Unallocated”. A SCSI pen partitioned with the ROOL PartMan gtptest tool as described here shows as unknown &EE.

On the RPi4B the 120GB SCSI SSD shows as unallocated and the 2GB unpartitioned, Pi firmware and ROM only, SD card shows as unknown FAT.

A USB 500GB HD connected to the RPi4 showed two partitions, one as 466GB FAT and the other as 2MB unallocated. GParted on Raspberry Pi OS confirms that.

Thanks for this very interesting development.

Thank you for this SW. Testing with an SD card (32GB) imaged with NOOBS and containing an RO disk and a Raspberry PI OS disk, it shows one partition of 63 MB and an extended partition of 28.82 GB. RO sees the card as 3718 Mbytes. The rest of the card is occupied with an ext4 partition for RPi OS.
I have also an SSD (120 GB)that was initially formatted ext4 and successively resized/moved to about 73 GB leaving 37 Gbytes that I formatted with HForm. So I have a (partition?Disk?) for RO of 37GB and one 73GB ext4 for RPi OS. Your software shows this disk as one partition of about 73 GB Linux. RO part is ignored.

Thanks for the revised version.
My computer has a 2Gb SD card (ADFS/FAT32), USB pen drive (58Gb ADFS) and a 2TB SSD (1.81TB EXT4/FAT32 265 MB)

Volume Layout Format Capacity Free
(SCSI::4.$.?) DOS FAT 265 MB -
(SDFS::0.$.?) DOS FAT 48 MB -
RISCOSpi (SDFS::0) E, New map, Boo FileCore 1.78 GB 1.51 GB

Very promising :)

A SCSI pen partitioned with the ROOL PartMan gtptest tool as described here shows as unknown &EE

Try v0.15, I’ve corrected an issue with the protective MBR check.

On the RPi4B the 120GB SCSI SSD shows as unallocated and the 2GB unpartitioned

Does the 120GB contain a partition table or is it fully FileCore?

and an extended partition of 28.82 GB

I’ve yet to implement extended partitions.

I have a (partition?Disk?) for RO of 37GB and one 73GB ext4 for RPi OS. Your software shows this disk as one partition of about 73 GB Linux. RO part is ignored.

It will only pick up on the RO part if it has a valid MBR partition entry. It sounds like its embedded within the Linux partition and does not have a matching MBR entry.

Very promising

It sounds like I have some oddities to deal with from the reports so far. I’ll add some code to dump the partition tables to text file, so I can better understand the discrepancies.

The scores on the doors!

Titanium:
Nothing for ADFS, as expected.
It has a linux SD card in, which shows up as:
SDFS::0
MBR
7.44GB – 7.33GB Linux; 2MB unallocated

Dual Boot Pi 4 booting Linux from SSD and RISC OS from SD:
SCSI::4
MBR
117.9GB – 56.11GB FAT (unknown); 55.67GB Linux (this is correct – that’s how it is partitioned)

SDFS::0
MBR
28.85GB – FAT 50MB (unknown); 28.75GB EDBOS Filecore
(EDBOS is what I called the drive)

Standard Pi 4 with 240GB SSD:
SCSI::4
MBR
233.57GB – Unallocated 223.57GB (This ia fully formatted 240GB filecore SSD).

SDFS::0
MBR
28.92GB – 50MB FAT (unknown); 28.87G Filecore RISCOSpi

For extra info, a couple of USB sticks

SCSI::0 – Formatted with ROOLs PartMan
MBR
114.60GB – Filecore 57.65GB Filecore; FAT 56.95GB (unknown)

SCSI::1 – FAT32 Drive
MBR
114.60GB – FAT 114.60GB (unknown)

Has a partition type been decided for RISC OS?

https://en.wikipedia.org/wiki/Partition_type

ADh File system Ben Avison, Acorn RISC OS ADFS / FileCore format