Cloverleaf Kickstarter includes a pledge for RPCEmu

Great news! Are the text changes likely to work with Mac and Linux versions or do they need different code?

Are the text changes likely to work with Mac and Linux versions or do they need different code?

A build is running here on Ubuntu 18.04 in a VM on an Intel Mac, the mouse scrolls and text copies and pastes between Linux and RPCEmu.

The only minor comment so far is that 256MB RAM would be good in settings to avoid on reset :-

RPCEmu fatal error: Bad PC fc001000 fc001000

Someone who knows how would need to do a build for the Intel Mac, I think it has already been established that Cloverleaf do not have a Mac. It has also been established that RPCEmu does not do well on Apple Silicon.

HTH.

And on more thing, the filetypes of the rpcemuhelper Obey file and Module in the Cloverleaf “Binarias” zip need setting when unzipped within RISC OS with SparkFS.

It has also been established that RPCEmu does not do well on Apple Silicon.

Works fine here on Apple Silicon. Albeit just the interpreter version. Natively or aarch64 using Parallels or QEMU. For some reason it runs a lot faster using the Hypervisor framework compared to native. (180mips and 230mips)

Only thing I noticed is the ‘Tasks’ window won’t scroll. Clipboard copying and other windows scroll OK.

To make it work the helper module “rpcemuhelper” has to be loaded and the clipboard monitoring task needs to be started.
The module loader script is hostfs/!Boot/Choices/Boot/Tasks/Rpcemuhelper,feb to ensure it is run at boot time.
The module binary itself is hostfs/System/350/Modules/rpcemuhelper,ffa

Copying the module into the RPCEmu\poduleroms directory in the Windows side seems to suffice

@Steve Pampling
Yes, copying to RPCEmu\poduleroms loads the module. But there is needs to start the clipboard monitoring task.
I was not sure that module not hangs waiting task to complete if start task directly from module itself and implemented the separate command rpcemuhelper_start for it.
I will try to implement the task start from module and if it will works correct will move module to RPCEmu\poduleroms.

Yes, copying to RPCEmu\poduleroms loads the module. But there is needs to start the clipboard monitoring task.

Apologies. In later testing I’d discovered the clipboard needing the “task start” but forgotten to mention that.

Interestingly, using the StrongED menu option for copy (Menu: Block > Clipboard > Copy) works to place text in the transfer clipboard, using the declared shortcut Ctrl-Shift-C does not.
Edit does the copy & paste just fine, so I think we can point at StrongED (or the config of StrongED) for that problem.

That’s rather surprising given that both the menu option and cs-C call the same code to copy text to the global clipboard. If one method works then I’d expect the other to work too.

So for now it looks like the cs-C didn’t reach StrongED for some reason. Do other cs- keyboard shortcuts (eg cs-right arrow to select to end of line) work?

Interestingly, using the StrongED menu option for copy (Menu: Block > Clipboard > Copy) works to place text in the transfer clipboard, using the declared shortcut Ctrl-Shift-C does not.

I have this issue as well, I always have to use the menu methods for CTRL-SHIFT copy/paste as none of the key combinations work.

If one method works then I’d expect the other to work too.

Me too, as they say.

I’m not getting the same behaviour today that I had with the sequence yesterday, did I do something different?:

Yes, I did. I did multiple lines in the copy

Single line:
Testing with a cs-right arrow, cs-C and paste with Ctrl-V in Windows works, mouse selecting text and cs-C plus ctrl-V works.

However, although selecting multiple lines of text in Edit and then doing ctrl-C will do a copy to clipboard for a paste into Windows, cs-C in StrongED will not take multiple lines but is happy with single.

