Partition Manager feedback

[JonAbbott]

Will test MassFS on Unipod and A9, though IIRC last time I played with this I had issues finding a USB drive small enough that it'd cope with.

MassFS support has had a makeover in the latest build, if you'd like to try it again.

From testing so far, it seems to be a bit hit/miss with some devices working and others not returning from MassFS when read. Formatting MassFS hosted devices hasn't been tested yet, so there might be work for me there - in particular FAT, as MassFS doesn't support MBR partition tables. FAT, like FileCore, can be used without a partition table, but I've not implemented it specifically in PM. Initialising as FileCore, then formatting a new volume as FAT should in theory produce a FAT without MBR - I've not test that myself though.

With regard to MassFS's lack of support for devices >2GB, I wonder if PM might work around that if I cap MassFS to 2GB volumes. That is however assuming the issue is with the MassFS formatter, not MassFS the filesystem. I might also need to restrict it to FAT16, as I'm not sure if MassFS supports FAT32.

[IanJeffray]

PM 1.01 is juuuust too big to fit on an 'E' format floppy now

[IanJeffray]

Using PM 1.01, "Initialise as ICS" with a 1GB DOM and Wizzo in an A5000 throws "Arguments of function/procedure incorrect in "FS.IDEFS" at line 592"

[JonAbbott]

PM 1.01 is juuuust too big to fit on an 'E' format floppy now

I've added instructions on how to "Lite" it.

Using PM 1.01, "Initialise as ICS" with a 1GB DOM and Wizzo in an A5000 throws "Arguments of function/procedure incorrect in "FS.IDEFS" at line 592"

Hopefully fixed in today's build.

[IanJeffray]

PM 1.01 is juuuust too big to fit on an 'E' format floppy now

I've added instructions on how to "Lite" it.

S'fair, but 800K is the "need for lite", not "RISC OS 3.1x".
(ie only for basic A300/A400/A500/A3000, whereas A3010/A3020/A4000/A5000/A4 can all cope with HD floppies and are still 3.1x).
I was actually hoping you might just squeeze a few of the modules and it'd suit everything with no user fuss

Using PM 1.01, "Initialise as ICS" with a 1GB DOM and Wizzo in an A5000 throws "Arguments of function/procedure incorrect in "FS.IDEFS" at line 592"

Hopefully fixed in today's build.

Alas now I just get an immediate "Failed to write partition table", then the whole desktop starts to redraw, no iconbar, then the machine's locked up, though the pointer still moves and you can ctrl-break out of it. It appears to have done "something" to the disc though, as after a restart the greyed-out drive icon now has no label, rather than the plain "IDE" it had before. On restarting PM, it still says "Filecore" as the partition type, and trying the "Initialise ICS" again works as expected - I can create new partitions as required -- creating two partitions gets two drive icons on the bar, BUT they're both just greyed out with no name, even after a reboot - and examination with PM again shows them both as "(unmounted)", with no way to set them as mounted, via PM or otherwise - odd!

A further examination with IDEFormat shows the 495MB and 482MB partitions (the usual sizes I use for these 1GB DOMs) as being 494MB and 481MB, and stating 2MB "available for allocation". Going through the "Initialise all drives" with IDEFormat (keeping the partition table as PM created it) still doesn't get me usable drives - still just the two greyed-out icons on the bar.

BTW, it would be lovely if PM displayed the LFAU info on each partition...

[JonAbbott]

Alas now I just get an immediate "Failed to write partition table", then the whole desktop starts to redraw, no iconbar, then the machine's locked up

I'll need a debug log for that.

I'll take a guess at: A write error occurred when writing the partition table, leaving it in a non-determinate state? Something then errored while BASIC's Error handler was in a corrupt state causing an apparent lock-up?

further examination with IDEFormat shows the 495MB and 482MB partitions (the usual sizes I use for these 1GB DOMs) as being 494MB and 481MB

