FreeNVMe

Don’t eNVy Me – it’s FreeNVMe

After months of development work and testing, RISCOSbits and Stader Softwareentwicklung GmbH, partnering with RISC OS Open, are pleased to announce the initial release of FreeNVMe, a free and open source NVMe driver for RISC OS. NVMe is a modern storage technology, widely used in the PC world, that allows faster access to small footprint (sometimes tiny!) but high capacity storage.

As demonstrated at the MUG Show and the WROCC meeting in December, FreeNVMe is currently designed to work on Raspberry Pi Compute Module 4 based systems, with a roadmap already in place to bring it to other PCIe based machines, such as Elesar’s Titanium, in the very near future.

FreeNVMe is based around the “nightly builds” concept, so is initially available as a softloadable driver so that users can keep RISC OS up to date AND still use NVMe storage, without the need for a custom-built ROM.

RISCOSbits will be demonstrating the fully functional FreeNVMe at the SouthWest Show on Saturday 24th February, and a range of fully-equipped NVMe machines will be available to buy and take away.

Downloads will be available in the very near future, including access to pre-built driver modules. For developers wanting to get involved in the project, the source code for FreeNVMe will also be made available shortly. We will also provide a “compatibility list” of drives and equipment that conform to NVMe standards and are known to work with FreeNVMe.

Thanks should also go out to our many testers (some from the other side of the world!), whose feedback and support proved invaluable in bringing this open source venture to fruition.

As soon as the documentation is available, I’ll look at adding support to Partition Manager.

Emailed you privately

Here’s the first download location for the beta binaries for the FreeNVMe driver for use with a Pi Compute Module 4 and a suitable NVMe drive…

https://www.riscosbits.co.uk/nvme
https://gag.de/software/nvme.html

A compatibility list of known working drives will appear soon, but for now, drop us an email to info@… and we’ll let you know what we’ve found so far.

More download sites will appear in the coming days.

Drives on the Waveshare board need to be thin underneath as they have to clear a 30mm mounting collar. The DeskPi Mini has only a 42mm mounting so 30mm drives will not fit (but thicker 42mm drives will). Only an adapter board for the Pi Foundation IO board can accommodate sizes above 42mm.

        iozone -e -I -a -s 132M -r 4k -r 8k -r 16k -r 32k -r 64k -r 128k -r 256k -r 512k -r 1024k -r 2048k -r 4096k -r 8192k -i 0 -i 1 -i 2
        Output is in kBytes/sec

Both drives LFAU 32K

NVME Samsung SSD 970 EVO 500GB
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          135168       4    29720    30942    30259    30268    24095    30825                                                                
          135168       8    52521    55951    52907    52968    43147    55771                                                                
          135168      16    85256    94310    85053    85296    72034    93860                                                                
          135168      32   124810   144048   122874   123278   106969   143351                                                                
          135168      64   162012   196071   157599   158460   145380   195863                                                                
          135168     128   192769   241486   183777   184798   175051   240980                                                                
          135168     256   212348   273401   200629   201752   194437   273468                                                                
          135168     512   224195   293890   209806   211443   206153   293622                                                                
          135168    1024   230670   300159   209031   211082   207063   302154                                                                
          135168    2048   260270   305291   203445   205747   205005   303173                                                                
          135168    4096   280323   303888   203489   206087   205253   307578                                                                
          135168    8192   291934   304158   204279   206526   205553   306539                                                                



Sata WDC  WDS500G2B0B-00YS70 466 Gbytes

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          135168       4    63546    67017    64554    65863    28171    67468                                                                
          135168       8   109126   113731   107605   108429    48143   113683                                                                
          135168      16   161298   169761   165469   166899    71249   170323                                                                
          135168      32   212474   229174   224855   227955   112870   229760                                                                
          135168      64   251976   275723   273412   274911   159991   276054                                                                
          135168     128   276407   304243   312371   317858   201151   307138                                                                
          135168     256   290415   321553   340537   338330   230146   323810                                                                
          135168     512   298382   329373   346090   342765   273552   331419                                                                
          135168    1024   297430   338656   337453   344049   306204   334766                                                                
          135168    2048   299171   346812   347875   344364   325157   336701                                                                
          135168    4096   316663   341776   337248   344526   337012   344073                                                                
          135168    8192   319508   342290   348249   356293   348443   339215                                                                

