FreeNVMe

HForm is traditionally crunched, so it’s possible it was either done with the wrong settings or the changes have broken something.

I’ve been trying to add support to Parttition Manager by reverse engineering the Modules this weekend, but not having much luck so far. There’s no low level disc access, so I can’t send a Namespace Identify command to drives. There is an SWI for disc info, but it appears to cap the max LBA value. There also doesn’t appear to be a means to notify the Filer of drive changes, although there are Service calls I’ve yet to investigate.

As it’s written in C, it’s really hard to identify what’s going on in the code. Source and documention would be really helpful, so I might have to back burner this until they’re available.

From what I’ve noted so far, some additions will be required before I can properly support NVMe in Partition Manager. Low-level access to drives, bypassing the OS is essential.

I’ve also looked at NVFS and it has similar issues, but slightly worse, as there doesn’t appear to be a way to discover the physical drive size. There’s also the issue of the Service, SWI block and Filing system numbers possibly not being allocated – they’re not in the official tables at any rate.

As things stand I can’t add support for NVFS, but might be able to add limited support for NVMeFS, although partitioning will break things without low-level access.

On this last point, ROOL and the two companies involved need to agree an interface, along the line of what is already implemented for IDE and SCSI, where commands can be sent directly to drives.

HForm is traditionally crunched, so it’s possible it was either done with the wrong settings or the changes have broken something.

It is only NVMe formatting that goes wrong.

The tool doing the damage is squish. Warnings are issued during the build but no errors.

There is also a BASIC CRUNCH done, which is benign.

It’s a pity the BASIC compare progs couldn’t compare crunched progs with the uncrunched versions.

Hform NULL.POINTER.DEREFERENCE at line 945

Somehow the SWI number is wrong at line 945. In the squished BASIC it is 370208, NVMeFS_FreeOp. From the source it should be NVMeFS_DiscInfo, 370207. A manual change of that last digit suffices, the format dialogue continues. (I used Zap to preserve the BASIC file format. This may not be necessary.)

I have not tried a full NVMe format as it is possible that may be other SWI number errors, what else is broken?

Oops, duplicate post.

Hform NULL.POINTER.DEREFERENCE at line 945

Somehow the SWI number is wrong at line 945. In the squished BASIC it is 370208, NVMeFS_FreeOp. From the source it should be NVMeFS_DiscInfo, 370207. A manual change of that last digit suffices, the format dialogue continues. (I used Zap to preserve the BASIC file format.This may not be necessary.)

I have not tried a full NVMe format as it is possible that may be other SWI number errors, what else is broken.

There’s also the issue of the Service, SWI block and Filing system numbers possibly not being allocated – they’re not in the official tables at any rate.

It seems unlikely that ROOL (the organisation responsible for allocations) would be announcing NVMe while simultaneously having forgotten to allocate these quantities with themselves.

A quick squint at the front page ‘Recent changes in Git’ confirms my hypothesis. How are you not finding this stuff? At time of writing it’s literally the top 4 items in the change history.

How are you not finding this stuff?

If you re-read my post you will see I referring to NVFS.

Minor amendments made to the NVME Drivers so that they work with ROOL’s HForm, as expected. Please redownload from https://www.riscosbits.co.uk/nvme

That has sorted it, thanks.

My SWI number to string app is now showing 370208 as NVMe_DiscInfo. Ditching the squish operation also ditched the SWI name to number conversion which is why an unsquished HForm worked but a squished one did not.

Has anyone explained the differences between all these hard drive systems – scsii idfs etc.

