Re: New treeview

In article <537cc325a6tlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:

> Remaining Hotlist TODO:

> + Node editing
> + Updating hotlist visits data
> + Saving the hotlist to file, and on quit
> + Adding entries
> + A default "Unsorted" folder for new entries
> + A way to create new folder nodes

All done, although the front ends aren't updated to use it all.

Over the weekend I intend to make NetSurf use the new treeview, and remove
the old one. The temp_treeview_test option will be removed.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <20130822182907.GD31223@spod.org>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> On Thu, Aug 22, 2013 at 08:18:16AM +0100, george greenfield wrote:
>> In message <7b84d77e53.old_coaster@old_coaster.yahoo.co.uk>
>> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>>
>> > On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

Hi Peter

Sorry for the long delay in replying: see below for updates (such as
they are)..
>> >
>> > [snip]
>> >
>> >> If you're running on Vista or 7 and you used the windows installer,
>> >> don't check Program Files/RPCEmu/rpc.cfg but Users/<your
>> >> userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg
>> >
>
> George, can you confirm whether your config file issue was resolved by
> comparing this other file.

Yes, it was. Despite not using the Windows Installer on my latest,
clean install of 0810/520, it turned out that AppData did indeed
contain a folder corresponding to my /520 installation, which
contained a valid rpc.cfg file (i.e., one conforming to actual
settings) with a current date. So seemingly, if at any time one has
used the Windows Installer (I did, on my original 089/402
installation), crucial bits of subsequent installations will actually
run from AppData regardless of how they have been installed.
>
> As to your new issue, try not using 256MB of RAM, but a lower value.
> There's some interesting issues with risc os and that much ram on real
> hardware, and I'm wondering if similar occurs when emulated.

I tried 128MB, but the Bad Opcode problem is still with me. Also,
089/402 has been running for months now with 256MB of RAM (264MB
actually reported), without any problems. As I explained to Tony (who
has been very helpful), I don't actually /need/ /520 to work, as I
have a networked and KVM-switched Iyonix, so troubleshooting /520 is
pretty much a spare-time activity. Cheers,

George



--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Fwd: Installing NetSurf

Hi All, 

I hope that this is not a waste of the list's time ....

I have successfully installed Enlightenment 17 for my build and I have chosen Netsurf as the web browser. 

However, when trying to install Netsurf under the command of "make install [PREFIX=/usr]" the process stops at "gtk/Makefile.target:25. *** unable to find library for : BMP libnsbmp. Stop." But the libnsbmp library has been installed.

How can I overcome this?

I'm sure that I'm gonna look stupid against what is probably an easy fix. 

Would be really grateful if someone can help me out :) 

 

Regards, 

Asma

[gccsdk] [Bug 247] PDFUtils has no Sprites file

http://www.riscos.info/bugzilla3/show_bug.cgi?id=247

John Tytgat <John.Tytgat@aaug.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |John.Tytgat@aaug.net
Resolution| |FIXED

--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2013-08-24 05:03:39 PDT ---
Solved by Chris Gransden (incl. an upgrade to version 0.23.1).

--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <20130822182907.GD31223@spod.org>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> On Thu, Aug 22, 2013 at 08:18:16AM +0100, george greenfield wrote:
>> In message <7b84d77e53.old_coaster@old_coaster.yahoo..co.uk>
>> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>>
>> > On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>> >
>> > [snip]
>> >
>> >> If you're running on Vista or 7 and you used the windows installer,
>> >> don't check Program Files/RPCEmu/rpc.cfg but Users/<your
>> >> userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg
>> >
>
> George, can you confirm whether your config file issue was resolved by
> comparing this other file.

Hi Peter

I didn't use the Windows installer (I installed direct from the zips),
so not sure whether the
'Users/<youruserame>/AppData/Local/VirtualStore/Program
Files/RPCEmu/rpc.cfg' file will actually be relevant....
>
> As to your new issue, try not using 256MB of RAM, but a lower value.
> There's some interesting issues with risc os and that much ram on real
> hardware, and I'm wondering if similar occurs when emulated.

