Partition Manager

ROL did mess with the disc format by adding things such as the display and sort order to directories, but they refused to give me any information, so if DiscKnight see’s any reserved bits being non-zero it will zero them until such time as they are formally documented.

1. Gerph probably knows and could supply the info to document this.
2. It sounds like any removable device swapped between the two forks could currently end up with screwed up directory info – not good

For FileCore details, it is always a good idea to look at Gerald Holdsworth’s documentation of various Disc Image Formats

http://www.geraldholdsworth.co.uk/documents/DiscImage.pdf

as well as his DiscImageReader Delphi sources:

https://github.com/geraldholdsworth/DiscImageManager

You just need to strip out the superfluous Amstrad and Commodore stuff :-)

ROL did mess with the disc format by adding things such as the display and sort order to directories,

Shouldn’t this be a UI thing rather than a fiddling with the disc format thing?

Shouldn’t this be a UI thing rather than a fiddling with the disc format thing?

If you want to be able to set different settings on a per-directory basis then it makes sense to put it in the directory’s metadata… so long as it’s documented. If it’s not documented then it’s effectively corrupting the metadata.

If it’s not documented then it’s effectively corrupting the metadata.

Like I said “not good”
Now, if it’s documented and can be replicated in RO5 it might be useful.
There is of course the not so small issue of whether that metadata fiddle can be carried into non-Filecore formats

It took a long time to get my head around the E+ format when did the (badly named) ‘adfs-tools’ stuff in python that does a (very limited) amount of stuff with filecore discs.

These are FileCore, but on a Titanium with ADFS v4.

I started looking at ADFS4 last night, unfortunately the author failed to document the SWI’s (ATA_Op?) on the Wiki.

I’m sorry, but I should not have to wade through recent source code additions to the OS and write the documentation for the author. As a rule, ROOL should not accept anything into the OS source unless its been correctly documented on the Wiki.

It’s bad enough having to figure out SCSIFS and FileCore. At least there’s some documentation on them – even if it isn’t accurate or make any sense!

It took a long time to get my head around the E+ format

Yes, I’m not looking forward to implementing “Format”. I have some knowledge of some of the background tasks from ADFFS and working with floppies, but I’ve never touched HD’s. From reading what documentation I can find on FileCore over the past week, its pretty poor. Basic information such as how to translate an Internal Disc Address (eg RootDir) to an LBA is simply missing in all of the official documentation I’ve looked at so far.

I started looking at ADFS4 last night, unfortunately the author failed to document the SWI’s (ATA_Op?) on the Wiki.

I agree that updating the Wiki should be part of any change.

But in this case, ADFS4 seems documented in Git sources, in:
FileSys.ADFS.ADFS4.doc.ADFS
and the SATADriver documentation is in:
HWSupport.ATA.SATADriver.doc.ATA

Which may be sufficient for your purposes.

v0.24 is now up, which adds IDE based ADFS support. I’ve tested on all major OS versions from 3.11 up to 5.23 on an A4000, RiscPC and Kinetic.

One issue I need to resolve is how to handle FileCore drives within MBR/GPT partitions, that don’t actually fill the partition. My A4000 for example has a 2GB MBR partition, but RO is only using the first 512MB.

Strictly speaking, my A4000 is a “full disk FileCore drive” that only uses the first 512MB, but just happens to have a valid MBR on it that HForm didn’t erase when it was initialised.

My current train of thought is to show the FileCore area as being embedded within the partition. This method could also be used to handle full FileCore drives that have an embedded FAT partition, which has already been highlighted above. I’ll create some mock-ups for peer review before I implement anything.

Which may be sufficient for your purposes.

Thanks Martin. Ironically, I did look for a documentation folder in Git, but somehow managed to miss it.

Please try 0.24 on the Titanium. From looking at the doc, it seems to mirror ADFS so should hopefully now work.

13 Jan 18:44:59 000 000001E6: Error from Partition Manager: SWI name not known in “volume_info_FileCore(, )” at line 13

Do I have something missing?

13 Jan 18:44:59 000 000001E6: Error from Partition Manager: SWI name not known in “volume_info_FileCore(, )” at line 13

Looks like it needs ADFS to be available which doesn’t exist in ROM on e.g. RPi. It ran OK when I loaded !ADFFS which has a fake adfs module.

Looks like it needs ADFS to be available which doesn’t exist in ROM

Oops, I didn’t check it on the Pi without ADFS. I’ll quickly fix it and upload a revised version.

