RISC OS Pico RamDisc size

Hi.
With *Configure RamFSSize I can’t create a disc bigger, than 0.5 Mb.
The desktop’s !Configure application would cope with it, but Pico has no desktop. How to create a big RamDisc?
Thanks in advance.

How to create a big RamDisc

You want *ChangeDynamicArea not the configure command

Works. Thank you, Mike.
I read the help to that command (your link). Looking at it you might think that the suffix ‘K’ (kilobytes) at the end is optional. But (here’s a surprise!), command not works without. System operation becomes broken after that until reset (command’s ‘not found’ and the like).
In the presence of ‘K’, everything is OK.

At a guess, it’ll assume bytes if you don’t include the “k”, which will of course make for a very small RAM disc :)

I thought that units are pages. But in the matter, the units do not matter ;) The system does not work as it should, or ‘Help’ lying… Maybe, I do not understand something…
The main thing is that I can create RAM discs. That’s enough for me in this case.

Yes, it looks like in the absence of a K, M, or G(!) it will assume bytes.

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/Utility?rev=4.6.2.8#l1095

I have amended the help page to indicate this.

Is there any chance of increasing the value of the RAMdisc/Font size to reflect on the usual amount of ram fitted these days?

I can’t imagine a scenario where anyone would really specify a byte-size RAM disc, so perhaps altering it to assume kilobytes would be better. Just in case it’s possible someone does want to specify a size in bytes, a “B”/“b” option could be added. Something like (typed straight into the forum, therefore untested – and by someone who doesn’t really do ARM code anyway):

1102        LDRB    R3,[R1]
1103        Uppercase R3,R14         
1104        TEQ     R3,"B"           ; if the terminator is "b" or "B"
1105        ADDEQ   R1,R1,#1         ; increment R1
1106        MOVNE   R2,R2,LSL #10    ; and if not, multiply by 1,024
1107                                 ; i.e. Assume kilobytes by default
1109        TEQ     R3,#"K"          ; if terminator is "k" or "K"
1110        ADDEQ   R1,R1,#1         ; increment [R1]
1111        TEQ     R3,#"M"          ; if terminator is "m" or "M"
1112        ADDEQ   R1,R1,#1         ; increment [R1]
1113        MOVEQ   R2,R2,LSL #10    ; and multiply by a further 1,024
1114                                 ; (we've already multiplied by 1,024 by default)
1115        TEQ     R3,#"G"          ; if terminator is "g" or "G"
1116        ADDEQ   R1,R1,#1         ; increment [R1]
1117        MOVEQ   R2,R2,LSL #20    ; and multiply by a further 1,048,576
1118                                 ; (we've already multiplied by 1,024 by default)

It’s a few more instructions due to the additional check, and it means two multiplies for megabytes and gigabytes, which is a tiny drop in efficiency for those two cases, but that’s offset by having a more sensible starting assumption.

Afterthought: Somebody somewhere will be specifying a RAM disc of 262144 bytes (or whatever) rather than 256K, relying on the bytes assumption. Scrap that, then.

Edit: Afterthought #2: The above would also affect the other things set by ChangeDynamicArea – the RMA and Screen, Sprite and Font areas. :/

Edit 2: Best to include the LSL on that last MOVEQ, really. ;)

I can’t imagine a scenario where anyone would really specify a byte-size RAM disc, so perhaps altering it to assume kilobytes would be better.

I think the question was referring to the configure commands (not changedynamicarea) which are computed in pages, but the page size is much smaller now than with memc, so maybe rounding to the nearest logarithm would be more useful? eg. 4mb machine has 64 times finer granularity than a 256mb one

Perhaps granularity must depend on the size of the disc, rather than RAM.
For ‘ChangeDynamicArea -RamFSSize’ I tried to enter a different values (in bytes). These values are rounded up to a multiple of 4096 Bytes.
The smallest value (that allows the program) is 4097. This creates a disc with the following parameters: Bytes free: 4,096. Bytes used: 4,096.
The input value of 4096 (and less) leads to silent disruption of the system. Nothing, neither the program nor a help page not warn about it. Maybe, something must be more verbose.

I wonder if, for the values less than 4096, RAMFS is still trying to create the filesystem and overwriting the end of the allocated block, which could certainly cause memory corruption and potential problems.

It certainly sounds like *ChangeDynamicArea needs changing to give an error if the size is too small (unless this has been fixed since Pico was released; I’m not near my RISC OS machine to check).