Reducing RAM to 128MB via Settings-Configure-RAM seems to have helped;
0.8.10/5.20 recompiler is now up and running (hurrah) and networking
is back up too (in fact I'm sending this post from it). This
installation is in OS (C:)>Program Files>RPCEmu0810-520>rpcemu520,
which was created from scratch i.e. was not in use for an earlier
RPCEmu version. A quick check of rpc.cfg in the rpcemu520 folder shows
no change in the base settings, i.e., still showing ARM610 and 32MB
RAM, for instance. Any suggestions where I should look for the real
McCoy?

George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On 23 Aug 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> In message <5a70717f53.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:

[snip]

> > Here, MPro/Hermes seems to be OK, on 0810/520. I'm using it now.
>
> What versions are you using? Mine are rather elderly.

RPCEmu is currently using MPro 6.06, Hermes 2.62 (I'm now typing this on
my RiscPC, which has later versons).

[snip]

> > > Having moved my working directory to 0810/520's HostFS, when I
> > > needed to move it back to 089/402 it was not visible either over
> > > the network from another RO machine or under Windows:
> >
> > Windows Explorer couldn't see it?
>
> No. It was a 'clean' install, i.e., I created a new installation
> rather than upgrading my existing 0810/519 version.

Your working directory is in HostFS, which is a Windows folder. I read
your first comment, above, to mean that Windows could not see one of its
own (un-hidden) folders. If you need to move the work folder again, it's
likely to be faster to do so via the Windows filer.

[snip]

> I'll get to grips with 0810/520 at some point, but whereas /402 is a
> genuine 'hardware replacement' option here, the jury's still out on
> /520 despite its advantages.

I wonder if the dodgy start-up was caused by RPCEmu not emulating the
StrongARM CPU. I've found that attempting to use ARM750 causes boot to
fail. My 0810/520 rpc.cfg file contains

model = RPCSA
bridgename = rpcemu
mouse_twobutton = 0
network_type = ethernetbridging
mouse_following = 1
cdrom_type = 0
cdrom_enabled = 0
refresh_rate = 60
stretch_mode = 1
sound_enabled = 1
vram_size = 2
cpu_type = SA110
mem_size = 256
cpu_idle = 1

However, in view of Peter's recent caution, maybe you need to reduce
mem-size to 128, although 256 seems to work here.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <5a70717f53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 22 Aug 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>
> [snip]
>
>> Indeed. But even before the booting/networking problems,
>> NetFetch/MessengerPro was not working properly (freezing the system
>> before displaying incoming mail),
>
> Here, MPro/Hermes seems to be OK, on 0810/520. I'm using it now.

What versions are you using? Mine are rather elderly.
>
>> NetSurf was taking 90 seconds to load
>
> NS 1258 loads in 7 seconds.

I do have a lot of fonts - approx. 120 individual font directories -
but NS 1305 on 089/402 loads equally quickly.
>
> [snip]
>
>> Having moved my working directory to 0810/520's HostFS, when I needed
>> to move it back to 089/402 it was not visible either over the network
>> from another RO machine or under Windows:
>
> Windows Explorer couldn't see it?

No. It was a 'clean' install, i.e., I created a new installation
rather than upgrading my existing 0810/519 version.

>
> [snip]
>
>> I didn't use the Windows installer to set up 0810/520.
>
> Nor did I.

Nor I.

>
> [snip]
>
>> Apart from the apps mentioned above I'm running all the usual stuff
>> here, TechWriter, Artworks, Thump, Variations, OvationPro, nothing
>> exotic, and am using RISC OS to do actual work
>
> I mainly use my RiscPC, but switch to RPCEmu, for its speed, when
> editing DataPower files, etc.

Indeed. Apart from benchmarks such as !Firebench and !RoMark, RPCEmu
is nearly twice as fast as the Iyonix displaying complex tables in
NetSurf e.g.
http://www.navweaps.com/index_nathan/Penetration_Britain.htm which takes just under 20 secs under 089/402 and about 35 secs on the Iyo (similar vintage of NS in both cases, javascript disabled). OTOH running a 12-JPEG slideshow in !Thump with zero display time selected takes 53 secs under /402, 37 secs under /520 and 34 secs on the Iyo (a demonstration of the benefits of hardware acceleration, presumably).

>
> [snip]
>
>> Sorry for the rather rambling post, but hopefully it's all 'grist to
>> the mill'.
>
> Sorry to hear of the problems.

I'll get to grips with 0810/520 at some point, but whereas /402 is a
genuine 'hardware replacement' option here, the jury's still out on
/520 despite its advantages.

George
--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On 22 Aug 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:

[snip]

> Indeed. But even before the booting/networking problems,
> NetFetch/MessengerPro was not working properly (freezing the system
> before displaying incoming mail),

Here, MPro/Hermes seems to be OK, on 0810/520. I'm using it now.

> NetSurf was taking 90 seconds to load

NS 1258 loads in 7 seconds.

[snip]

> Having moved my working directory to 0810/520's HostFS, when I needed
> to move it back to 089/402 it was not visible either over the network
> from another RO machine or under Windows:

Windows Explorer couldn't see it?

[snip]

> I didn't use the Windows installer to set up 0810/520.

Nor did I.

[snip]

> Apart from the apps mentioned above I'm running all the usual stuff
> here, TechWriter, Artworks, Thump, Variations, OvationPro, nothing
> exotic, and am using RISC OS to do actual work

I mainly use my RiscPC, but switch to RPCEmu, for its speed, when
editing DataPower files, etc.

[snip]

> Sorry for the rather rambling post, but hopefully it's all 'grist to
> the mill'.

Sorry to hear of the problems.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On 21 Aug 2013, Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> [snip]
>
> > If you're running on Vista or 7 and you used the windows installer,
> > don't check Program Files/RPCEmu/rpc.cfg but Users/<your
> > userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg
>
> Using Win7 32bit, RPCEmu was installed from the zip archive, not the
> installer, and the folder Users/<userame>/AppData/ is not present.

I had forgotten that the AppData folder is normally hidden and, having
changed the settings to show the folder, I find that there are, indeed,
rpc.cfg files present where you say. However, their datestamps are all
more than a year old and presumably result from previous installations,
long since abandoned. I have now changed the names of the folders in
VirtualStore/Program Files, to hide them, and the current installations
continue to work.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On Thu, Aug 22, 2013 at 08:18:16AM +0100, george greenfield wrote:
> In message <7b84d77e53.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>
> > On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> >
> > [snip]
> >
> >> If you're running on Vista or 7 and you used the windows installer,
> >> don't check Program Files/RPCEmu/rpc.cfg but Users/<your
> >> userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg
> >

George, can you confirm whether your config file issue was resolved by
comparing this other file.

As to your new issue, try not using 256MB of RAM, but a lower value.
There's some interesting issues with risc os and that much ram on real
hardware, and I'm wondering if similar occurs when emulated.

Peter

--
Peter Howkins
peter.howkins@marutan.net

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <7860227f53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 22 Aug 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>
> [snip]
>
>> 0810/520 has gone pop: on about 75% of bootups I get 'Bad opcode 14
>> 41435452 at 2019FC20'
>
> Does that mean that 25% start-ups are OK?

Roughly speaking, yes, but it's impossible to know beforehand if any
given startup will fail or not: 0810/520 recompiler mode is completely
unpredictable in its present state.
>
[snip]
>
> The utility Where should be copied into !Boot.Library . To call it, just
> type where at the star-prompt, and press return.
Cheers.
>
> If that doesn't yield and useful information, you could install Reporter
> and set it to monitor Boot. However, rather than trying to locate the
> problem, it might be quicker to start again, with a new installation.

Indeed. But even before the booting/networking problems,
NetFetch/MessengerPro was not working properly (freezing the system
before displaying incoming mail), NetSurf was taking 90 seconds to
load (though working fine once loaded), and I was getting intermittent
'Bad Opcode' errors. Oh, and Photodesk would not run from HostFS.

Having moved my working directory to 0810/520's HostFS, when I needed
to move it back to 089/402 it was not visible either over the network
from another RO machine or under Windows: the only directories visible
were those originally installed in the virgin HostFS (Internet,
Monitors, Network, Printing and Utilities). I solved that problem by
moving the work directory into Utilities and moving it from there. I
should add that I didn't use the Windows installer to set up 0810/520.

None of these issues arises with 089/402. So whilst 0810/520 is
measurably faster (30-50& depending on process) and doesn't suffer
from the 28MB limit, in terms of a fully-useable and stable system it
hasn't really cut it, on the basis of my experience to date. Apart
from the apps mentioned above I'm running all the usual stuff here,
TechWriter, Artworks, Thump, Variations, OvationPro, nothing exotic,
and am using RISC OS to do actual work against actual deadlines(!).
And I do have a networked Iyonix....

Sorry for the rather rambling post, but hopefully it's all 'grist to
the mill'.

George
--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On 22 Aug 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:

[snip]

> 0810/520 has gone pop: on about 75% of bootups I get 'Bad opcode 14
> 41435452 at 2019FC20'

Does that mean that 25% start-ups are OK?

> after the RO5 label disappears but before the desktop appears.
> Clicking OK terminates the boot sequence.

If you've added any items to PreDesk, Tasks, Look-at or Run, I'd suggest
removing them. If that fixes the problem, add back the removed items,
one by one, to see which is the culprit.

> That's with the recompiler; the interpreter boots ok but neither will
> see the network /at all/. I have Where, but am not sure how to
> install/use it.

The utility Where should be copied into !Boot.Library . To call it, just
type where at the star-prompt, and press return.

If that doesn't yield and useful information, you could install Reporter
and set it to monitor Boot. However, rather than trying to locate the
problem, it might be quicker to start again, with a new installation.

> So back to 089/420 for the time being....

When 0810/520 is up and running, again, I'd suggest making a backup copy
of the relevant folder C:\Program files\RPCEmu , or whatever.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <7b84d77e53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> [snip]
>
>> If you're running on Vista or 7 and you used the windows installer,
>> don't check Program Files/RPCEmu/rpc.cfg but Users/<your
>> userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg
>
> Using Win7 32bit, RPCEmu was installed from the zip archive, not the
> installer, and the folder Users/<userame>/AppData/ is not present. The
> only copies of rpc.cfg are those in Program Files/RPCEmu439, 520 etc.
> However, I still found that one data item (cdrom_enabled) in the 520
> rpc.cfg was not in sync with the value expected from Settings. Clicking
> again, in Settings, saved rpc.cfg with the correct value.
>
0810/520 has gone pop: on about 75% of bootups I get 'Bad opcode 14
41435452 at 2019FC20' after the RO5 label disappears but before the
desktop appears. Clicking OK terminates the boot sequence. That's with
the recompiler; the interpreter boots ok but neither will see the
network /at all/. I have Where, but am not sure how to install/use it.
So back to 089/420 for the time being....

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

[snip]

> If you're running on Vista or 7 and you used the windows installer,
> don't check Program Files/RPCEmu/rpc.cfg but Users/<your
> userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg

Using Win7 32bit, RPCEmu was installed from the zip archive, not the
installer, and the folder Users/<userame>/AppData/ is not present. The
only copies of rpc.cfg are those in Program Files/RPCEmu439, 520 etc.
However, I still found that one data item (cdrom_enabled) in the 520
rpc.cfg was not in sync with the value expected from Settings. Clicking
again, in Settings, saved rpc.cfg with the correct value.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On Wed, Aug 21, 2013 at 05:38:55PM +0100, George wrote:
> It doesn't: cpu_idle = 0 in rpc.cfg, even though the CPU is, clearly,
> idling correctly! But several items in rpc.cfg bear no relation to
> reality:
>
> RPC.CFG REALITY
> mouse_twobutton = 0 correct

<snip>

If you're running on Vista or 7 and you used the windows installer,
don't check
Program Files/RPCEmu/rpc.cfg
but
Users/<your userame>/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg

Peter

--
Peter Howkins
peter.howkins@marutan.net

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <a442c27e53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>> On Tue, Aug 20, 2013 at 05:09:40PM +0100, George wrote:
>
> [snip]
>
>> > Selecting Settings-Reduce CPU Usage doesn't seem to affect the
>> > behaviour.
>>
>> However, this should have kicked in the power-saving stuff. *provided*
>> that the OS starts seeing enough null events, e.g. if you're running a
>> task that uses all spare cpu in risc os, this will have no effect.
>>
>> After about 10 seconds you should see the mips count start to drop ...
>> unless something has changed in RO 5.20 from earlier ...
>
> Here, 'Reduce CPU Usage' seems to be working, with RPCEmu0810/RO520.
> Loading NetSurf, and fetching the BBC website, causes the MIPS value to
> increase to about 150 but, after a few seconds, drops to less than 1.0.
> Scrolling the displayed page, also causes a similar increase, which
> again drops to a low value, when there is no activity.
>
> Recently, Settings > CD-ROM showed 'Disabled' but. in rpc.cfg. I found
> cdrom_enabled = 1. George may find it worth checking, in rpc.cfg, that
> cpu_idle = 1 , in fact.
>
It doesn't: cpu_idle = 0 in rpc.cfg, even though the CPU is, clearly,
idling correctly! But several items in rpc.cfg bear no relation to
reality:

RPC.CFG REALITY
mouse_twobutton = 0 correct
network_type = off correct, though network is connected
via bridge
mouse_following = 1 correct
cdrom_type = 0 correct
cdrom_enabled = 1 not according to Configure*
refresh_rate = 60 correct by 'Settings'
stretch_mode = 1 ?
sound_enabled = 0 correct
vram_size = 2 correct
cpu_type = ARM610 S/ARM selected in 'Settings'
mem_size = 32 256MB selected in 'Settings'
ipaddress = 172.31.0.1 RPCEmu here = 192.168.2.2
cpu_idle = 0 enabled (and seems to be working)

(*just noticed that the RAM disc icon isn't on the icon bar, though it
is selected in Configure-Disks). It was there yesterday: I'll try
rebooting.

George

--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

In message <20130821142519.GB31223@spod.org>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> On Tue, Aug 20, 2013 at 05:09:40PM +0100, George wrote:
>> I've been running 0.8.10/5.20 daily for about a week now, and have
>> noticed an oddity relating to the MIPS readout on the header bar,
>> which seems to display activity (sometimes /a lot/ of activity - up to
>> 1400 on one occasion(!) and generally around 250-350 on my system*)
>> regardless of whether any application is active (i.e., when TaskUsage
>> will be displaying '0' or low single-figure activity levels).
>
> RISC OS machine by default don't have any power-saving (with reduce
> cpu-usage off), they run flat out providing wimp null events even when
> there's no apps running anything. This busy-wait loop uses up CPU cycles,
> which are the MIPS you're seeing.
>
[snip]
>
>> Selecting Settings-Reduce CPU Usage doesn't
>> seem to affect the behaviour.
>
> However, this should have kicked in the power-saving stuff. *provided*
> that the OS starts seeing enough null events, e.g. if you're running a
> task that uses all spare cpu in risc os, this will have no effect.
>
> After about 10 seconds you should see the mips count start to drop ...
> unless something has changed in RO 5.20 from earlier ...