The performance figures are impressive but it cannot be for a filecore filing system (as it is faster than RAMfs).

Thanks Chris for those figures…
Am I right that the bigger the figures the faster the drive – in that case what system was the SATA-SSD connected to, and the NVMe since it seems faster than the NVMe one to me.
Especially since they are connected to different computers comparability does drop since oddly enough the CPU and RAM speed probably does have some impact.

We’ve found in testing that RISC OS FAST is marginally faster than NVMe but I doubt anyone would ‘feel’ any difference in everyday use.

There are still a few optimisations that can be applied to the NVMe driver. Watch this space!

Some extended testing using ROMark:

Percentages are shown against the performance of RAMfs. The red shading indicates that both NVMe drivers have difficulty with FAT formatted NVMe drives. Early SATA drives (circa 2016) had faster SSD devices and were more expensive, see e.g. the Crucial MX200 which has very good random read and write speeds. Later SATA drives had slower SSD chips but added things like on-board DRAM to make it cheaper and compensate for slower chips. The CM4 interface is limited to PCIe Gen 2×1 lane, i.e. peak speed of 400MB/s.

Equivalent performance figures from Linux:

The Linux commands to get approximately equivalent sequential read/write and random read/write performance figures to those from ROMark in RISC OS:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read.fio --bs=4k --iodepth=1 --size=250M --readwrite=randrw --rwmixread=80
(use --bs=8M --readwrite=read for HD read)
(use --bs=8M --readwrite=write for HD write)

Am I right that the bigger the figures the faster the drive – in that case what system was the SATA-SSD connected to, and the NVMe since it seems faster than the NVMe one to me.
Especially since they are connected to different computers comparability does drop since oddly enough the CPU and RAM speed probably does have some impact.

I used the same hardware for both tests. A waveshare CM4-IO-BASE-B board. The CM4 was clocked @2.35GHz.

The results do seem to be drive dependent for smaller record lengths.

Results for a NVME WD Blue SN570 1TB. The LFAU size was 32K. I also tried a 2TB WD Black set to 4K mode but it wasn’t recognised which implies there’s no 4K support yet.

                                                              random    random                             
              kB  reclen    write  rewrite    read    reread    read     write
          135168       4    42354    44104    40884    40916    29129    44277                                                                
          135168       8    72213    76350    68976    69116    49958    76613                                                                
          135168      16   112582   123351   106640   106935    82435   123750                                                                
          135168      32   157034   177447   146298   146657   121502   178119                                                                
          135168      64   196680   228269   178172   178952   159089   228525                                                                
          135168     128   224374   267343   200490   201636   187483   268122                                                                
          135168     256   242731   294159   213792   215214   206178   294062                                                                
          135168     512   251478   311452   221241   222594   217185   311553                                                                
          135168    1024   249093   306483   217916   219355   215669   307014                                                                
          135168    2048   270486   300973   212962   213709   211837   302647                                                                
          135168    4096   288873   302375   210853   212343   210280   302181                                                                
          135168    8192   295427   302896   210416   211538   211192   304978

Results for building a RISC OS rom for two different nvme drives compared to ramfs.

                          
ramfs: 1 min 51s

Samsung SSD 970 EVO 500GB: 2 mins 30s

WD Blue SN570 1TB: 2 mins 25s

If I try to format an nvme drive with the latest !HForm I get the error,

NULL.POINTER.DEREFERENCE at line 945 after selecting the drive number. !HForm then quits.

I had to use a USB adapter to format an nvme drive.

Hform NULL.POINTER.DEREFERENCE at line 945

Looks as if could be a problem with the NVMeFS SWI “NVMeFS_FreeOp” to me, unless the Drive% is bad in r0?
No idea which version, or even which incarnation, you are using.
Maybe ZeroPain would give some more details?
But strange that over USB it works.

Now I have a puzzle. I have two SATA drives, both Crucial MX200 250GB, but one has twice the random read/write speed of the other:

Disc 1
Ctl Prt PMP  Type   Description                 Capacity
  0   2   0  ATA    Crucial_CT250MX200SSD1      233 Gbytes
Disc 2
  0   2   0  ATA    Crucial_CT250MX200SSD1      233 Gbytes


          Disc 1 ARMX6  Disc 1 Pi IO FAST  Disc 2 Pi IO FAST
HD Read   63015  2113%  321254   10773%    353380   11850%
HD Write 127254  4184%  334042   10984%    340657   11202%
FS Read     619   299%  1443     697%        2481    1198%
FS Write    676   352%  1649     858%        3312    1725%

examining them they have different formats:

      10 : REM >TestDisc
      20 : :
      30 : DIM ptr% 128
      40 : *spool trtr
      50 : SYS "ADFS_DescribeDisc",":5",ptr%
      60 : PRINT "Sector size " ; ?ptr% ; " (9 :: 512)"
      61 : PRINT "Sec/track   " ; ptr%?1
      62 : PRINT "Heads       " ; ptr%?2
      63 : PRINT "Map flg bts " ; ptr%?4
      64 : PRINT "Bytes/mbit  " ; ptr%?5 ; "(10 :: 1024)"
      65 : PRINT "Znes in map " ; ptr%?9
      66 : PRINT "Disc size   " ;~ptr%!36; "-" ; RIGHT$("00000000"+STR$~(ptr%!16),8)
                  
          
 Disc 1          Disc 2
Sector size    9               9  (9 :: 512)
Sec/track    189             189
Heads         16              16
Map flg bts   21              19
Bytes/mbit    13              15   (10 :: 1024)
Znes in map   88              86
Disc size     3A-38B2E000     3A-38B2E000

So clearly I did something different when I formatted Disk 2 which means it is twice the speed on random reads and writes.

Now which of the HDForm parameters did I change?

Were drives formatted on different systems? See code in https://www.riscosopen.org/forum/forums/5/topics/15945?page=1#posts-111367

It’s the LFAU. If you have DiscKnight that can show it’s value.

Filecore seems to be fastest for small record sizes if the LFAU is 64K but the downside is more space is needed.

I have two SATA drives, both Crucial MX200 250GB

Are they both from the same supplier and purchased at the same time?

Chris has made the most likely explanation but don’t discount manufacturer changes,
the firmware on each drive or that old chestnut of real or cloned, i.e. duplicated, products traded as the same.

The drives were bought at around the same time. However I have taken a recently purchased drive and reformatted it (using the same shape) but instead of the recommended LFAU of 8192, I selected 32768. The downside is that a directory of 142 files counting 729kbytes occupies 5Mbytes on the drive rather than 1Mbyte: this means the disc capacity for lots of small files is significantly reduced (by about a factor of 4) but for large files is not affected. The upside is that random read and write speeds are doubled from 34% of RAMfs (1500kB/s) to 65% of RAMfs (3210 kB/s).

So a 240GB drive will only store the same number of small files as a 64GB drive. But will run at twice the speed for copying files. I think I can cope with that.

Now let’s see if NVMe drives exhibit the same pnenomenon…

Formatting a 512GB NVME drive using the new HDForm (in its uncompressed form, which seems to work) does show some differences:

FILECORE HARD DISC FORMATTER 2.77 (22-Feb-24)
Which filing system does your drive use (cursor keys select) ? NVMe

Format which drive (4 - 7) ? 4
Disc capacity    : 262144 Mbytes
Suggested shape  : 131072 cylinders, 128 heads and 32 sectors/track

Dismounting drive
This disc was last formatted using the non-standard disc shape :
          62660 Cylinders, 136 Heads and 63 Sectors/Track
          Parking cylinder 62661

Do you wish to retain this shape (Y/N) ? n

Heads ? 128   
Sectors per track ? 32   
Cylinders ? 131072   (Note: should be 131000)
Parking cylinder ? 62661   

A: no more changes to defect list
A,B,C or D ? a

Disc will be formatted as :
          131072 Cylinders, 128 Heads and 32 Sectors/Track
          Parking cylinder 62661

