Partition Manager

Logs from another RPC here, in case it’s useful. There is only one disc, but it’s shown as unallocated.

http://www.adamshome.org.uk/RiscOS/RPC-402-debug.txt

I’ve tried v0.48 on A5000, RiscPC and Iyonix, all three see the discs but report as either unrecognised or unallocated

Logs from another RPC here, in case it’s useful. There is only one disc, but it’s shown as unallocated

Please try v0.50

EDIT: I forgot to mention that v0.50 has most of the WIMP code in it, if folk want to play with it and feed back any comments.

Up to and including RISC OS 3.1, D (old map, new dir) and E (new map, new dir) are supported. RISC OS 3.5 and above offically ceased support for D format harddiscs (according to PRM 5a – D format floppies remain supported), but I think the code was still there and it worked

Given that information, I think we can drop D format and only need two options:

E, New map, New dir
E+, Big map, Big dir

EDIT: On second thoughts, I think I’ll just go with E/E+ and drop the map/dir info as it’s confusing. I’ll auto select the map size and E+ will default to Big dir

It’s just a shame that FileCore in older versions of RISC OS 5 can’t handle the big map with idlen>19, as it was so obvious this would be required for the ever increasing sizes of discs. That would remove the rather artificial distinction between E+ formats which require RISC OS 5.2×.

Thanks, Jon, 0.50 correctly reports filecore on the Iyonix and RiscPC now, but still says unrecognised for the CF card on the A5000. To be fair, it has odd values, I recall it took some time to get it formatted to something that would work when I set it up a couple of years back. If it helps, HForm says… 993 Cylinders, 16 heads, 63 sectors/track
I’m pretty sure I use an old version of HForm to get it to work in the end, but exactly which version, I couldn’t say now.

0.50 correctly reports filecore on the Iyonix and RiscPC now, but still says unrecognised for the CF card on the A5000

Thanks for confirming. The reason for the A5000 not being recognised is because it has a valid MBR partition table, with a FAT partition spanning the disk:

MBR partition table found

Partition 0
-----------
Partition type=&E
Start LBA      =&00000003F
Size in LBA    =&0000F45B1
Checking ADFS 0 partition 0 for FAT

A FAT volume obviously isn’t detected as its not actually there, so it’s falling back to assuming it’s an unformatted partition.

It’s just a shame that FileCore in older versions of RISC OS 5 can’t handle the big map with idlen>19, as it was so obvious this would be required for the ever increasing sizes of discs. That would remove the rather artificial distinction between E+ formats which require RISC OS 5.2×

FileCore is quite frankly a mess. You know more about this than I do, but from all the docs I’ve read in the past week there are multiple variables associated with a volume (Map type, Directory type, Directory size, LFAU, idlen, sector size, Rootdir address, Zone count, big flag, …) and FileCore versions support differing values.

I gather LFAU needs to default to the physical sector size (so 4K on both 4K/4K and 4K/512 drives), from that the idlen, Zone count, Map type, big flag can be calculated from the partition size and Rootdir address set from the Zone addresses?

When the partition size can’t be reached with the selected LFAU, do I increase idlen up towards the max FileCore supports and then start increasing LFAU as a last resort?

A5000 not being recognised is because it has a valid MBR partition table, with a FAT partition

Makes sense, it would have been valid FAT before I started. Thanks for the explanation.

@Jon I only really know about making the existing format good, there are others that know more about creating a format from scratch. But from my experience you always start with the maximum supported IDLen (currently 21) which 1<<IDLen gives you the maximum number of addressable units, divide the size of the disc in sectors by this and round up to the nearest power of two to get the LFAU in sectors. Larger LFAUs can be selected, where each doubling results in one bit smaller max IDLen, and halves the number of zones in the disc map.

That was the easy part. To get the number of zones required, you need one bit per LFAU divided plus the size of the disc record which lives in zone 0. Take that number of bits and divide by the number of usable bits in a sector (bit size minus unused bits per zone). The first zone of the map starting after the disc record should contain the boot block ID, and root directory should always be located in the middle zone of the map, the last zone will usually extend beyond the end of the disc, so that also needs to be marked appropriately. (Can’t remember all the IDs for that, but can look them up. At one point I knew how to allocate objects in the map too!).

Logs from another RPC here, in case it’s useful. There is only one disc, but it’s shown as unallocated
Please try v0.50

Works correctly on RPC now.

FileCore is quite frankly a mess.

Indeed. It’s essentially a 6502 era floppy format that evolved several times into what we know now, with bits bolted on here and there.

It probably would have been better if the different formats were actually entirely different things and not just “setting this bit in the boot record means…”.

with bits bolted on here and there.

So long as the bolts are good quality!

So long as the bolts are good quality!

Please allow me to present to you the Wimp where there are multiple places where “TASK” (or &4B534154) switches behaviour. The nested Wimp uses this to extend window calls to deal with parent/child associations, and the most famous use is Wimp_Initialise where it basically means “this isn’t Arthur so multitask it properly”.
Not to mention the icky multiply keypress way of handling UTF-8 characters so that they don’t clash with the pre-existing &1xx character codes (all the function keys and such).

