Partition Manager

Not that I consider changing this utility to look like a spreadsheet to be a good idea.

Just to clarify I didn’t mean to replace the utility with a spreadsheet like display just the list at the bottom. The reason I suggested it is that in the mockup the titles in the list look to me disjoint from the list and the columns blur into each other. I think a spreadsheet like arrangement could work.

My suggestions were just a case of if I don’t ask I definitely don’t get.

With 0.21 :-

The PartMan partitioned pen shows a number of “extra” partitions.

The ‘Capacity’ values are still wrong. For example Free for SCSI::0, Pen16, shows Free 8GB, Used 6GB and Size 14GB.

My suggestions were just a case of if I don’t ask I definitely don’t get.

Opinions, we all have them. Fortunately I don’t think we’re likely to start a riot :)

0.21 works again but still no SDFS::1

Also SCSI::4, which is my main SSD, 224GB, says SCSI::4/Filecore 223.57GB/ SSD/Filecore and 3.57GB in the pictoral section and in the text section Layout SSD (SCSI::4)- E, New Map, Format Filecore, Capacity 3.57 with free 7.54GB.

Others are similar.

Also if a window goes over the PartManager window it deletes part of the display as does moving/resizing the window so the redraw code may need tweaking.

I can’t put a picture as I have no webspace to place and point to via Textile unless someone else knows how to insert a picture directly?

Thanks for v0.21, I get the following message Parameters not recognised in “add_drives_SCSIFS” at line 87

I’ve switched it back to using *_DiscOp64

Don’t be fooled by the presence of *_DiscOp64.
Last time I looked it didn’t actually do anything different to *_SectorDiscOp which is why it’s not used in Fat32fs.

still no SDFS::1

Just thought could this being tripped up by how the confuguration of drives is set up on the ARMX6 by RComp.

Essentialy it has a built in card reader and also the SDFS drives are set up with some obey files that RComp include.

So I have:
SDFS::0,128GB SDCard – Essentially a back medium
SDFS::1,8GB SDCard – Essentially the recovery drive and not identified via PartManager. Also Freemap, an alternative freemap display app, doesn’t say that it is a SDCard like for SDFS::0
SCSI::0 is displayed on the icon bar but is empty and maps to built in card reader.
SCSI::1 – 64GB USB Stick that shows as 58.4GB in Freemap.
SCSI::4 SSD – 224GB SSD and main drive.

I also have three ShareFS drive icons for remote systems so that brings up the total of eight drives?

SDFS::1 details from RComp:

WARNING
-——

DO NOT FORMAT this disc with !HForm. The OS is housed in 8Mb of “invisible”
space on the disc, so you can’t accidentally delete it, but reformatting may
well result in the disc becoming unbootable. This drive is SDFS::1 when
using HForm – DO NOT format that drive.

So does the partiticular partition set up of this card cause PartMgr not to report it?

HideSDFS obey in Boot.Tasks:

REM OS_UpCall 24 to show icon, 25 to hide
SYS"OS_UpCall",25,“SDFS::0”

OpenHD4 obey file in Boot.Tasks

BootDir$=FNGetSysVar(“Boot$dir”)
drv$=LEFT$(BootDir$,LEN-6)
SYS “OS_SetVarVal”,“BootDrv$Dir”, drv$, LEN drv$, 0, 0
OSCLI “Filer_OpenDir <BootDrv$Dir>”

END
DEF FNGetSysVar(sv$)
DIM Q% 255
SYS “OS_ReadVarVal”, sv$, Q%, 256 TO,, Z%
Q%?Z% = 13
= $Q%

SDFS drives are set up with some obey files that RComp include.

The ArmX6 boots from SDFS:1 and the bootable sd card stores its boot files in an area of the disc marked as defective. According to DiscKnight the defect list starts at 0xA000.

the bootable sd card stores its boot files in an area of the disc marked as defective.

Thanks Colin as I said I wondered if the way it was partitioned, or in this case not partitioned but defected out, might cause an issue with Jon’s attempts to fully read the SDFS::1 SDCard.

As they say “Not all partitioned drives are the same or equal” :-)