13 Jan 18:44:59 000 000001E6: Error from Partition Manager: SWI name not known in “volume_info_FileCore(, )” at line 13

v0.25 is now up which fixes this error.

From the Titanium.

Apart from that PartMan partitioned pen, SCSI::2, the only comment is that the size of ADFS::6 is actually 128GB, or 120GB, would need to demolish the machine to see what it really is. It does have a large LFAU set to speed up ROM builds, 32768, which may or may not have anything to do with anything. Looking a bit harder I see that all three ADFS SSDs show the same size in the left, grey, icons.

v0.25 similar to previous result reported.

When I don’t unplug the attached SSD drive (EXT4/FAT), then this version reports Parameters not recognised in “add_drives_SCSIFS” at line 88"

Nice to see ADFS support. Please consider 4Kn drives and take 4096 byte sector size into account.
With my 2TB FileCore formated drive the capacity shows 232.87 GB instead 1863 GB. The Free space is shown correctly.

Have try “all I have” ;-)

ADFS::4 Is my RootFS for Ti Linux and Fat for both
ADFS::5 My Ti boot device
ADFS::6 2TB FileCore as Anton point it out
ADFS::7 various… normally BlueRay, now a partman drive from MX6 all detected correct but not usable on SATA
SCSI::4 1TB SSD with FileCore and FAT32FS made with Toni’s PartFC
both partitions are usable via SATA and SCSI. Same detection if I plug on SATA.

If I plug the partman device to Ti USB, v0.25 crashes with the line 88 error but is usable with partman compiled for Ti.

ARMX6: With the partman device…

SDFS: Sorry I can not take look inside but I’m sure, one SDFS devise is without a card (0 detect nothing), the other (1) hold the boot section, the rest is Filecore HardDisc0 round about 1GB tells Free..

Do I have something missing?

Thank you (and Chris).

It would really save a lot of effort if this forum listed stuff latest-first!

Who do I need to hassle?

It would also help if the posts per page setting “stuck”, however the limitations of the forum software are probably such that getting what most people might want is unlikely without moving to a new set of forum software.

It would also help if the posts per page setting “stuck”

I understand that we’re using an existing platform which is “stuck in time” unfortunately!

But …

We can aspire!

v0.26 has rewritten IDE drive sizing code, having now read the IDE spec, it might now get a different result. v0.25 used code from HForm, which didn’t make a lot of sense if I’m honest.

Please consider 4Kn drives and take 4096 byte sector size into account.

As far as I can tell, IDE only supports 512 sectors. Having read a copy of the spec I could not find a way to determine the LBA size. That said, I need to sign up to T13 to get the current spec and will see if that provides more info.

SDFS is similar, in that it appears to have a fixed LBA of 512 bytes and no official way to find out the actual size – at least not documented, that I can find. SDFS_ReadCardInfo only returns the drive size in bytes and not the LBA size.

Parameters not recognised in “add_drives_SCSIFS” at line 88"

That error is a failed DiscOp, so somewhere the LBA is wrong. I’ll only be able to diagnose that once I write the debug code.

May I just say how grateful we all are that you are tackling this issue!

I have personally no interest in your other work, but appreciate that you are addressing an issue of more general import!

Bravo !

John, bookmark https://www.riscosopen.org/forum/posts

The Recent Posts page is listed newest first. Plus it’s a useful overview of everything.

BTW, did anybody else notice David’s SCSI::2 drive? Third (unallocated) partition – 984003.95TB!
I don’t know whether I’m more impressed that he allegedly has nearly a million terabytes, or that the program (BASIC?) actually managed to calculate a number that large.

Hi Jon,

Thanks for 0.26.

On my Iyonix running 5.29 it gives a slightly odd disc reading for the second disc it seems the same as this.

the only comment is that the size of ADFS::6 is actually 128GB, or 120GB,

So ADFS::5 gives Filecore in the left hand window:

ADFS::5
FileCore
111.79

and in the right:

Iyonix2
Filecore
128.18

in the text it says:

E+ Boot, Big Map, Filecore – Capacity 128.18 Free 11.11 GB

Map shows it as 128GB, Total Used 117GB

If I run HForm it gives

Config Cylinders 16383 , 16 Heads, 63 Sectors/Tracks
Total LBA 312581808
84573 cylinders/16 Heads/231 Sectors

Last formatted:
72732 Cylinders/16Heads/231 Sectors/Tracks.

Hope this helps as Part Manager is something that is going to be really useful going forward.