I re-selected Settings-Reduce CPU Usage this morning and hey presto,
behaviour is back to normal, i.e., MIPS readout drops to 1 or 2
shortly after desktop or other activity ceases. Hey ho.....

George

--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On 21 Aug 2013, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Tue, Aug 20, 2013 at 05:09:40PM +0100, George wrote:

[snip]

> > Selecting Settings-Reduce CPU Usage doesn't seem to affect the
> > behaviour.
>
> However, this should have kicked in the power-saving stuff. *provided*
> that the OS starts seeing enough null events, e.g. if you're running a
> task that uses all spare cpu in risc os, this will have no effect.
>
> After about 10 seconds you should see the mips count start to drop ...
> unless something has changed in RO 5.20 from earlier ...

Here, 'Reduce CPU Usage' seems to be working, with RPCEmu0810/RO520.
Loading NetSurf, and fetching the BBC website, causes the MIPS value to
increase to about 150 but, after a few seconds, drops to less than 1.0.
Scrolling the displayed page, also causes a similar increase, which
again drops to a low value, when there is no activity.

Recently, Settings > CD-ROM showed 'Disabled' but. in rpc.cfg. I found
cdrom_enabled = 1. George may find it worth checking, in rpc.cfg, that
cpu_idle = 1 , in fact.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

On Tue, Aug 20, 2013 at 05:09:40PM +0100, George wrote:
> I've been running 0.8.10/5.20 daily for about a week now, and have
> noticed an oddity relating to the MIPS readout on the header bar,
> which seems to display activity (sometimes /a lot/ of activity - up to
> 1400 on one occasion(!) and generally around 250-350 on my system*)
> regardless of whether any application is active (i.e., when TaskUsage
> will be displaying '0' or low single-figure activity levels).

RISC OS machine by default don't have any power-saving (with reduce
cpu-usage off), they run flat out providing wimp null events even when
there's no apps running anything. This busy-wait loop uses up CPU cycles,
which are the MIPS you're seeing.

> I haven't noticed this with any previous 5.xx version or 4.02, where in
> both cases the MIPS display conformed pretty closely to activity as
> perceived on the desktop.

No, (assuming reduce-cpu-usage is off) all the versions of the OS will run
flat out.

The mips count can also vary depending on the complexity or ease with which an
instruction can be emulated. A tight loops of instructions that are easy
can temporarily skew the MIPS count higher.

> Selecting Settings-Reduce CPU Usage doesn't
> seem to affect the behaviour.

However, this should have kicked in the power-saving stuff. *provided*
that the OS starts seeing enough null events, e.g. if you're running a
task that uses all spare cpu in risc os, this will have no effect.

After about 10 seconds you should see the mips count start to drop ...
unless something has changed in RO 5.20 from earlier ...

> Windows Task Manager gives the same readout as MIPS.