Other programs – hform, DiscKnight, SystemDisc – have no problem finding the drive so its odd that PartMan is having problems unless it is being rejected as unreadable. I wonder if a disc is displayed if the format is unreadable.

OpenHD4 obey file in Boot.Tasks

BootDir$=FNGetSysVar(“Boot$dir”)
drv$=LEFT$(BootDir$,LEN-6)
SYS “OS_SetVarVal”,“BootDrv$Dir”, drv$, LEN drv$, 0, 0
OSCLI “Filer_OpenDir <BootDrv$Dir>”

This is BASIC, not Obey. However my surprise is the second line – is it really LEN?
I would expect LEN (BootDir$)

(and why is Textile underlining the LEN?)

OK, I think the question is caused by Textile. Typing LEN followed immediately by (BootDir$) comes out as LEN with an underline. I had to add a space to get it to show what I meant in the question.

(and it’s taken 8 edits to get this to display as I intended. Textile? Bah, humbug.)

(and why is Textile underlining the LEN?)

Because something in capitals followed by something in brackets is interpreted as an acronym with a following explanation that can appear as a pop-up (on capable browsers).

I had to add a space to get it to show what I meant in the question.

You mean LEN(BootDir$)? ;-)

There are two cheats that may be employed here.

The first is to wrap the content in <notextile> … </notextile> (this is extremely useful if referring to code or functions with underscores (which can be misinterpreted as italics) or with exclamation marks (like $.!Boot.!Run) whichh would otherwise be misinterpreted as an image reference.

The second is to wrap the text in ‘@’ symbols which will force it to be code (like LEN(BootDir$) ) and as such it ought to be left alone.

Note, by the way, that detected URLs will be turned into links, even if this is wrong and breaks stuff. Try an http link in the comments of some code, you’ll see the mess it makes as it converts the link into an actual link, and then embeds the actual link markup in the comment.

Hell, here’s an example:

REM <a href="https://heyrick.eu/blog/">https://heyrick.eu/blog/</a>

What you see… is not what I wrote.

and it’s taken 8 edits to get this to display as I intended.

Yeah, Textile is… difficult.

There’s apparently a full detailed spec of exactly how Textile behaves with various sorts of markup. Maybe one day Textile itself will bother to read that spec. ;-)

This is BASIC, not Obey

Yep sorry about that.

“Keep up at the back” and as they also say “should of gone to Specsavers”, other opticians are available, as looking again at the files it is clear they are Basic files.

it’s taken 8 edits to get this to display as I intended. Textile?

Just there to catch you out when you can’t even put something simple in to the comments.

Because something in capitals followed by something in brackets is interpreted as an acronym with a following explanation that can appear as a pop-up (on capable browsers).

Doesn’t marking it as code (like this LEN(BootDir$)) sort it out?

That’s written as

@LEN(BootDir$)@

by the way. If you’re writing a block of code, prefix the first line with bc..<space> and start the following paragraph with p.<space> as documented here.

Doesn’t marking it as code (like this LEN) sort it out?

Indeed. As Rick said:

The second is to wrap the text in ‘@’ symbols which will force it to be code (like LEN ) and as such it ought to be left alone.

However, he also said speaking in jest but catching truth:

There’s apparently a full detailed spec of exactly how Textile behaves with various sorts of markup. Maybe one day Textile itself will bother to read that spec.

Anyone who says they’ve never had textile do something “different” is either telling porkies or needs to play the lottery, so we can get proper RO development funding.

v0.22 is up with some minor bug fixes. I’m not going have much time to spend on it during the week, so it will be the weekend before I can sort out debug output to diagnose some of the issues reported above.

With regard to the window not redrawing correctly – I’m guessing I’ve done something wrong in the icons, that is causing the Wimp to fail to redraw them correctly.

Other programs – hform, DiscKnight, SystemDisc – have no problem finding the drive

I couldn’t remember how I looked for drives to put in the DisKnight front end menus, but I found a bit of old BASIC test code.