Fire up Edit, do a select text, cs-C (StrongED) ctrl-V (Edit) works as expected (local clipboard) and the same multi-line text can be pasted into Windows.
Shutdown Edit, repeat various single line and multi-line copy (StrongED) paste (Windows) sequences, and they work.
Shutdown RPCEmu, start up RPCEmu, select multiline text in SE, paste in Windows – works. :(

So, it’s intermittent, not application specific or single/multiline specific.
This is going to be frustrating…

I’ve just retested. CTRL-SHIFT-C works inside StrongED, as does CTRL-SHIFT-V if then done into an Edit Command Taskwindow. It’s CTRL-SHIFT-V into a StrongEd Taskwindow that isn’t working for me. The number of lines being copied makes no difference in my case.

CTRL-SHIFT-V into a StrongEd Taskwindow that isn’t working for me.

Same here. It never has AFAICR. I use drag and drop to get stuff into StrongED TaskWindows.
Everything else seems to work including cross-platform to Linux.

@Steve

So, it’s intermittent, not application specific or single/multiline specific.

If I understand you correctly then copying/pasting is working fine within RPCEmu but pasting into Windows is intermittent?

If so, then either the transfer of clipboard data from StrongED to RPCEmuHelper is failing or something further along is.

Therefore I would suggest that Cloverleaf check if RPCEmuHelper is receiving a complete copy of clipboard data from StrongED. That will tell us whether the problem is on the RISC OS side or not, and we can take it from there.

@Jon

It’s CTRL-SHIFT-V into a StrongEd Taskwindow that isn’t working for me.

The TaskWindow mode will pass most keypresses on to the underlying task, including cs-V, meaning StrongED doesn’t do anything with it.

To change that, load the TaskWindow ModeFile and look for the line:

cs-V <tab> ToTask

edit it to:

cs-V <tab> ReleaseShiftCtrl CB_Paste

After that pasting into a StrongED TaskWindow should work. The ReleaseShiftCtrl is there to make sure LineEditor doesn’t grab the keypress.

After that pasting into a StrongED TaskWindow should work.

Thanks Fred – it does indeed work.

If I understand you correctly then copying/pasting is working fine within RPCEmu but pasting into Windows is intermittent?

Exactly that.
Unlike Jon & John I hadn’t tried pasting into a TaskWindow as I regarded the copy & paste within RPCEmu as just a check that the text was entering/leaving the clipboard, so it was editor to editor.

Anyway, looks like a possible glitch in the RPCEmuHelper process – the problem is getting a reproducible sequence for failure, otherwise people could chase their tails for a long time.

@Fred Graute

I’m checked the RPCEmuHelper and !StrongEd on my Linux host machine.

The clipboard copy/paste between RISCOS and my Linux host works correct when called from menu “Block→Clipboard→Copy to clipboard”, “Block→Clipboard→Paste to text”.

The Ctrl-Shift-C, Ctrl-Shift-V keys is not working for me, seems StrongEd or RISCOS don’t see that Shift was pressed (in combination with Ctrl) and always perform the its internal Copy/Move operations, same like from menu “Block→Process→Copy”, “Block→Process→Move”. Shift alone is detected as Shift-Arrows work as expected.

I’m tried in the “TextMode”

There is seems some problem in RISCOS or RPCEmu to detect (or send) that both Shift and Ctrl is pressed. Single Shift-Key and Ctrl-Key is works. In other project me needs to detect Ctrl-Shift-Enter, Ctrl-Enter, Shift-Enter combinations. I used 2 calls to the OS_Byte 121 in the KeyEvent handler and it never give me result that both Ctrl and Shift are pressed (only single Shift or Ctrl).

        // check if control pressed

        regs.r[ 0 ] = 121;

        regs.r[ 1 ] = 0×1 ^ 0×80;

        tbx::swix_check(kernel_swi(0×6, &regs, &regs)); // 0×6 is OS_Byte

        ctrl_pressed = (regs.r[ 1 ] == 0xff);

        // check if shift pressed

        regs.r[ 0 ] = 121;

        regs.r[ 1 ] = 0×80;

        tbx::swix_check(kernel_swi(0×6, &regs, &regs)); // 0×6 is OSByte

        shiftpresses = (regs.r[ 1 ] == 0xff);

The RPCEmuHelper have debug output which can be turned on by:
*rpcemuhelper_debug 1

The debug output can be seen in the !Reporter.
In the debug output can be seen the length of clipboard and first line of clipboard content.

Ctrl+Shift together do work in RPCEmu – I can use Ctrl+Shift+Right_Arrow to select words in Fireworkz. It may be that the OS_Byte 121 mechanism isn’t working as expected? I have always used OS_Byte 129 for key detection on the grounds that if it’s good enough for INKEY to use, it’s good enough for me! (I look for such shifting key modifiers when I receive a Window Manager Key event)

I have always used OS_Byte 129 for key detection

Indeed. I have just checked the source to David Pilling’s keyboard handling in his task lib. It uses os_byte 129 for polling shift, ctrl, and alt. It uses os_byte 121 for other keys, with the comment ‘keys other than shifts pressed?’. I have always used os_byte 129 in the few cases where I have polled for shift and ctrl.

There is a lot of similarity between the calls.

121 lets you check a specific key (in R1 EOR &80) and it returns &FF if the key is down, zero if not.
Alternatively it lets you check a range of keys, using R1 on entry to set the lower limit (so you can choose to ignore the modifier keys). It will return the key number in R1 on exit, or &FF if no key pressed (yup, the opposite ;-) ).

122 is the same as calling 121 with R1=16, so it’ll ignore Ctrl, Shift, Alt and the mouse keys.

129 is largely similar; it can scan for a range of keys or a specific key (just like 121), it also can do a timed scan (like a positive INKEY) as well as the completely unrelated reading of the OS identifier byte.

I’m not sure what, if any, difference there is. Originally (BBC Micro), 121 was the keyboard scan and 129 was the read-within-time-limit. Note, though, that they are not identical – you just give an internal key number to 121 to set the range. With 129 you have to EOR it with &7F for some reason.

It looks like in Arthur, 129 was extended to be able to scan for a particular key…and it seems in RISC OS 2 to be able to also scan for a range of keys, thus essentially duping 121.

thus essentially duping 121.

• 121
  calls BBCScanKeys.

• 129
  if OS version, report it, otherwise call DoInkeyOp
  if timed INKEY, handle it, otherwise EOR the given key value with &7F and then call BBCScanKeys.