Then there’s the fun of trying to work out what a sprite is. There are four ways of specifying what a sprite is – old style mode number (which falls apart when using custom modes that aren’t present on the system in question), a mode selector block (a pointer to it), a RISC OS 3.5 style mode word, or a RISC OS 5 style mode word. Phew!

BASIC has pretty much the same set of keywords as always, but they can now be used in new and exciting ways – DIM this% LOCAL 123 or COLOUR OF a,b,c ON x,y,z

Bolting stuff on does help to keep existing formats and APIs in use, but it can make stuff complicated!

That was the easy part

:|

I think I’m going to attempt to merge HForm into my FileCore library and offset all DiscOp to the start of the partition.

I have just tried 0.48 with a Kingston Memory stick formatted with !FAT32Form (using Fat32Format dated 23 Feb 2016)

This is on a 5.28 Ras Pi 4 with no other discs connected. (PartMgr is on the Memory Stick which opens as Fat32fs::Kingston.$ – 14GB mostly free))

Partition Manager window shows an empty MBR disc of the correct size:

I get the same result with the mSATA drive and boot SD card connected.

EDIT: Debug file in Tests now deleted.

I have justt tried 0.48 with a Kingston Memory

I would try PartMgr 0.50
and see if it is the same.

Sorry, I should have said that 0.50 gives the same result, but I do not have an image file or a debug file without the other discs.

Except for the hacks I’ve put in place to trap full disc FileCore drives formatted with ROOL/Castle HForm variants, it’s expecting to find a partition table.

It checks in order of preference, GPT, then MBR, finally falling back to full disc FileCore.

MBR is detected by the signature &AA55 at &1FE in LBA 0 and in your case !FAT32Form has written the MBR signature, but no corresponding partition entry for the FAT32 area, so strictly speaking your disc is MBR unpartitioned.

I could change the code so it ignores an MBR with a zeroed partition table, but that would simply break partitioning if you initialise a disc as MBR. I’d also have to code support for unpartitioned FAT drives, which is possibly not realistic as a FAT drive created on Linux/Windows should partition the drive.

What do Linux/Windows report when you plug the drive in out of interest?

No problem

Windows XP repors it as full disc FAT32 (no partitions).

I no longer have any linux systems.

MBR is detected by the signature &AA55 at &1FE in LBA 0

That’s not true. If there is no MBR then it will be the VBR.

MBR is detected by the signature &AA55 at &1FE in LBA 0 (of the drive)

That statement is true…however…

VBR is detected by the signature &AA55 at &1FE in LBA 0 (of the volume)

Is also true.

Unless I’ve missed something, it’s impossible to distinguish between an MBR with no partitions and non-partitioned device with a VBR as they are identical.

I’m no expert, but if the drive is non-partitioned then presumably it won’t have a (PC-style) volume and therefore no VBR. So, if you see this layout, it must be MBR with no partitions.

Does that make sense or am I just showing my ignorance? :)

I’ve hit a few snags:

1. LOCAL variables leak memory in BASIC
2. I’m struggling to get HForm’s initialisation code to write a detectable (via PartMan) FileCore partition outside of HForm

Mitigation options for issue 1:

1. Write my own variable/memory handler – lots of work and code bloat, to the point it probably wouldn’t fit in memory on a 1MB machine
2. RMFaster BASIC and bug fix it
3. Bundle updated 26/32bit versions of BASIC and run the code in its own BASIC environment on older machines
4. Drop libraries/future proofing/portability and switch to C

Option 3 seems the most sensible and the least effort

Mitigation options for issue 2:

1. keep plugging away at it
2. document FileCore on the Wiki and writing from scratch

I have no idea how long either of those paths would take, almost certainly months for the later.

I’m fairly certain the problem I’m having with the HForm code is its use of global variables. Very few are declared up-front and in a lot of cases they should in fact be LOCAL’s, so I think I’ve missed setting some key variables, which is resulting in a malformed structure. From just looking at the DiscOp output, it does appear to be writing to the middle of the partition, so there’s also the possibility of “out by 1” issues, where the Zones are out by 1 LBA.

On a more positive note, within the Wimp I can now initialise a GPT drive, add and delete partitions and at least attempt to format them as FileCore. I’m not going to make it public yet though, as I have to implement all the error handling and do a lot more testing across RO aversions and device types. I also need to fix the BASIC memory leak issue before it’s usable.

LOCAL variables leak memory in BASIC

If by ‘leak’ you mean that they use more memory each time the PROC/FN is called, then can you give an example? Does it apply to all types of variable?

Perhaps if you push the global value of a string variable onto the stack, then create a LOCAL one of a different length, then pop back the global value that consumes memory just like setting a string variable to a longer length. String fragmentation used to be a big issue with small amounts of RAM. Garbage collection could take ages and occurred at unpredictable times.