Last year SW Show was telling about fastest RO system – gets rather confusing to old duffers :-(

Has anyone explained the differences between all these hard drive systems – scsii idfs etc.

We’ve carried quite a few articles about the new hardware in The WROCC over the past year or so.

If trying to load the new version which seems to be compiled by ROOL I am getting an “invalid library chunk” on all of my machines (independently whether there is PCIe existing or not). I am not getting this if using my own versions however.

Regarding HForm troubles. I used originally 3270207 for DiscInfo. It seems that ROOL changed this to 320208 during code review which is in general ok. However I was not aware of this change. The bas version of HForm uses the name and not the number so this never was detected. Sorry for that.

Regarding Jons problems with Namespace Identify commands I am finding this a bit strange. I am not aware what ROOL left from my original source but NVMeDriver contained exactly this possibility. I used it during development and from BASIC and it works. Offering no low level access doesn’t make fun.

NVMeDriver contained exactly this possibility. I used it during development and from BASIC and it works.

If you have any documentation or failing that, a test example, please send me a copy. I’ve been asking after documentation since January and have had to resort to looking through Modules.

If trying to load the new version which seems to be compiled by ROOL I am getting an “invalid library chunk” on all of my machines (independently whether there is PCIe existing or not). I am not getting this if using my own versions however.

The new version as downloaded from the riscosbits site dated 24-03-03 is good here.

*fx0
RISC OS 5.29 (23 Feb 2024)
*help SharedCLibrary
==> Help on keyword SharedCLibrary
Module is: C Library       6.22 (29 Nov 2023)

Loaded  NVMeDriver        0.01 (30 Jan 2024)
Loaded  NVMeFiler         0.01 (03 Mar 2024)
Loaded  NVMeFS            0.01 (14 Feb 2024)

Beware though that the first zip version, downloaded here from RiscOSbits on 26th Feb, contained…

NVMeDriver 0.01 (22 Feb 2024)       this is *after* the latest zip.
NVMeFiler  0.01 (16 Feb 2024)       this is before the latest zip.
NVMeFS     0.01 (22 Feb 2024)       this is *after* the latest zip.

Just noticed that the zip from gag.de is different again!
And is using SWIs incompatible with Hform.

Their sizes are also rather different

I expect the sizes will change (without a version bump) when the autobuilder is creating the Modules, as the original release was compiled with 26bit compatibility.

Regarding versions:
I agree that the actual situation is not optimal. However you have to take into account the following things:

I dared to make a walk yestderday afternoon as it was one of the first sunny spring days here after a long grey rainy winter and because of this I read RISCOSBits email first at evening.

RISCOSBits wanted to remove the problem with HForm quickly and so they published the module variants obtained from ROOL compiled already before after a short test (and it worked for them).

ROOL is developing their code and I am still owning my code. There is a loose exchange between us about findings and changes. In most cases this worked until now but sometimes it fails. However I am not aware how ROOL is doing their version management in the moment. Their version isn’t offcial yet. So I assume that they didn’t pay attention to the version number. I am myself trying to adapt at least the date.

Regarding size I can only say that my versions are debug versions which are containing a lot of debug messages. May be that the ROOL modules are non debug versions. And of course they did already some optimizations.

Regarding GAG: Mr. zur Nedden as maintainer of the homepage is very engaged in RISC OS. However AFAIK he has also a live beyond RISC OS. ;-) If RISCOSBits is publishing a new variant he will try to update the GAG website accordingly within a few days after he is informed and when he has time to do so. In this case there was also the problem that I wrote to RISCOSBits that I am facing trouble running the new modules. So I assume Mr. zur Nedden will wait with his updates until there is a version running on all machines.

Enjoy your walking :-))

I meanwhile found the problem on my side. The ROOL modules are requiring at least SharedCLibary 6.22 from November 2023 to work.

Sprising what ideas come when out walking :-)

Minor amendments made to the NVME Drivers so that they work with ROOL’s HForm, as expected. Please redownload from

I am sticking to the 22-Feb-2024 versions (and the uncrunched HForm) as the later 20-Feb/3-Mar ones fall over. Version numbers the same most puzzling:

In the 22-Feb bundle (released at the show):
NVMeDriver 0.01 (22-Feb-2024) datestamp 22:38:58 22-Feb-2024 29k
NVMeFiler 0.01 (16-Feb-2024) datestamp 22:39:02 22-Feb-2024 29k
NVMeFS 0.01 (22-Feb-2024) datestamp 22:39:06 22-Feb-2024 39k

In the 03-Mar bundle (from link above):
NVMeDriver 0.01 (30-Jan-2024) datestamp 09:51:06 20-Feb-2024 15k
NVMeFiler 0.01 (03-Mar-2024) datestamp 09:45:41 03-Mar-2024 15k
NVMeFS 0.01 (14-Feb-2024) datestamp 09:51:26 20-Feb-2024 14k

I suspect these have been put together with some haste. I am using a 29 Feb 2024 ROM with updated start4.elf and fixup4.dat so that large SD cards and eMMc appear to work and be allocated the correct drive numbers, i.e. :0 or :4 depending whether removable. No doubt the bug fixes (to #512 and #611) will make their way to the daily roms in due course.

Having reformatted the NVMe drive after some testing with PartMan (which may have corrupted the boot block) I found the 03-Mar bundle worked OK. It seems the version numbers and datestamps are still slightly odd though.

Putting the version numbers to one side, I have reformatted the NVMe drive after various testing as it got beyond the abilities of DiscKnight to fix. I have used the 03-Mar RISC OS Bits drivers and done some performance checks:

ROM unpack 33s
ROM compile 3m31s

HD Read – Block load 8MB file 202772 6799%
HD Write – Block save 8MB file 291992 9601%
FS Read – Byte stream file in 2974 1436%
FS Write – Byte stream file out 2641 1375%

This is extremely good performance – lots of thanks to RISC OS Bits and ROOL.

I have tried a 1TB NVMe drive, formatted with 4k sectors giving a RISC OS partition of 750GB.

This gives a worthwhile improvement in random read and writes:
RISCOSmark 2.06 (29-Mar-2016) by Richard Spencer 2003
Filing system: NVMe:HardDisc4.$.SpeedTests
HD Read – Block load 8MB file 192752 6463%
HD Write – Block save 8MB file 270415 8892%
FS Read – Byte stream file in 4216 2036%
FS Write – Byte stream file out 4347 2264%

Also ROM unpack 33s
ROM compile 3m13s

Using a 4K Sector formatting application currently in development, we’ve managed to format and use a 1 Terabyte NVMe drive with FreeNVMe under RISC OS. We only needed to pop over to Linux to switch the drive from emulated 512 byte sectors to native 4k sectors.

We’re also getting very similar speeds to those shown above.

The developer of the 4k formatting tool has just informed me that work is underway to remove that last Linux hurdle, and that his formatter will soon be able to convert drives from 512 byte sectors to 4K sectors under RISC OS!

Already working in testing, too.