REM >EnumDrives
ON ERROR PRINTREPORT$;" at line ";ERL:END
DIM buff% 256
M=0:I=0
REPEAT
 OM=M:OI=I
 SYS"XOS_Module",12,M,I TO R0,M,I,B,W,P
 IFR0<>12 END
 B=B+B!&10
 M$="":REPEAT:M$+=CHR$?B:B+=1:UNTIL?B<32
 P$="":REPEAT:P$+=CHR$?P:P+=1:UNTIL?P<32
 IFM$="FileCore" ANDP$<>"Base" THEN
  FORD%=0 TO 7
   path$=P$+"::"+STR$D%+".$"
   SYS"XOS_FSControl",37,path$,buff%,0,0,256 TO ,,,,,R
   buff%?(256-R)=13
   IF$buff%<>"" PRINTP$;" ";D%;" ";$buff%
  NEXT
 ENDIF
UNTIL0

Also Freemap, an alternative freemap display app, doesn’t say that it is a SDCard like for SDFS::0

God that’s ancient, it was for D-Format discs which needed manual compaction to stop the free space table getting full after just 82 entries. It did have some mild warming over to recognise E and E+ drives, but it doesn’t know about any more recent disc types such as SD cards, and fails completely on some FS’s. Comment out the line in !Boot which makes it take over from the standard Free Space, without running it first.

It did have some mild warming over to recognise E and E+ drives

I’ve yet to figure out how to correctly distinguish between old/new map or D, E, E+, F?, F+? layout ADFS drives as documentation seems to be thin on the ground. Is there a known method to save reinventing the wheel?

FreeMap cheated by parsing the output of the *Map command looking for big map for E format, and big directories for E+ format.

It wasn’t until I wrote DisKnight I had to get my hands grubby by looking at the data on the disc. The good news is it is all in the PRMs for E format, and E+ was in the Ursula documentation (which may still be on the ROL site), the bad news is it is a real head fsck to understand.

DiscKnight doesn’t know anything about a D format drive, and would just get very upset if you presented it with one. E and E+ drives have the same disc record and map structures, but their directories differ, but are clearly marked by differing first and last words. It’s not cached in my head at the moment, but I could probably give some more pointers if pressed.

Oh and F and F+ formats are the same as E and E+, the E and F are use to distinguish between 800K and 1.6M floppies. The conversion used by Acorn was to call the format for harddiscs E/E+, although lots of people incorrectly described them as F/F+.

PartMgr 0.22 looks good here, now showing capacities as expected.

Many thanks.

PartMgr 0.22 looks good here

+1

Though SDFS::1 still missing in action.

FreeMap disabled though I did like, to me at least, it’s better graphical display and thats all it was used for.

After a bit of unplugging, v0.22 works if I unplug my USB SSD which worked with version v0.15

PiBoot (SDFS::0.$.?)
RISCOSpi (SDFS::0)

If I don’t unplug the attached SSD drive, then this version errors with Parameters not recognised in “add_drives_SCSIFS” at line 87"

Please could SATA connected ADFS drives be included when you get chance?
These are FileCore, but on a Titanium with ADFS v4.

After a bit of unplugging, v0.22 works if I unplug my USB SSD which worked with version v0.15

Thanks for the info, I suspect my switch from internally using addresses to LBA’s has broken it.

Please could SATA connected ADFS drives be included when you get chance?

ADFS is next on my list

E and E+ drives have the same disc record and map structures, but their directories differ

I noted the disc record is the same for E/E+. I’ve assumed that if *_DescribeDisc returns with big_flag in a large record it’s E(+) and if it returns a small record its D.

I’m not sure I need worry about directory type as it’s only the format we’re concerned with in a partition manager.

Oh and F and F+ formats are the same as E and E+, the E and F are use to distinguish between 800K and 1.6M floppies. The conversion used by Acorn was to call the format for harddiscs E/E++

I did wonder if they were floppy only. I also noted the idiotic ++ convention, with I think is a RO4/6 format.

Do I distinguish between E/E+ by the size of idlen?

I also noted the idiotic ++ convention, with I think is a RO4/6 format.

Sorry that was a typo from me.

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.

Do I distinguish between E/E+ by the size of idlen?

No, its the by FileCore version at offset 44 of the disc record, should be 0 for E and 1 for E+. Those pages really need updating for E+ format.