CRamFS

Merry christmas and a happy new year to all!

I’ve just put a new version of RAMFS on the gitlab. You can look at it here. It’s the same as the old one, but written in C.

For those unfamiliar with how it works, RAMFS has three ingredients:

1. A dynamic area, which may or may not be a physical memory pool (PMP).
2. A block device driver that uses dynamic areas as it medium.
3. A routine that attempts to FileCore format discs of arbitrary size.

The first is handled by c.pmp, the second by c.ops, and the third by c.disc_record.

Sounds interesting.

Unfortunately, I can’t see it with Netsurf.

I’ve just put a new version of RAMFS on the gitlab.

Brilliant!!!

I have it running as a softload on the Titanium and RPi4 and its looking good. A full rom build on this new CRAMFS Disc on the Titanium was just fine, which as a test is at least a bit of a work out.

(A Pi 5M Long Descriptor ROM build with RAMFS-CRamfs built with 1.43K spare.)

Sounds interesting.

Unfortunately, I can’t see it with Netsurf.

Here’s a link to download a zip of the source directly. You’ll probably have to set a few filetypes though as it’s not zipped up on RISC OS.

It doesn’t have the built module on gitlab yet.

Sounds good … but is there a pre-built module anywhere?
A couple of questions …
- Can it automatically re-size?
- What is performance vs current version?

Here’s a link to download a zip of the source directly. You’ll probably have to set a few filetypes though as it’s not zipped up on RISC OS.

A better option is to download the bz2 version and then extract it using UnTarBZ2, which will preserve the filetypes. This works for anything in GitLab.

Here’s a link to download a zip of the source directly. You’ll probably have to set a few filetypes though as it’s not zipped up on RISC OS.

Extracting using the command line unzip available via PackMan will retain the file types.

Brilliant, Julie, and thank you very much for your efforts!

I took the bz2 route, as suggested by Chris Mahoney. I unpacked it and built the RAM version. It certainly appears to work on my Pi here.

I wish you a very Happy New Year!

Now, does this provide a worthwhile stepping stone to any other filing system in C?

Well done Julie, though I think you forgot to remove the s.BlockMove source.

A routine that attempts to FileCore format discs of arbitrary size.

Personally, I think that modules support for FileCore, FAT, etc should provide a Format SWI so that different applications initializing hadrdiscs, ram disks, image files, etc don’t have to reinvent the wheel.

Sounds good … but is there a pre-built module anywhere?
A couple of questions …
- Can it automatically re-size?
- What is performance vs current version?

gitlab doesn’t build it yet – I’ll sort that in due course. I need to setup some configuration files, luckily I wrote a wiki page on how to do that a year ago now!

I’m afraid same as usual, to re-size the disc it has to be empty first.

I’ve found the speed on Rasperry Pi 3B+ to be similar to current version (m1time gives a different answer each run so you have to take an average).

On RPCEmu copying lots of files like the OS source takes a while longer, maybe 20%. I left s.BlockMove in in case that is found to be faster than the current memmove from SharedCLibrary; but I really don’t know where the bottleneck is.

Now, does this provide a worthwhile stepping stone to any other filing system in C?

It might well be a modest help for the Filing system improvements step 2 and 3 bounties.

ROM builds are the test of choice here and are slightly slower on CRAMFS compared to the assembler RAMFS. From a Titanium :-

            RAMFS    CRAMFS
UnTarBZ2      20s       22s
Builder     3m54s     4m01s

Some romarks which show a slower HD Read.

RISCOSmark 1.01 (14 May 2003)
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

Tested at Sat,01 Jan 2022.07:56:34
Machine type HAL
MOS Utilities 5.29 (07 Aug 2021)
Version number: RISC OS 5.29
Build date    : Thu,30 Dec 2021.04:49:59
Platform      : Titanium
Vectors at FFFF0000 : Size 256bytes
Filing system: RAM:RamDisc0.$
Graphics Resoloution: 1920x1200,16M colours

Test                                                RAMFS               CRAMFS
Processor - Looped instructions (cache)       3837240    2157%     3836905    2157%
HD Read - Block load 1MB file                  179453    6017%      118621    3977%
HD Write - Block save 1MB file                 858740   28238%      866851   28505%
FS Read - Byte stream file in                    3635    1756%        3606    1742%
FS Write - Byte stream file out                  3766    1961%        3758    1957%