I think windows task manager just takes a copy of the window title string.

You can use task manager to see that until you engage 'reduce CPU usage'
RPCEmu will use all available CPU power on one core, but with reduce CPU
usage that should drop to a negligable level.

TBH, as with most benchmarks, interpretting the output of the MIPS count
is complicated :(

Peter

--
Peter Howkins
peter.howkins@marutan.net

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] 0.8.10/5.20: MIPS readout oddity

I've been running 0.8.10/5.20 daily for about a week now, and have
noticed an oddity relating to the MIPS readout on the header bar,
which seems to display activity (sometimes /a lot/ of activity - up to
1400 on one occasion(!) and generally around 250-350 on my system*)
regardless of whether any application is active (i.e., when TaskUsage
will be displaying '0' or low single-figure activity levels). I
haven't noticed this with any previous 5.xx version or 4.02, where in
both cases the MIPS display conformed pretty closely to activity as
perceived on the desktop. Selecting Settings-Reduce CPU Usage doesn't
seem to affect the behaviour. Windows Task Manager gives the same
readout as MIPS.

It's not actually a problem functionally, but I just wonder if
something is going on that shouldn't be, and whether anyone else has
seen similar behaviour?

George
[*Win7-64, 3.4GHz quad-core i7 Dell XPS desktop]
--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Is HD4 now useable under 0.8.10/5.20?

On 19 Aug 2013, Chris Gransden <chrisg@care4free.net> wrote:
> In article <b13fca7d53.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> > > In message <1418ab7d53.old_coaster@old_coaster.yahoo.co.uk>
> > > Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > > > On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> > > >
> > > > > As a matter of interest, is it now possible to install
> > > > > HardDisk4 under 0.8.10/5.20
> > > >
> > > > RPCEmu 0.8.10 ships with an hd4.hdf file of zero bytes, and RO
> > > > 5.20 Configure > Discs > 'Conventional SCSI' is greyed-out. If
> > > > the hd4.hdf file is replaced with a file of non-zero length, the
> > > > RO 5.20 config option is still greyed out, so the answer seems
> > > > to be no.
> > > >
> > > [snip]
> > >
> > > Interesting - thanks. I wonder how IOMD 5.20 works on an actual
> > > RiscPC?
>
> > It presumably works, otherwise ROOL would not sell ROMs for the
> > RiscPC. The problem, above, arises because _RPCEmu_ won't play with
> > RO5.20.
>
> The SCSI config is not used in RPCEmu. Hard discs are IDE and if it
> was working should just appear automatically.

Thanks for the clarification.

> There is a patch that gets Hard Discs working. I'm using it here with
> RISC OS 5.21 and RPCEmu 0.8.10 on linux. It's not been applied as it
> causes problems with hard discs on RISC OS 4/6.

So what happened to the memory leak? Was that affecting RO 4/6, or RO 5?

> The patch is on this page on the ROOL forums
> https://www.riscosopen.org/forum/forums/5/topics/410?page=4.

But no ready-built binary.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Is HD4 now useable under 0.8.10/5.20?

In article <b13fca7d53.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> > In message <1418ab7d53.old_coaster@old_coaster.yahoo.co.uk>
> > Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > > On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> > >
> > > > As a matter of interest, is it now possible to install HardDisk4
> > > > under 0.8.10/5.20
> > >
> > > RPCEmu 0.8.10 ships with an hd4.hdf file of zero bytes, and RO 5.20
> > > Configure > Discs > 'Conventional SCSI' is greyed-out. If the
> > > hd4.hdf file is replaced with a file of non-zero length, the RO 5.20
> > > config option is still greyed out, so the answer seems to be no.
> > >
> > [snip]
> >
> > Interesting - thanks. I wonder how IOMD 5.20 works on an actual
> > RiscPC?

> It presumably works, otherwise ROOL would not sell ROMs for the RiscPC.
> The problem, above, arises because _RPCEmu_ won't play with RO5.20.

The SCSI config is not used in RPCEmu. Hard discs are IDE and if it was
working should just appear automatically.

There is a patch that gets Hard Discs working. I'm using it here with RISC
OS 5.21 and RPCEmu 0.8.10 on linux.
It's not been applied as it causes problems with hard discs on RISC OS 4/6.

The patch is on this page on the ROOL forums
https://www.riscosopen.org/forum/forums/5/topics/410?page=4.

Chris.


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Is HD4 now useable under 0.8.10/5.20?

On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> In message <1418ab7d53.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> >
> > > As a matter of interest, is it now possible to install HardDisk4
> > > under 0.8.10/5.20
> >
> > RPCEmu 0.8.10 ships with an hd4.hdf file of zero bytes, and RO 5.20
> > Configure > Discs > 'Conventional SCSI' is greyed-out. If the
> > hd4.hdf file is replaced with a file of non-zero length, the RO 5.20
> > config option is still greyed out, so the answer seems to be no.
> >
> [snip]
>
> Interesting - thanks. I wonder how IOMD 5.20 works on an actual
> RiscPC?

It presumably works, otherwise ROOL would not sell ROMs for the RiscPC.
The problem, above, arises because _RPCEmu_ won't play with RO5.20.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Is HD4 now useable under 0.8.10/5.20?

In message <1418ab7d53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
>
>> As a matter of interest, is it now possible to install HardDisk4 under
>> 0.8.10/5.20
>
> RPCEmu 0.8.10 ships with an hd4.hdf file of zero bytes, and RO 5.20
> Configure > Discs > 'Conventional SCSI' is greyed-out. If the hd4.hdf
> file is replaced with a file of non-zero length, the RO 5.20 config
> option is still greyed out, so the answer seems to be no.
>
[snip]

Interesting - thanks. I wonder how IOMD 5.20 works on an actual
RiscPC?

--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Is HD4 now useable under 0.8.10/5.20?

In article <1418ab7d53.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:

> > As a matter of interest, is it now possible to install HardDisk4 under
> > 0.8.10/5.20

> RPCEmu 0.8.10 ships with an hd4.hdf file of zero bytes, and RO 5.20
> Configure > Discs > 'Conventional SCSI' is greyed-out. If the hd4.hdf
> file is replaced with a file of non-zero length, the RO 5.20 config
> option is still greyed out, so the answer seems to be no.

> > or is the memory leak issue still with us?

> I wouldn't know.

> Tony

Yes, I tried that myself as all my other RPCEmu 4.02 4.39 and 6.20
installs run under HardDisc4.

As Tony notes even after changing the hd4.hdf it still doesn't work.

Dave

--

Dave Triffid

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Is HD4 now useable under 0.8.10/5.20?

On 19 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:

> As a matter of interest, is it now possible to install HardDisk4 under
> 0.8.10/5.20

RPCEmu 0.8.10 ships with an hd4.hdf file of zero bytes, and RO 5.20
Configure > Discs > 'Conventional SCSI' is greyed-out. If the hd4.hdf
file is replaced with a file of non-zero length, the RO 5.20 config
option is still greyed out, so the answer seems to be no.

> or is the memory leak issue still with us?

I wouldn't know.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Is HD4 now useable under 0.8.10/5.20?

As a matter of interest, is it now possible to install HardDisk4 under
0.8.10/5.20, or is the memory leak issue still with us?

George

--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: NetSurf Society 2013 AGM to be rescheduled