No doubt rounding differences due to Cylinder size. If I remember correctly, with ICS, PM will round down from the requested size to the closest Cylinder. IDEFormat either doesn't align the end to a Cylinder, or is rounding up.

[IanJeffray]

Alas now I just get an immediate "Failed to write partition table", then the whole desktop starts to redraw, no iconbar, then the machine's locked up

I'll need a debug log for that.

Sure. Thinking about it -- I do often get "funnies" when partitioning media for the first time with IDETool anyway - others have reported the same - basically, partition it, let it moan and say write error, then just do it again and it's usually fine. Odd. I was hoping to avoid such acrobatics by using PM

Is there sufficient data in the debug log that you may be able to use that to see why I've still not got working drives, despite both IDEFormat and PM thinking they're all partitioned and set up suitably? Pretty odd how runtime Wizzo IDEFS obviously has different ideas

[JonAbbott]

I do often get "funnies" when partitioning media for the first time with IDETool anyway - others have reported the same - basically, partition it, let it moan and say write error, then just do it again and it's usually fine. Odd. I was hoping to avoid such acrobatics by using PM

Several of the "ICS-like" IDEFS Modules protect LBA 0 and 1 when there's a valid FileCore volume on the disc...hence the two step process to first invalidate the first FileCore volume, receive the error and then have to repeat the process now that the FileCore area is wiped.

I don't have a suitable Podule to test, but I can probably work around it by coding that process explicitly for ICS hosted drives...its going to need careful testing as there's potential to wipe the first FileCore volume when updating the partition table.

Is there sufficient data in the debug log that you may be able to use that to see why I've still not got working drives, despite both IDEFormat and PM thinking they're all partitioned and set up suitably? Pretty odd how runtime Wizzo IDEFS obviously has different ideas

I've just tested Wizzo under Arculator and the drives did appear correctly so they should in theory appear when created with PM (I didn't use your drive sizes though, so perhaps try smaller sizes to rule that out?).

Check the *Config settings are correct, PM should adjust them so unlikely an issue.

The other possibility is Wizzo/Baildon/ICS are all totally dependent on the drive geometry, in particular the perceived Cylinder size. It also checks the volume Heads/Sectors, which must match the physical drive exactly - even though they're completely irrelevant with LBA addressing.

Do the drives appear if its moved over to an ICS or Baildon Podule?

[JonAbbott]

I do often get "funnies" when partitioning media for the first time with IDETool anyway - others have reported the same - basically, partition it, let it moan and say write error, then just do it again and it's usually fine. Odd. I was hoping to avoid such acrobatics by using PM

I've been trying to repro this under Arculator's ICS ideA emulation.

First point to note is there's a bug in PM where it's not presenting a blocking error dialogue, so it's immediately cancelling any write error and leaving the error box on-screen. The next update will resolve that.

Secondly, I'm not seeing any write errors when initialising a drive as "ICS" partitioning, regardless of it previously being FileCore or ICS with 1 or more partitions. So...there might be version differences with the ICS IDEFS implementation.

Thirdly, I do get an error writing LBA 6 if I initialise the drive as "FileCore" - LBA 6 is protected by IDEFS, seemingly regardless of the previous state of the drive. If I cancel the write, IDEFS then either crashes or shows text on the screen along the lines of "Waiting for harddisc", so I think it then gets into an ambiguous state.

If you can work out the repro steps for the write error you're seeing, I'll see if I can reproduce it under Arculator. In the meantime, I'll see if there's a workaround for the LBA 6 write error.

EDIT: I've tracked the LBA 6 down to a quirk of BASIC, where "IF X=Y>>Z" is not the same as "IF X=(Y>>Z)". With that fixed, I'm no longer seeing the write errors to LBA 6.

[JonAbbott]

- there's a bug in PM where it's not presenting a blocking error dialogue, so it's immediately cancelling any write error and leaving the error box on-screen.
- I do get an error writing LBA 6 if I initialise the drive as "FileCore"

Both of these issues are fixed in the latest build.