CMOS on RO4.02 does not work?

I just installed RO4.2 on the RPCEmu (Ubuntu, running on Rpi-4 ARM610- and and SA-emulations), and found out,
that no settings gets saved (Keybourd and sound).

Can some kind soul tell me, what i’m doing wrong?

If RPCEmu crashes or stiffs on shutdown or reset then it does so before writing its settings. Either try to avoid the crash or try with the reduce CPU usage option disabled. Sometimes directly editing rpc.cfg is required.

No, mo crash on RPCEmu, all working fine, except, that the settings does not survive resets, or new starts.

I’m sure, i’m doing something wrong, but i don’t know what.

Troubleshooting: RISC OS won’t boot properly, or behaves oddly

As on a real RISC OS machine, it uses the CMOS RAM to hold important system settings. In the emulator these are stored in the cmos.ram file. If you use the emulator for the first time, or change the version of RISC OS you’re running, you need to reset the CMOS. To do this, start the emulator while holding down the Delete key. Just as it would on a real machine, it resets the CMOS to factory settings for the version of RISC OS you happen to be running.

Ref: https://www.riscos.info/index.php/RPCEmu_Linux_Guide (deprecated, but there could be a useful nugget at the end of the article, see above.)

Not a fix, but to compare with maybe, I compiled/installed RPCEmu and used nightly builds of RISC OS 5 and Harddisc4 yesterday. This setup doesn’t allow ASFS::4.$ but I was able to configure Hostfs and boot/use that as the drive, so the cmos file thing seems to have worked OK without resetting to factory.

A lengthy exercise getting this far, The Windows7 laptop needed restoring after my first attempt at making a dual boot. Have made the Windows recovery disc this time, but now use the sdcard with grub4dos to boot the Peppermint (Ubuntu) ext4 partition. This leaves Windows stuff alone and the laptop bios can be told to boot the sdcard. The grub4dos has an easily configured menu.lst file to adjust the booting parameters and order of systems to boot.
Booting from the sdcard makes it hd0, and the main harddrive partitions become hd1,x but it is working, and I could rebuild Windows now without drama.
The only reason I need Windows is to update my Navman, I see that Windows7 updates are finishing soon, that will be a good thing, if it can just do the job without the windows carryon.

BTW the rpcemu window shows 50 MIPs, is that reasonable? (early i5 processor)

We do have a build of 0.9.2 with 4GB HostFS file size patch and MacOS patches from user contributions on the RPCEmu mailing list underway, with source for Linux along with Windows and macOS builds plus a RISC OS 5.24 (hopefully soon, 5.28) ROM and disc image. It’s an overdue update to the USB stick distro.

We are almost there, but have hit some issues with mouse pointers misbehaving in full screen mode on the Mac and Linux variants. Once that’s done, we’ll be pretty close to releasing it.

I see that Windows7 updates are finishing soon,

Unless you have extended support the word is “finished” rather than “finishing soon”

In response to the OP rather than the thread. Could you be having trouble with file permissions / ownership? I have used the the same HOSTFS folder for years, obviously there’s been changes but when I change PC’s or OS I simply copy it over. When I do this sometimes nothing works and I have to set the file ownership. Try running rpcemu as root. (sudo ./rpcemu) if that works and saves your cmos file then you need to change file ownership to your own username. Entering (sudo chown -R username *) from inside the RPCEmu directory should set all files and subdirectories to our ownership. The parentheses are only to separate the command from the text. Hope this helps.

I noticed problems saving settings while getting the (new) NAT dhcp networking set up.
I installed the Ether module in !System so that could be found, but reading later, it sounds like this should be OK in the default Netroms location.
Edit: and yes, it is not necessary to have it in System.
I think by not letting RISC OS reboot the normal way, and shutting RPCEmu down from Linux was the turning point to successfully retaining changes, particularly the RPCEmu network settings at the top of the window were getting lost.

Can anyone tell me if the created RAMFS::Ramdisc actually uses the host machine ram, and why 256MB is not recommended but 128MB is?

if the created RAMFS::Ramdisc actually uses the host machine ram

It uses the emulated RAM, so if RPCEmu has 64MB configured the maximum RAM disc size is approximately 60MB.

why 256MB is not recommended but 128MB is?

There are numerous admonitions of the form “don’t use 256MB with RISC OS 3.5/3.6/3.7”. For example:

• The maximum RAM for the A7000 was 128MB, and the vast majority of Risc PCs never had 256MB fitted. As a result, fewer applications were thoroughly tested with 256MB.
• Two applications that won’t work with 256MB are ArtWorks v1 and Fresco.

RISC OS 5 is – or could be – a different matter. I did try 256MB RAM with RPCEmu 0.9.1 and it seemed to work for the handful of applications I tried, but my tests were superficial at best.

I wasn’t sure what you meant by ‘emulated RAM’ but running linux Htop while configuring RAM let me see what happens.
When RPCEmu starts, it takes a chunk of ram from the Host computer depending on the size allocated in the pull down settings. The allocation is also the size limit when setting up RAMFS when in RISC OS.
It looks like 256MB would be the max for RAMFS and MemphisFS combined if /it/ was used/needed.
By using scrap in RAM, I guess 256MB would be available for the unixlib /temp, this could help with the native GCC compiler speed, or at least move the temp read/writes from the harddisk to memory.