Format or just initialise the drive (F/I) ? I
Soak test the hard disc for defects (Long/Short/None) ? N
Do you wish this to be a bootable disc (Y/N) ? Y
Do you want long filenames on this disc (Y/N) ? Y
Large file allocation unit ? 8192   

Are you SURE you want to do this to drive NVMe::4 (Y/N) ? y

Bytes free &0000004000396000 =   268,439,128 Kbytes
Bytes used &FFFFFFFFFFC6A000 = 4,294,963,624 Kbytes

(Now test speed)
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                            275770    9068%
FS Read - Byte stream file in                               1542     744%
FS Write - Byte stream file out                             1543     803%

(Now re-format drive)

 FILECORE HARD DISC FORMATTER 2.77 (22-Feb-24)

Which filing system does your drive use (cursor keys select) ? NVMe

Format which drive (4 - 7) ? 4
  
Disc capacity    : 262144 Mbytes
Suggested shape  : 131072 cylinders, 128 heads and 32 sectors/track

Dismounting drive
This disc was last formatted using the non-standard disc shape :
          131000 Cylinders, 128 Heads and 32 Sectors/Track
          Parking cylinder 131001

Do you wish to retain this shape (Y/N) ? n

Heads ? 136   
Sectors per track ? 63   
Cylinders ? 62000   
Parking cylinder ? 131001   

A: no more changes to defect list
A,B,C or D ? a

Disc will be formatted as :
          62000 Cylinders, 136 Heads and 63 Sectors/Track
          Parking cylinder 131001

Format or just initialise the drive (F/I) ? I
Soak test the hard disc for defects (Long/Short/None) ? N
Do you wish this to be a bootable disc (Y/N) ? Y
Do you want long filenames on this disc (Y/N) ? Y
Large file allocation unit ? 32768   

Are you SURE you want to do this to drive NVMe::4 (Y/N) ? Y

Bytes free &0000003F53390000 =   265,604,672 Kbytes
Bytes used &0000000000340000 =         3,328 Kbytes

(now test speed again)
R-Comp NVFS:
RISCOSmark 2.06 (29-Mar-2016) by Richard Spencer 2003
Filing system: NVFS:HardDisc4.$.SpeedTests
HD Read - Block load 8MB file                              51200    1716%
HD Write - Block save 8MB file                            192752    6338%
FS Read - Byte stream file in                               1579     762%
FS Write - Byte stream file out                             3583    1866%

RISC OS Bits NVMeFS:
RISCOSmark 2.06 (29-Mar-2016) by Richard Spencer 2003
Filing system: NVMe:HardDisc4.$.SpeedTests
HD Read - Block load 8MB file                             194661    6527%
HD Write - Block save 8MB file                            281098    9243%
FS Read - Byte stream file in                               2937    1418%
FS Write - Byte stream file out                             2967    1545%

As SystemDisc does not yet handle NVMeFS, put drive into USB caddy to create the ‘Loader’ partition (and the partition table).

@Chris. Sometime ago I used the newly released raspberry pi 3 model b+ to hook up two Iyonix discs and copy the files to two adfs sd cards and two fat32 sd cards each 120gb. What I found is that the copies could be sped up by changing the cluster or block size as you did. However, I ran into incompatibilities. The copy would fail in someway if I didn’t use the same disc cluster size on the SD card destination as the Iyonix discs. The copy got a bit further then fail. The only way to get a full copy was to use a very specific version of hform and format the sd cards on my Iyonix. I never got a full copy to fat32 but that was just an extra backup in case something happened to all my riscos machines. The copy failed possibly in a way that locked up my machine.

Later when I was using usb flash drives, for maximum compatibility with newer versions of the OS and with the older Iyonix OS I had to format all my drives with a certain version of hform on my Iyonix or the flash drive when copying files from a newer machine would lock the newer OS up. So basically my iyonix was my main machine. I transferred my programs to a flash drive with a specific format, work on programs on a riscos laptop or three and then transfer back to Iyonix. I donated my Iyonix so am probably no longer able to create what seems like compatible flash drives and I can’t say exactly what I did.

If anyone has experienced this it’d be good to know what version of hform, os, cluster size can be used to format media that can produce media that just works on all versions of riscos with thousands and thousands of little files that riscos mostly generates.