On Tue, Aug 13, 2013 at 09:15:37 +0100, Daniel Silverstone wrote:
> I will be working out the date/time on the 17th August, so vote now -- banzai!

I have given a little extra time, just in case there were latecomers.

The winning options were Thursday 12th and Saturday 14th September.

Since it's a tiny tiny bit more convenient for me, the AGM is hereby scheduled
for 20:00 UK time, Thursday 12th September.

If you are a society member and unable to attend, please note that the
nominations and seconds for committee members have been received and you can
vote between "Keep incumbent committee" or "None of the above" by email if you
wish.

We will not be recalculating membership versus the details determined
previously.

Regards,

Daniel.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Re: New treeview

On Sun, 18 Aug 2013 18:06:16 +0100, Michael Drake wrote:

> In article
> <OUT-5211066D.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > Hmm, if I drag up and down above my window's left-hand border, the
> > green arrow appears correctly (although I can see the expansion arrows
> > flickering underneath it). If I drag around anywhere else - including
> > outside the window's boundaries - all the entries get the closed
> > expansion arrows drawn on top of them and the green arrow doesn't
> > appear (or is getting overwritten - not sure which).
>
> Sounds like the front end is calling tree_draw with a bad x and/or y param.
>
> Note that the case of node move drags is the only one where x != 0 (i.e.
> the left edge of the redraw request rectangle is not at the full left of
> the treeview).

I've just noticed I copied my tiled redraws code over to the treeview,
so it's probably related to that. I'll look into it, thanks.

Chris

Re: New treeview

In article
<OUT-5211066D.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:

> Hmm, if I drag up and down above my window's left-hand border, the
> green arrow appears correctly (although I can see the expansion arrows
> flickering underneath it). If I drag around anywhere else - including
> outside the window's boundaries - all the entries get the closed
> expansion arrows drawn on top of them and the green arrow doesn't
> appear (or is getting overwritten - not sure which).

Sounds like the front end is calling tree_draw with a bad x and/or y param.

Note that the case of node move drags is the only one where x != 0 (i.e.
the left edge of the redraw request rectangle is not at the full left of
the treeview).

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

In article <9789347d53.DaveMeUK@my.inbox.com>,
Dave Higton <dave@davehigton.me.uk> wrote:

> I normally use Fetch_NS to fetch new versions, and I don't think it
> merges !Boot and !System, so I just merged them manually from 1312.

I don't think anything has changed in our !Boot/!System resources for a
while.

> Same result - works just fine, but I see 25b8 and 25be instead of
> the triangles.

Yeah, as I said, it seems the default RISC OS fonts don't supply those
glyphs. We'll need to add them to the !NetSurf.Resources.Fonts.NSSymbol
font.

Anyone want to have a crack at that?

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

In article
<OUT-52110545.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:

> I'm getting some odd effects though:
> * On the SSL viewer, expanding an entry makes the title on that line
> disappear

I can't reproduce that.

> * When dragging items in the hotlist, I'm getting the expansion arrow
> reprinted at an offset location. The normal drawing doesn't do this,
> so there must be something different in the calculations.

No, the tree drawing is always the same and done in one place with the
same calculations for positioning things.

The only difference is that during a node moving drag, an indicator arrow
should be rendered on top of what's been plotted previously, as an overlay.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

On 18 Aug 2013 17:32:53 +0100, Chris Young wrote:

> I'm getting some odd effects though:
> * On the SSL viewer, expanding an entry makes the title on that line
> disappear
> * When dragging items in the hotlist, I'm getting the expansion arrow
> reprinted at an offset location. The normal drawing doesn't do this,
> so there must be something different in the calculations.

Hmm, if I drag up and down above my window's left-hand border, the
green arrow appears correctly (although I can see the expansion arrows
flickering underneath it). If I drag around anywhere else - including
outside the window's boundaries - all the entries get the closed
expansion arrows drawn on top of them and the green arrow doesn't
appear (or is getting overwritten - not sure which).

Re: New treeview

On Sun, 18 Aug 2013 17:22:19 +0100, Michael Drake wrote:

> Don't suppose there's any change with my latest commit?

No, but there is with mine :)

I'm getting some odd effects though:
* On the SSL viewer, expanding an entry makes the title on that line
disappear
* When dragging items in the hotlist, I'm getting the expansion arrow
reprinted at an offset location. The normal drawing doesn't do this,
so there must be something different in the calculations.

Chris

Re: New treeview

In article
<OUT-5210FDD4.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:

> No, I'm getting nothing from hotlist.c.

I can't really see why that would be.

> https://www.unsatisfactorysoftware.co.uk :)
> https://armdevices.net does the same thing.

Don't suppose there's any change with my latest commit?

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

On Sun, 18 Aug 2013 16:45:26 +0100, Michael Drake wrote:

> Do you get the "Loading hotlist" LOG messages from desktop/hotlist.c's
> hotlist_init?

No, I'm getting nothing from hotlist.c.

> > Also, the SSL certificate tree is now rendering (or, rather, not
> > rendering) as completely blank.
>
> What page are you testing on? The only site I can find with an SSL cert
> problem is https://armdevices.net/

https://www.unsatisfactorysoftware.co.uk :)
https://armdevices.net does the same thing.

Chris

Re: New treeview

In article
<OUT-5210F3D6.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:

> I'm still seeing the old-style hotlist here (yes, I have the option
> set, and am using the latest build from the master branch[1]).

Odd. The old tree code, that the front ends use currently, should just be
detecting that temp_treeview_test is set, and redirecting calls to the new
treeiew. So that behaviour is all in the core, and it's working when used
from GTK and RISC OS front ends.

Do you get the "Loading hotlist" LOG messages from desktop/hotlist.c's
hotlist_init?

> Also, the SSL certificate tree is now rendering (or, rather, not
> rendering) as completely blank.

What page are you testing on? The only site I can find with an SSL cert
problem is https://armdevices.net/

(Also working on GTK and RISC OS.)

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

In message <537cd69ecetlsa@netsurf-browser.org>
Michael Drake <tlsa@netsurf-browser.org> wrote:

>In article <537cd5d040tlsa@netsurf-browser.org>,
> Michael Drake <tlsa@netsurf-browser.org> wrote:
>> In article <a03dd47c53.DaveMeUK@my.inbox.com>,
>> Dave Higton <dave@davehigton.me.uk> wrote:
>
>> > However, I see a "25b8" at the left of every line, which presumably
>> > means that that Unicode character isn't rendering for me.
>
>> It should be a little triangle, pointing right if the node is collapsed
>> and down if the node is expanded.
>
>Also, clicking the symbol toggles the node between those two states.

Sorry, I should have said: the expansion works fine, as it always did.
And of course it's not just 25b8, but 25be too.

I normally use Fetch_NS to fetch new versions, and I don't think it
merges !Boot and !System, so I just merged them manually from 1312.
Same result - works just fine, but I see 25b8 and 25be instead of
the triangles.

Dave

____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails

Re: New treeview

On Sat, 17 Aug 2013 19:54:55 +0100, Michael Drake wrote:

> I've just pushed a partial new implementation of the Hotlist.
>
> To see it in action, either set temp_treeview_test:1 in the
> Choices file, or pass --temp_treeview_test=1 when you execute NetSurf.

I'm still seeing the old-style hotlist here (yes, I have the option
set, and am using the latest build from the master branch[1]).

Also, the SSL certificate tree is now rendering (or, rather, not
rendering) as completely blank.