Another test saving and loading a 20MB file also showed a slower read.

       RAMFS     CRAMFS
Save   500MB/s   670MB/s
Load   167MB/s   111MB/s

OTOH more easily maintained code more ready for the upcoming 64bit era.

Brilliant!

Happy New Year.

Great job Julie!

works here as well as module.

Happy new year :)

I asked gitlab to build the module, but there was an error. I think I might need to put s.RAMFSErr back in. Not sure.

Load   167MB/s   111MB/s

Does DDE C implement PLD or have a command to manually hint? Read performance could probably be improved with such a trivial feature considering all modern ARM support it.

The only hint in the gitlab log seems to be “make¹: * No rule to make target ‘HelpText’, needed by ‘TokHelpSrc.s’.”

Would somone with the right computer (I believe Iyonix, OMAP3 or iMx6) run FIQProf on this for me?

That might give a clue as to which bits to try and speed up.

Where do we get FIQProf?

From Jeffrey.

From an iMx6:

*fiqprof
TimerNumber: 1
TimerFreq: 25000
DASize: 16
DAName: FIQProf
Registers: &18000
PerfCounters: 
Not Iyonix
Removing old dynamic area 288
Timer 1 has granularity 66000000, max period -1
Period of 2640 will result in 25000Hz interrupt
Timer confirms new period 2640, frequency 25000
Created 16MB dynamic area 288 with base &54933000
Initialising buffer...
Buffer will hold approx 83 seconds of data
Compiling module...
Code is 104 bytes long, write ptr will be at &68
Profiling enabled!
Use *FIQProfSave <filename> to save results to disc
*

Great. Now we need to work out how to use this. Are you able to build the RamFS module? We’ll need a GPA file.

Does DDE C implement PLD or have a command to manually hint? Read performance could probably be improved with such a trivial feature considering all modern ARM support it.

PLD won’t help for reading from RAMFS; the dynamic area is non-cacheable (except on StrongARM).

Are you able to build the RamFS module? We’ll need a GPA file.

Ideally you’d also build your own ROM, to get function & file/line granularity on ROM locations. Otherwise you’ll be limited to module-level granularity. (profanal can load the full ROM symbols via the loadrom command)

It might be nice to be able to use more than one RAM disc at a time (RamDisc0,
RamDisc1,…).

How would this look at the command line? Let’s have a new command *SizeDisc.

Then you’d go

*RAM:SizeDisc 0 4M

which would do the same as

*ChangeDynamicArea -RAMFSSize 4M

But there’d be three other discs, which you can setup by

*RAM:SizeDisc 1 16M
*RAM:SizeDisc 2 32M
*RAM:SizeDisc 3 1G

As with the existing RamDisc0, if you try to resize a disc containing files,
you will get an error, and must wipe the disc first.

I think it would also make sense for the SizeDisc command to accept either a disc number or a disc name, e.g.:

*RAM:SizeDisc Bob 4M

Disc names will make things a lot easier to keep track of, especially if programs gain the ability to create/manage their own RAM discs.

When creating a named disc, it can probably just use the first free disc number.

We’ll need to tweak the kernel.

Firstly, at the moment the DA handler checks whether “ram:$.*” exists. If the
current drive isn’t zero that might give the wrong answer, so we should make
that “ram::0.$.*”.

Secondly, *ChangeDynamicArea -RamFSSize re-initialises the RamFS module, so the
other three discs (:1, :2, :3) would vanish. I propose that instead it checks if
RamFS is active (using OS_Module 18 or 19); if not active, it carries on as
normal. If active, it doesn’t RMReInit, but instead calls a further new command

*RAM:Layout 0

This would reinitialise just that disc, leaving the others alone.

I think it would also make sense for the SizeDisc command to accept either a
disc number or a disc name

That does make sense! RamFS doesn’t know the names of its discs, so I’d ask
FileCore for those to work out which DA it is.

Here’s what I’m not sure about. At the moment, if RamFSSize is 0K then the RamFS
module is absent, so you can’t use SizeDisc at all. We could have RamFS always
start up, but then it would start affecting the RAMFSFiler icon, and I really
wanted to confine these changes to the command-line, at least to start with.

I’ve upgraded BuildSys here to the latest version (7.71) and I still don’t see any of the errors compiling that come up on gitlab, so I don’t know what’s different about it.