Avalanche/VNCSvr Config Pinboard

Running Avalanche v0.22 on ARMX6 to control RPi3 using VNCSvr v2.05(0.18).
Any attempt to change the Pinboard Background colour on the Pi via Configuration causes Avalanche to crash with:
trap in trap handler abort
&FC15DF14 PC = FC15DF0C at 000248A4

Any attempt to change the Pinboard Background colour on the Pi via Configuration causes Avalanche to crash

The problem is not so specific as the above suggests. Almost any drag of a window causes the same abort. It is worse when the ARMX6 is displaying 2560 × 1440 and the RPi is 1920 × 1080. When the ARMX6 is displaying 1920 × 1980 it is possible to move windows, but sooner rather than later Avalanche crashes.
Is anybody using Avalanche/VNCSvr successfully?

Avalanche is pretty crashy when data transfer is big. With a fast computer you must be very slow :)

VNCSrv is very reliable. But do not accept modifiers as â on French keyboard. The same with RDPClient.

â is ^ then a

Avalanche is pretty crashy when data transfer is big.

What I was hoping to do was to run OBrowser on the Pi and control it via Avalanche on a MoreDesk virtual screen on the ARMX6. This way I could set Otter going, looking for something in its glacial fashion, meanwhile being able to carry on using the ARMX6.
Sadly Avalanche crashes within 2 or 3 seconds. I have tried using a lower res mode on the Pi, and dropped the ARMX6 to 1920×1080.
There was no improvement.

But, and here is the good news. No such problem on the Iyonix. I have been using Avalanche for half an hour now without any crashes.

The Iyonix is using 1680 × 1050, the Pi is using native 1950 × 1080 so I have to scroll occasionally.

Perhaps I need to contact RComp to see if they can suggest anything.

Did anyone try to recompile ViNCe (by Vincent Levefre) or VNC (by Simon Truss) for the newer machines?

I have to say, I have more issues with Avalanche on my ARMx6 that I do on the Titanium or even the RiscPC. I did play with it earlier, as per your original setup, and noticed it seemed more reliable if I ran the Pi in 64k modes. More reliable than both 256 or 16m modes. Couldn’t say if it was anything more than coincidence though.

I do have regular network issues with the ARMx6 that I don’t have with any other machines (shares disappearing or timing out, Omni not working etc.) but I’ve just learned to live with it in that respect, and the Titanium has largely taken over as the workhorse machine.

Did anyone try to recompile ViNCe (by Vincent Levefre) or VNC (by Simon Truss) for the newer machines?

Leo White did a couple of VNC things, didn’t he? http://mybigideas.co.uk/html/software.php

I have to say, I have more issues with Avalanche on my ARMx6 that I do on the Titanium or even the RiscPC.

I have to say that Avalanche 0.22 is good on my Titanium running current ROMs, but it was not always so. It seems there was some substance to this post.

Just a thought but what date are the ARMx6 custom ROMs on the machines giving the trouble.

Just a thought but what date are the ARMx6 custom ROMs giving the trouble.

19th Jan 2017 – I remember I had to drop back from the last update as it broke the EDID for my monitor. I’ve since switched the monitor, so that may not be such an issue now. I’ll give it a go with the latest ROM over the weekend.

just a thought but what date are the ARMx6 custom ROMs on the machines giving the trouble

The ROMs have not been changed. They are low vector. The Info menu item on the RISC OS iconbar says:
5.23 (29Jun 16)
The boot partition on my RComp ARMX6 is not visible and short of taking the machine apart and putting the SD card into another machine I don’t know how to change the ROMs.

The boot partition on my RComp ARMX6 is not visible and short of taking the machine apart and putting the SD card into another machine I don’t know how to change the ROMs.

The ARMX6 ROMs are only available from RComp who issue user friendly upgrades from time to time. I do not have an ARMX6, and do not know what the latest RComp release is.

In any case it is not absolutely proven that the ROM date is an issue on the ARMX6 though it does appear to be a possibility on the Titanium. The magic ROM date would be 08-Jun-17.

A quick view of the ARMini support lists suggest that a new ROM was made available in April 17 and is available from the support site with username/password provided when the ARMX6 was purchased.

This includes the tool to do the update.

I’d suggest John checks the list or contacts RComp if he can’t find his details.

If memory serves me right it also includes a fix for slow internet and EDID improvements.

How to get the ARMX6 updates is explained in the last page of Documents→welcome.pdf on the disc supplied with the ARMX6. You could just use TurboLAN.zip from the same site. Judging from the dates that may only be included in the latest test rom.

How to get the ARMX6 updates is explained in the last page of Documents→welcome.pdf

Thanks for that – note to self – RTFM!
New ROMs 19 April 2017 now installed.
Avalanche crashed within 5 seconds giving slightly different numbers:
&FC16148C PC = &FC161484 at 000248A4
However I am writing this in Otter on the Pi via Avalanche on the ARMX6.
I have restricted the Avalanche window to about half size and using scroll bars – it is holding up.

Well it was until I pressed “Post” then it aborted with numbers as above .
Fortunately VNCSrv was not affected so the post was not lost.
I am finishing this off on Avalanche on an ARMiniX (1920×1080) full size and apparently stable.

Does *help etherth show version 0.25 or later? If not try installing TurboLanv2.zip

Does *help etherth show version 0.25 or later? If not try installing TurboLanv2.zip

EtherTH 0.26 11 March 2017

(still using ARMiniX Avalanche)

Any change with the recent Jan 2018 release? We’ve had no other networking issues reported, and I’m rather surprised by AndyM’s comments (do bear in mind that the primary customers for ARMX6 absolutely pound the networking, and many recent Omni updates came from ARMX6 dev!). From what I’ve seen, current ROM/ethernet stuff on ARMX6 is some of the best LAN performance/reliability around. There’s still more work to do on Omni generally though, for all platforms.

I’m rather surprised by AndyM’s comments (do bear in mind that the primary customers for ARMX6 absolutely pound the networking, and many recent Omni updates came from ARMX6 dev!). From what I’ve seen, current ROM/ethernet stuff on ARMX6 is some of the best LAN performance/reliability around. There’s still more work to do on Omni generally though, for all platforms.

To be fair to Andrew and RComp, I’m suspending my earlier comment in light of wider network issues that have occurred and I think I am now blaming a faulty BT router, not least because any online TV stuff seems to freeze with the same regularity as the ARMx6. Recent use of Netflix and Brooklyn Nine Nine has nicely, and most frustratingly, brought this to my attention!