The global history and cookie trees are showing up fine and didn't
require any prodding.

Chris
[1] Built by U-Poseidon\Chris (Chris) from master at revision
d6e975ce5033ac4df5991577a5aae78256d74a92
(I tried the Jenkins build previously and that was no better)

hi all, a question about libhubbub and namespace

Hi all.

I was reading the example libxml.c provided in the src of libhubbub.
And found that it assumed that all html page had namespaces below:

/**
 * Mapping of namespace prefixes to URIs, indexed by hubbub_ns.
 */
static struct {
    const char *prefix;
    const char *url;
} namespaces[] = {
    { NULL, NULL },
    { NULL, "http://www.w3.org/1999/xhtml" },
    { "math", "http://www.w3.org/1998/Math/MathML" },
    { "svg", "http://www.w3.org/2000/svg" },
    { "xlink", "http://www.w3.org/1999/xlink" },
    /** \todo Oh dear. LibXML2 refuses to create any namespace with a
     * prefix of "xml". That sucks, royally. */
    { "xml", "http://www.w3.org/XML/1998/namespace" },
    { "xmlns", "http://www.w3.org/2000/xmlns/" }
};

However, take aol.com as example. It has namespaces below:

<!DOCTYPE html>  <html xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="Gecko ff2" id="global-header-light">  ... ...    

So, the Question is: how to automatically create namespaces for html pages such as aol.com ?

Thanks a lot.

Re: New treeview

In article <537cd5d040tlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> In article <a03dd47c53.DaveMeUK@my.inbox.com>,
> Dave Higton <dave@davehigton.me.uk> wrote:

> > However, I see a "25b8" at the left of every line, which presumably
> > means that that Unicode character isn't rendering for me.

> It should be a little triangle, pointing right if the node is collapsed
> and down if the node is expanded.

Also, clicking the symbol toggles the node between those two states.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

In article <a03dd47c53.DaveMeUK@my.inbox.com>,
Dave Higton <dave@davehigton.me.uk> wrote:
> In message <537cc325a6tlsa@netsurf-browser.org>
> Michael Drake <tlsa@netsurf-browser.org> wrote:

> It's an improvement on the old one. First, you've fixed the long-
> standing problem that double clicks near the right hand end of an
> entry were ignored; the whole line being sensitive is much more
> sensible - and alternating the background colours makes them clear
> all the way across. Second, there is now no doubt where you're
> dragging an item to; the green arrow is absolutely clear.

Good, thanks for that feedback.

> However, I see a "25b8" at the left of every line, which presumably
> means that that Unicode character isn't rendering for me.

It should be a little triangle, pointing right if the node is collapsed
and down if the node is expanded.

http://www.fileformat.info/info/unicode/char/25b8/index.htm
http://www.fileformat.info/info/unicode/char/25be/index.htm

If the default fonts don't provide those gylphs on RISC OS, we'll need
someone who knows their way around a font editor to add them too
!NetSurf.Resources.Fonts.NSSymbol

Cheers,

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: New treeview

In message <537cc325a6tlsa@netsurf-browser.org>
Michael Drake <tlsa@netsurf-browser.org> wrote:

>
> I've just pushed a partial new implementation of the Hotlist.
>
> To see it in action, either set temp_treeview_test:1 in the Choices file,
> or pass --temp_treeview_test=1 when you execute NetSurf.
>
> Hotlist loading and rendering are done. It's currently lacking the
> facility to add pages to the hotlist, and it doesn't save any changes when
> you quit NetSurf.
>
> Anyway, I'd like people's opinion on the behaviour of the drag&drop to move
> nodes around in the hotlist. Users had problems with the behaviour of the
> old one.
>
> Does it behave any differently to how you would intuitively expect?

It's an improvement on the old one. First, you've fixed the long-
standing problem that double clicks near the right hand end of an
entry were ignored; the whole line being sensitive is much more
sensible - and alternating the background colours makes them clear
all the way across. Second, there is now no doubt where you're
dragging an item to; the green arrow is absolutely clear.

However, I see a "25b8" at the left of every line, which presumably
means that that Unicode character isn't rendering for me.

Iyonix, RO 5.21 (04 Aug 2013), 512 MiB.

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: New treeview

I've just pushed a partial new implementation of the Hotlist.

To see it in action, either set temp_treeview_test:1 in the
Choices file, or pass --temp_treeview_test=1 when you execute NetSurf.

Hotlist loading and rendering are done. It's currently lacking the
facility to add pages to the hotlist, and it doesn't save any changes when
you quit NetSurf.

Anyway, I'd like people's opinion on the behaviour of the drag&drop to
move nodes around in the hotlist. Users had problems with the behaviour
of the old one.

Does it behave any differently to how you would intuitively expect?



Remaining Hotlist TODO:

+ Node editing
+ Updating hotlist visits data
+ Saving the hotlist to file, and on quit
+ Adding entries
+ A default "Unsorted" folder for new entries
+ A way to create new folder nodes

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

On 13 Aug 2013, Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
> In article <ea249c7a53.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_coaster@yahoo.co.uk> wrote:

> > I'm not disputing that reducing the pixel rate has solved the
> > problem. However, as said above, I don't understand why that should
> > be.
>
> See this thread: https://www.riscosopen.org/forum/forums/3/topics/1191

It's clear now. Many thanks.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

In article <ea249c7a53.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> I'm not disputing that reducing the pixel rate has solved the problem.
> However, as said above, I don't understand why that should be.

See this thread: https://www.riscosopen.org/forum/forums/3/topics/1191

Basically, the bit that determines whether a mode is suitable for real
IOMD hardware was changed in the development versions about a year ago.
Caught me out when I downloaded a more recent image earlier this year.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: something odd....

In message <d51ea57a53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 13 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
>
> [snip]
>
>> in the installation instructions for 0810/520 you advise selecting
>> 128MB RAM. 256MB is available: is it problematic? Can this setting be
>> changed (i.e. increased) after installation without ill-effects?
>
> With 0810/620, 256MB memory causes the pointer to disappear, so I
> decided to play safe, when installing 0810/520. Since then, I've changed
> the 0810/520 memory to 256MB. No problem.
>
> Tony

Thanks; I'll do likewise.

--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: something odd....

On 13 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:

[snip]

> in the installation instructions for 0810/520 you advise selecting
> 128MB RAM. 256MB is available: is it problematic? Can this setting be
> changed (i.e. increased) after installation without ill-effects?

With 0810/620, 256MB memory causes the pointer to disappear, so I
decided to play safe, when installing 0810/520. Since then, I've changed
the 0810/520 memory to 256MB. No problem.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: something odd....

In message <0afd997a53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 13 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
>> In message <537a7d9375rpcemu-sub@aconet.nl>
>> Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
>
> [snip]
>
>> > If you want to know where in the ROM this is, use the command 'Where
>> > &FC15C6BC' (provided you have the Where tool installed, of course).
>>
>> That sounds like a useful tool - where (no pun intended) would I get
>> it?
>
> Try http://www.armclub.org.uk/32bit/Where.zip
>
> Tony

Thanks. Off-topic now, in the installation instructions for 0810/520
you advise selecting 128MB RAM. 256MB is available: is it problematic?
Can this setting be changed (i.e. increased) after installation
without ill-effects?

George

--
George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

