RPCEmu 0.9.5

A new version of RPCEmu is available, 0.9.5

http://www.marutan.net/rpcemu/

Changes in this build

- Mouse

Implement mouse-wheel support to scroll window contents. Based upon work by Daniel Clarke for Arcem.

- Floppy Disc

Add the ability to create blank, pre formatted, floppy disc images from the UI.

Restore the ability to format blank files as disc images (a regression in 0.9.4)

- IDE Hard Discs

Support LBA (Logical Block Addressing) hard disc image files, based upon work by Phil Morris.

Correctly detect and work around hard drive images that have the off by 512 byte (1 sector) bug and no longer create new hard drive images that have that issue when formatting new hard discs.

- Networking

Refactor and refine the network driver

Use up to date header files for RISC OS libraries

Correct the usage of podule interrupts, allowing other podules to also handle them.

- Timing

Improve timer accuracy of ‘intermediate’ values. Based upon work by Jeffrey Lee

- HostFS

Add support for high-resolution timestamps for HostFS on 64-bit Linux (this was already available on Windows)

Matthew Howkins
Peter Howkins

Congratulation! Better late than never.
We (Cloverleaf RISC OS Project) implemented the mouse-wheel support already about 3 years ago and our version also has clipboard support between the host OS and RISC OS.
You could have taken over our code and still can(!) for the clipboard support as it needs a new module in the RISC OS part.
But maybe it is a no-go to use code that was programmed by Germans….

RISC OS Cloverleaf Github

Thank you for this great update.

Network by DHCP initially didn’t work. After having set it up manually, I got a reliable access to internet. While I still got internet after having tried DHCP again, it only worked for one minute, then the program froze. A manual connections seems more stable. This is with RPCemu 0.9.5, StrongArm, 256 MB memory and 2 MB VRAM on the latest Windows 11 Home.

A question that I wanted to ask long before: is it normal that NetSurf takes nearly 3 minutes to fire up?

A question that I wanted to ask long before: is it normal that NetSurf takes nearly 3 minutes to fire up?

IIRC Netsurf does a lot of font caching, so the more fonts you have visible to the app, the longer it takes to startup

IIRC Netsurf does a lot of font caching, so the more fonts you have visible to the app, the longer it takes to startup

That is correct. Activating the ROM fonts only, considerably reduces loading time. But on my real computer (4té2), NetSurf saves the font cache. On RPCemu, it scans all the fonts again at every new start. Or do I miss something?

On RPCemu, it scans all the fonts again at every new start. Or do I miss something?

A difference in the config of the two copies of NetSurf perhaps? If the RPCEmu copy is using an ephemeral location for its cache – like RAMDisc – then NetSurf has to rebuild the font cache every time.
Using Memphis would remove the ephemeral aspect

NetSurf has to rebuild the font cache every time.

This.
The font cache should only be created the one time (and maybe if the available fonts change).
If it keeps doing it, something is wrong.

I think the cache is in !Boot.Resources.!Scrap.ScrapDirs.ScrapDir.RUfl (or thereabouts).

If you put !Scrap in RAMdisc, or clear it at shutdown, you’ll need to think of a way to preserve the RUfl cache file.

I think the cache is in Scrap.ScrapDirs.ScrapDir.RUfl (or thereabouts).

It is exactly there, both on my 4té2 as on this HostFS. It’s even the same cache. Nevertheless, where as NetSurf on the 4té2 scans the fonts only once, on RPCemu it rebuilds the cache every time.

By the way, I can’t help but thinking that <Boot>.Recources.!Cache would be far more logic to store the font cache…

NetSurf’s font scanning is the wrong solution, doesn’t scale, and dies when you have a lot of fonts. It should be replaced with a simple configuration file to declare a Unicode font stack.

I am also having problems with networking using 0.9.5 on Win11home.

Using a RO5.30 ROM, and a brand new HardDisc4, all seems to work well after setting FileSystem to use HostFS.
However, with StrongArm and 128MB configured, if I then change Networking to use NAT, the reboot immediately gives:

Error: DataAbort: Abort on data transfer at &FC305234 (Error number &00000002)

and *where gives:

Address &FC30523C is at offset &0001828 in module 'Internet'

*Desktop will start it, and Edit, Draw and Paint all will start.
But a click on HostFS gives:

Abort on instruction fetch at &20E6F68

though Cancel then displays the directories.
*where then gives:

Address &20E66F6C is at offset &006E6F6C in dynamic area 'Module area'

Anyone else seen this?

Note that I have used many versions of RISC OS with 0.9.4 and NAT without these problems.

Anyone else seen this?

256MB, StrongARM, starts up here, with OS5.31, and NAT networking works.

@David: If your 5.31 starts with NAT and usable networking, then perhaps I have done/not done something here.
I will try 5.31 ROM here.

I should add that 128MB, StrongARM, is a show stopper, the ROM initialisation errors with a “Bad expansion card identifier” in ScrollWheel. EtherRPCEm also fails similarly.

If you put !Scrap in RAMdisc, or clear it at shutdown, you’ll need to think of a way to preserve the RUfl cache file.

As I said… “Using Memphis would remove the ephemeral aspect.” :)

Description:
Memphis is a replacement RAM-based filing system (RAM disc) that uses the System Sprite area rather than the RAM disc area. It provides:

• A dynamically resizeable RAMdisc
• Up to 30 character file names
• A new storage scheme that can use a slave filing system instead of the Sprite area. This is useful if you need to have long file names or many
  files in a directory. The files are also compressed using Acorn’s Squash module built into the RISC OS 3 ROM.

Yup – have just seen those Bad Id problems with 5.31 and 128MB – followed by the abort I saw with 5.30 and 128MB.
But I also agree that changing to the (non-recommended) 256MB works with 5.31, and 5.30.
I have also checked my 0.9.4 installs, and they had 256MB … but fail with 128MB.

So this is not a new problem. NAT seems to need 256MB, and fail with 128MB.

Nevertheless, where as NetSurf on the 4té2 scans the fonts only once, on RPCemu it rebuilds the cache every time.

If it helps at all, the cache is rebuilt every time on my real Risc PC (RISC OS 4.39) whereas it only happens once on the RPi 4B (RISC OS 5.31). On the Risc PC the cache is stored in !Scrap.ScrapDirs.IDdisabled.RUfl.