;-)

While on this tack, it is useful to remember os_byte 202, which checks the keyboard status byte. This reports the status of several keys/states. In this context, it checks whether shift and/or ctrl keys are down. Very useful if using those keys to modify actions, e.g. mouse clicks or drags.

Scroll wheel working is nice indeed – as is the option that upon RISC OS shutdown RPCEmu ends too (that question when I have shut down RISC OS if I want to really quit RPCEmu is kind of superflous – now it’s even nicer).
- And as for the rpcemuhelper module I am sure keen-eyed as you all are you renamed !Boot.Resouces in the zip archive into !Boot.Resources.
- And if you then move the rpcemuhelper obey from !Boot.Choices into !Boot.Choices.Boot.Tasks it will even load at boot time.

What would really be nice is an option such that RPCEmu sets the RISC OS screen resolution to the size to match the RPCEmu window – or to perhaps just offer 2-3 resolutions (one full screen and configurable smaller ones) that you can swith to with a simple click and RISC OS screen mode and RPCEmu window size are in sync.

And while putting forward wishes: To end fullscreen with Ctrl End is a bit incovinient since that is the keypress to delete lines in the odd app; perhaps Alt End can be used in some future version optionally.

In any case I am really hoping that the changes done by Cloverleaf are soon good so that they can be included in the normal RPCEmu so that we don’t have a fork.

To end fullscreen with Ctrl End is a bit incovinient

The macOS build of RPCEmu gets round this, albeit by accident: to allow for the use of compact keyboards (e.g. on laptops) “end fullscreen” was remapped to Ctrl-Cmd-downarrow, so users with a full size keyboard can carry on using Ctrl-End as “delete line”.

We changed the implementation of the UTF-8 conversion after a discussion with Nemo. Now the conversion is done on the RISC OS side. Also implemented image clipboard support.
So the size is now down to 470 KB as before instead of 1.4 MB.

1. Implemented images support for host<→guest integrated clipboard. Tested on !Paint and !PrivateEye apps.
2. From HOST (RPCEmu side) to GUEST (RISCOS side) image transferred in JPG format. RISCOS apps must be able to load JPG to paste from clipboard. !Paint can do this.
3. From GUEST to HOST then clipboard images can be transferred in JPG and PNG formats. Sprites doest not supported right now, it will be implemented later. Copy from !Paint will not work as it copies the sprite. Copy from !PrivateEye a JPG and PNG files is work.
4. As RISCOS does not have events to monitor the clipboard contents changes then it must be polled and compared with old content and if a big image copied to clipboard then a system can run a little slowly.
5. To convert the clipboard text to/from RISCOS encoding I used RISCOS UCS conversion table (serviceinternational_get_ucs_conversion_table() function) instead of iconv. Windows version become smaller again as linking with iconv is not required.
Note: right now the conversion table is retrieved at the start of the module so if you change the alphabet later then it will not updated. Will be fixed later.

To work correct then needs to replace a module rpcemuhelper also. The module is in the zip archive.
http://files.riscoscloverleaf.com/rpcemu/rpcemu-0.9.3_cl_0.3.zip

Patched sources and patch is here
http://files.riscoscloverleaf.com/rpcemu/rpcemu-0.9.3_cl_0.3_src.zip

We didn’t make a built yet for MacOS as we need to setup a irtual MacOS first as no real Mac available.

On the subject of MIME-Mapping, i.e. presenting a named “crap.zip” as Archive file to RISC OS with no need to have the file named “crap.zip,ddc” … or “crap.zip,a91” (be it renamed on Windows or the type being set on RISC OS).

Indeed it would be nice if HostFS does support MimeMap so that e.g. when I have some archives on my windows disc that they remain ZIP for windows and are ZIP for RISC OS – currently if I type them to be ZIP on RISC OS the file name on disc is changed since a “,a91” or “,ddc” is appended and for Windows they are not more ZIP. Same applies to JPEG images etc.

At the time being my work-around this one is that I use LanManFS in addition to HostFS and thus have all the comfort I’m keen to have – and with LanManFS as nice side effect I can see all my disc of the Windows host and not just that small part HostFS points to!

BUT – and that is a huge BUT:
- RPCEmu does support the odd RISC OS version and the old ones do not use MimeMap but other thechniques
- The content of the MimeMap file can be amended by the user or changed by ROOL (last promiment change I am aware of is to move to A91 for ZIP file from the former DDC)

Not supporting any mapping but relying only on the ,xxx file name suffix by RPCEmu has the massive benefit that no matter what RISC OS version you use or what changes have been made to the MimeMap file (or if it is even corrupt or lost) the filetypes remain unchanged, i.e. are safe as they would be on a native FileCore disc. For those who use RPCEmu to have several different RISC OS versions at hand just to be able to check if the software they wrote supports real old RISC OS versions like 3.0 this absolute guarantee that file types are not tampered with depending on the RISC OS version or any other stuff but survive safely by design of RPCEmu are probably even very happy this to be the case.

So enabling MimeMap for HostFS does have some merit but does have a drawback too – and some riks.