On 13 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> In message <9581917a53.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 12 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> > > In message <537a295b6crpcemu-sub@aconet.nl>
> > > Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
> > > > In article <a98a207a53.George@george/greenfield.tiscali.co.uk>,
> >
> > > > > However, the RISC OS-Configuration-Screen-Resolution available
> > > > > options don't go higher than 1280 x 1924 x 16M x 60Hz for the
> > > > > particular Benq MDF I'm using
> > > >
> > > > That's to do with the maximum pixel rate.
> > > >
> > > > See http://www.riscosopen.org/forum/forums/10/topics/1624
> > > >
> > > > I have added these to my MDF and they work:
> > >
> > > [MDF details snipped]
> > >
> > > Thanks, Frank: I've done likewise and you're right!
> >
> > In an earlier post, George said that RPCEmu 0.8.10 / RO 5.17 could
> > display 1280 x 1924 x 16M x 60Hz
>
> Sorry, what I actually meant to say was that 1280 x 1024 x 16M x 60Hz
> was the highest available display resolution on 0.8.10/5.20, whereas
> 0.8.10/5.17 will go up to 1824 x 1026 x 16M x 60Hz on my system.

Whatever, it doesn't alter the point that I was making.

> > whereas RPCEmu 0.8.10 / RO 5.20 could not. The hardware is emulated
> > by RPCEmu, which is the same version, in both cases, so that could
> > not account for the difference.
> >
> > RO 5.20 'protects' the emulated hardware by setting the value of
> > VIDCBandwidthLimit to 2000000000. For a 32 bbp display, that implies
> > a pixel rate of 500 MHz, which should not be a problem for the host
> > Windows machine, and which is certainly greater than the 148 MHz
> > pixel rate, required George's display.
> >
> > I'm somewhat confused as to what is actually limiting the display.
>
> Be that as it may, amending the pixel rates in the MDF file (from a
> max. of 144000 down to 108000 here) has made resolutions above 1280 x
> 1024 x 16M both visible in the Configuration-Screen options box and
> useable.

I'm not disputing that reducing the pixel rate has solved the problem.
However, as said above, I don't understand why that should be.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: something odd....

On 13 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> In message <537a7d9375rpcemu-sub@aconet.nl>
> Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:

[snip]

> > If you want to know where in the ROM this is, use the command 'Where
> > &FC15C6BC' (provided you have the Where tool installed, of course).
>
> That sounds like a useful tool - where (no pun intended) would I get
> it?

Try http://www.armclub.org.uk/32bit/Where.zip

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

In message <9581917a53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 12 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
>> In message <537a295b6crpcemu-sub@aconet.nl>
>> Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
>> > In article <a98a207a53.George@george/greenfield.tiscali.co.uk>,
>
>> > > However, the RISC OS-Configuration-Screen-Resolution available
>> > > options don't go higher than 1280 x 1924 x 16M x 60Hz for the
>> > > particular Benq MDF I'm using
>> >
>> > That's to do with the maximum pixel rate.
>> >
>> > See http://www.riscosopen.org/forum/forums/10/topics/1624
>> >
>> > I have added these to my MDF and they work:
>>
>> [MDF details snipped]
>>
>> Thanks, Frank: I've done likewise and you're right!
>
> In an earlier post, George said that RPCEmu 0.8.10 / RO 5.17 could
> display 1280 x 1924 x 16M x 60Hz

Sorry, what I actually meant to say was that 1280 x 1024 x 16M x 60Hz
was the highest available display resolution on 0.8.10/5.20, whereas
0.8.10/5.17 will go up to 1824 x 1026 x 16M x 60Hz on my system.

> whereas RPCEmu 0.8.10 / RO 5.20 could
> not. The hardware is emulated by RPCEmu, which is the same version, in
> both cases, so that could not account for the difference.
>
> RO 5.20 'protects' the emulated hardware by setting the value of
> VIDCBandwidthLimit to 2000000000. For a 32 bbp display, that implies a
> pixel rate of 500 MHz, which should not be a problem for the host
> Windows machine, and which is certainly greater than the 148 MHz pixel
> rate, required George's display.
>
> I'm somewhat confused as to what is actually limiting the display.

Be that as it may, amending the pixel rates in the MDF file (from a
max. of 144000 down to 108000 here) has made resolutions above 1280 x
1024 x 16M both visible in the Configuration-Screen options box and
useable.

George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: something odd....

In message <537a7d9375rpcemu-sub@aconet.nl>
Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:

> In article <b76a777a53.George@george/greenfield.tiscali.co.uk>,
> George <george.greenfield@tiscali.co.uk> wrote:
>> On booting up my new installation, I'm getting a 'Insert HardDisc4'
>> request before the desktop displays.
>
> Sounds like something in the boot sequence is trying to run something
> off HardDisk4 rather than HostFS. Check the files in (the directories
> in) $.!Boot.Choices.Boot.
[snip]

Thanks for the advice. I remembered when the problem first appeared -
it was after I'd copied !SparkFS across, either from my 089/402
installation or the 0810/517 one (I forget which, but presumably it
was the former due to the HD4 call). Anyway, deleting that App
restored normality (and the 'Filecore in use' error on Shutdown went
as well).

> If you want to know where in the ROM
> this is, use the command 'Where &FC15C6BC' (provided you have the Where
> tool installed, of course).

That sounds like a useful tool - where (no pun intended) would I get
it?

George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

On 12 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
> In message <537a295b6crpcemu-sub@aconet.nl>
> Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
> > In article <a98a207a53.George@george/greenfield.tiscali.co.uk>,

> > > However, the RISC OS-Configuration-Screen-Resolution available
> > > options don't go higher than 1280 x 1924 x 16M x 60Hz for the
> > > particular Benq MDF I'm using
> >
> > That's to do with the maximum pixel rate.
> >
> > See http://www.riscosopen.org/forum/forums/10/topics/1624
> >
> > I have added these to my MDF and they work:
>
> [MDF details snipped]
>
> Thanks, Frank: I've done likewise and you're right!

In an earlier post, George said that RPCEmu 0.8.10 / RO 5.17 could
display 1280 x 1924 x 16M x 60Hz whereas RPCEmu 0.8.10 / RO 5.20 could
not. The hardware is emulated by RPCEmu, which is the same version, in
both cases, so that could not account for the difference.

RO 5.20 'protects' the emulated hardware by setting the value of
VIDCBandwidthLimit to 2000000000. For a 32 bbp display, that implies a
pixel rate of 500 MHz, which should not be a problem for the host
Windows machine, and which is certainly greater than the 148 MHz pixel
rate, required George's display.

I'm somewhat confused as to what is actually limiting the display.

Incidentally, in http://home.marutan.net/arcemdocs/VIDC20.pdf , which
relates to 'real' hardware, ARM states that the chip is capable of a
maximum 100 MHz pixel rate, not 110 MHz, as mentioned in
http://www.riscosopen.org/wiki/documentation/show/RiscPC%20Hardware

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: something odd....

In article <b76a777a53.George@george/greenfield.tiscali.co.uk>,
George <george.greenfield@tiscali.co.uk> wrote:
> On booting up my new installation, I'm getting a 'Insert HardDisc4'
> request before the desktop displays.

Sounds like something in the boot sequence is trying to run something
off HardDisk4 rather than HostFS. Check the files in (the directories
in) $.!Boot.Choices.Boot.
Is the grey desktop background there yet when the abort occurs? Then
start by looking at $.!Boot.Choices.Boot.Desktop and the files in
$.!Boot.Choices.Boot.Tasks.