If you mean the LFAU, please don’t use “cluster size” as it confuses things with FAT.

If I try to format an nvme drive with the latest !HForm I get the error,

NULL.POINTER.DEREFERENCE at line 945 after selecting the drive number. !HForm then quits.

I get the same here!

The drive is a Patriot P300 256GB.

I had to use a USB adapter to format an nvme drive.

With the drive in a caddy connected to a USB socket on the Waveshare IO board only SDFS and SCSI format options are offered, not NVMe. A PCIe USB card might be more appropriate, but I have not got one.

I’m a bit stuck.

Time: Sat Mar  2 16:45:50 2024
Location: Offset 00004f34 in module FileSwitch
Current Wimp task: Unknown
Last app to start: BASIC -quit <HForm$Dir>.!RunImage

R0  = fa207ec0 R1  = 00000000 R2  = 00000000 R3  = fc054800
R4  = 80000113 R5  = 00000080 R6  = fc03c9bc R7  = fc0311e4
R8  = fc031148 R9  = fc045b64 R10 = fc0179bc R11 = fa207f00
R12 = 20000394 R13 = fa207e8c R14 = fc05a160 R15 = fc0571fc
DFAR = 00000000  Mode SVC32  Flags NzCv if   PSR = a0000113

fc0571b4 : e28dd00c : ADD     R13,R13,#&0C       ; =12
fc0571b8 : e8bd83ff : LDMIA   R13!,{R0-R9,PC}
fc0571bc : e28d0000 : ADD     R0,R13,#0
fc0571c0 : ebfffdf8 : BL      &FC0569A8
fc0571c4 : e1a00007 : MOV     R0,R7
fc0571c8 : ebfff455 : BL      &FC054324
fc0571cc : e59d0024 : LDR     R0,[R13,#36]
fc0571d0 : ebfff453 : BL      &FC054324
fc0571d4 : e1a01000 : MOV     R1,R0
fc0571d8 : e59d0008 : LDR     R0,[R13,#8]
fc0571dc : ebfff450 : BL      &FC054324
fc0571e0 : e58d100c : STR     R1,[R13,#12]
fc0571e4 : e28dd00c : ADD     R13,R13,#&0C       ; =12
fc0571e8 : e8bd83ff : LDMIA   R13!,{R0-R9,PC}
fc0571ec : e92d407d : STMDB   R13!,{R0,R2-R6,R14}
fc0571f0 : e24b0040 : SUB     R0,R11,#&40        ; ="@"
fc0571f4 * e5d1e000 * LDRB    R14,[R1,#0]
fc0571f8 : e35e007f : CMP     R14,#&7F           ; =127
fc0571fc : 135e0020 : CMPNE   R14,#&20           ; =" "
fc057200 : 8a000002 : BHI     &FC057210
fc057204 : e3150001 : TST     R5,#1
fc057208 : 028f1044 : ADREQ   R1,&FC057254
fc05720c : 128f1042 : ADRNE   R1,&FC057256
fc057210 : e24b4038 : SUB     R4,R11,#&38        ; ="8"
fc057214 : e3855e11 : ORR     R5,R5,#&0110       ; =272
fc057218 : e24b6030 : SUB     R6,R11,#&30        ; ="0"
fc05721c : ebffff29 : BL      &FC056EC8
fc057220 : 68bd807d : LDMVSIA R13!,{R0,R2-R6,PC}
fc057224 : e92d0026 : STMDB   R13!,{R1,R2,R5}
fc057228 : e51b1040 : LDR     R1,[R11,#-64]
fc05722c : e51b2038 : LDR     R2,[R11,#-56]
fc057230 : e59d501c : LDR     R5,[R13,#28]

R15 = fc0571fc = FileSwitch +4f3c
R14_svc = fc05a160 = FileSwitch +7ea0
          Function call to fc0571ec = FileSwitch +4f2c

SVC stack:
fa207e8c : 00000037 :                                            - R0
fa207e90 : 00000000 :                                            | R2
fa207e94 : fc054800 : - Return to fc054800?                      | R3
         :          : | = FileSwitch +2540                       | 
fa207e98 : 80000113 :                                            | R4
fa207e9c : 00000080 :                                            | R5
fa207ea0 : fc03c9bc : - fc03c298 return to fc03c9bc?             | R6
         :          : | fc03c298 = UtilityModule +1bc90          | 
         :          : | fc03c9bc = UtilityModule +1c3b4          | 
fa207ea4 : fc05a160 :                                            | R14: fc05a160 (ASM call to fc0571ec)
         :          :                                            | fc05a160 = FileSwitch +7ea0
         :          :                                            | fc0571ec = FileSwitch +4f2c
fa207ea8 : 00000000 :
fa207eac : fc196d20 :
fa207eb0 : fa20021c :
fa207eb4 : fa207f28 :
fa207eb8 : 000791c5 :
fa207ebc : fa207f28 :
fa207ec0 : 20000113 :
fa207ec4 : 00000007 :
fa207ec8 : 00000080 :
fa207ecc : ffffffff :
fa207ed0 : 00000000 :
fa207ed4 : 00000000 :
fa207ed8 : 00008700 :
fa207edc : fc017760 : - R7
fa207ee0 : 00000000 : | R11
fa207ee4 : fa207ef0 : | R12
fa207ee8 : fc3ffb30 : | R14: fc3ffb30
         :          : | = EtherUSB +4d4
fa207eec : fc405018 : | APCS function: fc405010
         :          : | = EtherUSB +59b4
fa207ef0 : 00000037 : | R0 \ CMHG veneer _kernel_swi_regs?
fa207ef4 : 00000000 : | R1 |
fa207ef8 : 00000013 : | R2 |
fa207efc : fc01792c : | R3 |
fa207f00 : 00000037 : | R4 |
fa207f04 : 00000000 : | R5 |
fa207f08 : 00000013 : | R6 |
fa207f0c : fc01792c : | R7 |
fa207f10 : 80000113 : | R8 |
fa207f14 : fc03d90c : | R14: fc03d90c (ASM call to fc03da40)
         :          : | fc03d90c = UtilityModule +1d304
         :          : | fc03da40 = UtilityModule +1d438
fa207f18 : fc03c9bc : - fc03c298 return to fc03c9bc?
         :          : | fc03c298 = UtilityModule +1bc90
         :          : | fc03c9bc = UtilityModule +1c3b4
fa207f1c : fc0179bc :
fa207f20 : 60000113 :
fa207f24 : fc0107e0 : - fc01773c return to fc0107e0?
         :          : | fc01773c = +1773c in the Kernel
         :          : | fc0107e0 = +107e0 in the Kernel
fa207f28 : 60000113 : - PSR?
fa207f2c : 00020029 : | SWI XOS_FSControl
fa207f30 : fc1b4f2c : | R14: fc1b4f2c
         :          : | = SharedCLibrary +329b4
fa207f34 : fa20021c : | R10
fa207f38 : fa207fb8 : | R11
fa207f3c : 00020029 : | R12
fa207f40 : fa207f60 : - R2
fa207f44 : 00000000 : | R4
fa207f48 : fa207fbc : | R5
fa207f4c : 00000000 : | R6
fa207f50 : 00000000 : | R7
fa207f54 : 20000113 : | R8
fa207f58 : 00000000 : | R9
fa207f5c : 201eec10 : | R14: 201eec10 (ASM call to fc1b4f14)
         :          : | 201eec10 = NVMeFS +771c
         :          : | = swi_handler +114
         :          : | fc1b4f14 = SharedCLibrary +3299c
fa207f60 : 00000037 :
fa207f64 : 00000000 :
fa207f68 : 00000013 :
fa207f6c : fc01792c :
fa207f70 : 80000113 :
fa207f74 : fc03d90c : - R14: fc03d90c (ASM call to fc03da40)
         :          : | fc03d90c = UtilityModule +1d304
         :          : | fc03da40 = UtilityModule +1d438
fa207f78 : fc03c9bc : - fc03c298 return to fc03c9bc?
         :          : | fc03c298 = UtilityModule +1bc90
         :          : | fc03c9bc = UtilityModule +1c3b4
fa207f7c : fc0311e4 : - fc03fc20 return to fc0311e4?
         :          : | fc03fc20 = UtilityModule +1f618
         :          : | fc0311e4 = UtilityModule +10bdc
fa207f80 : fc031148 : - Return to fc031148?
         :          : | = UtilityModule +10b40
fa207f84 : fc045b64 : - fc0310f8 return to fc045b64?
         :          : | fc0310f8 = UtilityModule +10af0
         :          : | fc045b64 = UtilityModule +2555c
fa207f88 : 00000020 : - R0
fa207f8c : fa207fbc : | R1
fa207f90 : 30003be4 : | R2
fa207f94 : 2414e02c : | R4
fa207f98 : 00000388 : | R5
fa207f9c : 00000000 : | R6
fa207fa0 : 00000000 : | R7
fa207fa4 : 20000113 : | R8
fa207fa8 : 00000000 : | R9
fa207fac : 00000000 : | R11
fa207fb0 : fa207fbc : | R12
fa207fb4 : 201e78b0 : | R14: 201e78b0
         :          : | = NVMeFS +3bc
fa207fb8 : 201eeb08 : | APCS function: 201eeb00
         :          : | = NVMeFS +760c
         :          : | = swi_handler +4
fa207fbc : 00000004 : | R0 \ CMHG veneer _kernel_swi_regs?
fa207fc0 : 00000000 : | R1 |
fa207fc4 : 00000000 : | R2 |
fa207fc8 : 00000000 : | R3 |
fa207fcc : 00000000 : | R4 |
fa207fd0 : 00000000 : | R5 |
fa207fd4 : 00000000 : | R6 |
fa207fd8 : 00000000 : | R7 |
fa207fdc : 00000000 : | R8 |
fa207fe0 : 00000000 : | R9 /
fa207fe4 : fc0106b8 : - fc01773c return to fc0106b8?
         :          : | fc01773c = +1773c in the Kernel
         :          : | fc0106b8 = +106b8 in the Kernel
fa207fe8 : 60000110 : - PSR?
fa207fec : 0005a620 : | SWI NVMeFS_FreeOp
fa207ff0 : 000086d8 : | R14: 000086d8
         :          : | = +6d8 in application memory
fa207ff4 : 000000b8 : | R10
fa207ff8 : 000086d4 : | R11
fa207ffc : 0000a6a8 : | R12

R14_usr = fc1c18f8 = BASIC +9138

USR stack:
000a7fc0 : 00000008 :
000a7fc4 : 0005a620 :
000a7fc8 : 000000f2 :
000a7fcc : 00008f73 :
000a7fd0 : 00008f72 :
000a7fd4 : 00000000 :
000a7fd8 : 00000000 :
000a7fdc : 00008f00 :
000a7fe0 : 00008f00 :
000a7fe4 : 37020bc4 :
000a7fe8 : 00000000 :
000a7fec : 00000000 :
000a7ff0 : fc1bfc54 : - fc1b9874 return to fc1bfc54?
         :          : | fc1b9874 = BASIC +10b4
         :          : | fc1bfc54 = BASIC +7494
000a7ff4 : ff0de13a :
000a7ff8 : 00008700 :
000a7ffc : 00000002 :
000a8000 : 00000000 :
000a8004 : 00000000 :
000a8008 : 00000000 :
000a800c :

I’m a bit stuck.

With a bit of weirdness I have unstuck myself. In order to better diagnose the crunched BASIC in HForm, from a local build, the uncrunched BASIC was used and would you believe it, it worked!! (Something is nagging me. Have I seen this already reported?)

Not overclocked, 1500MHz.

Test                                                   Benchmark
Processor - Looped instructions (cache)                  3493856    1964%
HD Read - Block load 8MB file                             178439    5983%
HD Write - Block save 8MB file                            262462    8630%
FS Read - Byte stream file in                               1291     623%
FS Write - Byte stream file out                             1294     673%

the uncrunched BASIC was used and would you believe it, it worked!!

Oh I do believe you very much, crunching BBC BASIC is a bad idea (given the lack of proper local variables). May have worked for small or simple programs where it was relatively easy to keep track of the state, but it’s a dangerous activity to do on complex programs. Certainly I won’t do it on HForm (the one I use is always uncrunched).

Glad to see you are out of troubles! :)