> Clicking 'Cancel', and 'Describe' in the ensuing error box gives
> 'Internal error: abort on data transfer at &FC15C6BC', but clicking
> 'Continue' results in a normal-seeming desktop.

Could be because things aren't properly initialised yet for a
'Describe' to function correctly. If you want to know where in the ROM
this is, use the command 'Where &FC15C6BC' (provided you have the Where
tool installed, of course).

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: NetSurf Society 2013 AGM to be rescheduled

On Sat, Aug 10, 2013 at 11:51:04 +0100, Michael Drake wrote:
> The AGM is to be rescheduled due to low attendance.
> The new date and time will be posted here in due course.

Since we've had such issues sorting the AGM out, I have created a doodle.

I will only be considering the votes of society members in the first instance,
however non-members who would like to observe the AGM are welcome to vote too,
just please make it clear that you are not a member when you vote.

The doodle is at: http://www.doodle.com/piqvg6txax26fipg

I will be working out the date/time on the 17th August, so vote now -- banzai!

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

[Rpcemu] 0.8.10/5.20: something odd....

On booting up my new installation, I'm getting a 'Insert HardDisc4'
request before the desktop displays. Clicking 'Cancel', and 'Describe'
in the ensuing error box gives 'Internal error: abort on data transfer
at &FC15C6BC', but clicking 'Continue' results in a normal-seeming
desktop. RPCEmu then behaves normally (including super-stable
networking :-)) until shutdown, when a 'Filecore in use' error
appears.

I've entered (and re-entered)

*configure filesystem hostfs
*configure boot

but the problem persists; any help with diagnosis and cure would be
appreciated. TIA,

George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

In message <537a295b6crpcemu-sub@aconet.nl>
Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:

> In article <a98a207a53.George@george/greenfield.tiscali.co.uk>,
>> However, the RISC OS-Configuration-Screen-Resolution available options
>> don't go higher than 1280 x 1924 x 16M x 60Hz for the particular Benq
>> MDF I'm using
>
> That's to do with the maximum pixel rate.
>
> See http://www.riscosopen.org/forum/forums/10/topics/1624
>
> I have added these to my MDF and they work:
>
[MDF details snipped]

Thanks, Frank: I've done likewise and you're right!

George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

NetSurf could be it.

In my opinion Mozilla is not the organzation it used to be. It doesn't listen to either users or developers. It makes arbitrary changes and requires web developers to cope. This attitude reflects an abberant power imbalance felt by Mozilla between them and their users.

Rather than hope for a change in attitude at Mozilla, I think the org should be replaced with a project which more accurately incarnates progressive ideals. I think NetSurf could well be it. I must say, I am impressed with its project breadth: Amiga and even Atari... that's impressive. I remember that there were ports of Firefox to the GP2X handheld, before Gecko became too obfusticated to port, and looking at these home computer ports I think I see that same spirit. I also like how you are using libraries, as opposed to IBM's XP-COM unqualified disaster. I notice that you are lacking in areas, however, which Mozilla dealt with long ago, with C-based libraries that have been successfully implemented. Your Javascript woes, for example, can be ably handled by the SpiderMonkey engine, as they were in SphereRPG, which used SDL and SpiderMonkey side by side. With respect to HTML 5, I think you may want to question your dependence on it, because with few exceptions the standards process has been taken over by Google and is being biased towards its interests. These interests are not necessarily accessory to a "better web".

I think standardization compliance is a red herring; rather, I think the future lies in passion and leverage of popular values. However it would be a mistake to engage in "browser war" -- people who use Firefox do so because they detest Microsoft, Google, and Apple all. What we want is an alternative to Mozilla and its modus operandi... if the sites and apps we make won't run on other browsers, then they should use ours. Google's aggressive adherents are the real secret to its success... responding to their attitude in kind could pay dividends for Netsurf.

Re: [Rpcemu] MDF and RISC OS 6.2

In article <FD938642-88F3-4120-A893-0D8A5BF56204@hollypops.co.uk>,
Gerald Holdsworth <gerald@hollypops.co.uk> wrote:

> Reading George's problem with his RISC OS 5.20 and the MDFs not
> working, I have a similar problem, which I've never solved. Not sure
> if this is because it is emulated or if RISC OS 6.20 does this anyway
> (as I haven't put this into my real Risc PC yet)...however, I have
> created an MDF (called 'MacBookAir') and created a new directory for
> it (called 'Apple') inside the !Boot->Resources->Configure->Monitors
> directory. However, RISC OS refuses to see it

As far as I know RISC OS 6.20 doesn't look for MDFs in (subdirectories
of) Configure.Monitors but in !Boot.Resources.!VideoRes.Monitors.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] MDF and RISC OS 6.2

Hi all,

Reading George's problem with his RISC OS 5.20 and the MDFs not working, I have a similar problem, which I've never solved. Not sure if this is because it is emulated or if RISC OS 6.20 does this anyway (as I haven't put this into my real Risc PC yet)...however, I have created an MDF (called 'MacBookAir') and created a new directory for it (called 'Apple') inside the !Boot->Resources->Configure->Monitors directory. However, RISC OS refuses to see it - it's not even listed on my list of monitors. I've even taken those three mode definitions that Frank last posted and put them into my Acorn AKF92 MDF (which is what is currently being used), and even they aren't listed.

Am I missing something simple?

(BTW, this MDF works from my RPCemu RISC OS 4.39 setup).

Cheers,

Gerald.

From the MacBook Air of Gerald Holdsworth
www.geraldholdsworth.co.uk
www.hollypops.co.uk

Re: [Rpcemu] Can't get Monitor def file to work under 0.8.10/5.20

In message <27ea267a53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 12 Aug 2013, George <george.greenfield@tiscali.co.uk> wrote:
>
>> First, a massive 'thank you' to Tony Moore for exemplary instructions
>> for upgrading to 0.8.10/5.20
>
> You're welcome.
>
> [snip]
>
>> However, I seem to have hit a glitch with setting the screen
>> resolution. I've copied across the monitor def files from a
>> 0.8.10/5.17 installation and put them in
>> !Boot.Resources.Configure.Monitors. However, the RISC
>> OS-Configuration-Screen-Resolution available options don't go higher
>> than 1280 x 1924 x 16M x 60Hz for the particular Benq MDF I'm using,
>> whereas the same MDF in 0.8.10/5.17 gives the complete range up to
>> 1920 x 1050, as it should, including the 1824 x 1026 'hand-made'
>> option actually in use.
>
> VIDCBandwidthLimit is set in !Boot.Choices.Boot.PreDesk.Configure.!Run
> Is it different in your 0.8.10/5.17 installation?

It's identical, apart from the 520 version having an 'X' between 'Set
Alias$VIDCBandLimit' and 'VIDCBandwidthLimit' in the first line, which
the 517 version didn't. The contents:

Set Alias$VIDCBandLimit X VIDCBandwidthLimit 2000000000 2000000000
2000000000
VIDCBandLimit
Set PreDesk$Configure <Obey$Dir>.Monitor
/BootResources:Configure.ClrMonitor
/<PreDesk$Configure>

Deleting the 'X' made no difference. Nor did amending the accompanying
'Monitor' obey file with the required WimpMode X and Y values.

> If the number of
> colours is reduced, can you then see your 1824 x 1026 mode definition?

No.

George

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu