Re: Logging of Changes

Thank you for the clarification/explanation!

Best wishes,

John

--
| John Williams
| johnrw@ukgateway.net

Re: Logging of Changes

On Sat, Jan 27, 2018 at 09:50:28AM +0000, John Williams wrote:
>
> Why are there often series of changes which are not specifically logged at:
>
> http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
>
> like in the last 13 builds. Does the information appear somewhere else?

The "gap" builds are simply those triggered by other components
(libraries). There are no code changes in NetSurf itself so no entry
on this list.

Most of the 13 you identify stem from recent fixes and improvements to
librufl, libcss and toolchain updates. Though you may also see builds
triggered from the CI system itself because I have been ensuring the
system can successfully perform repeat builds.


>
> John
>
> --
> | John Williams
> | johnrw@ukgateway.net
>
>

--
Regards Vincent
http://www.kyllikki.org/

Logging of Changes

Why are there often series of changes which are not specifically logged at:

http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes

like in the last 13 builds. Does the information appear somewhere else?

John

--
| John Williams
| johnrw@ukgateway.net

[gccsdk] Wimpslot oddity

I have a working port of telegram-cli, but compiling with either 4/1/2 or
4/7/4 and when the static binary runs, it doesn't complain about the
wimpslot, but helps itself to 206112000 bytes.
I have never seen a (largish) binary work without a wimpslot specified
before.

I noticed the wimpslot for ld climbing to about 17MB and I approximate that
should be the ballpark wimpslot for the binary to run.

Though the linux equivalent will be using shared libs it is only running
with 2.5MB system memory.

I haven't got a working shared library built yet (TEXTREL) but the shared
version needed an enormous wimpslot, before displaying the error.

I have tryed bypassing the inner_main, loop, netloop functions for the
shell but it only dropped the memory usage by KB's not MB's

Going further back in the main() I only achieved a machine crash.
I am putting in a
while(1) {
}
to get it to stay running so I can observe changes to the memory.
I'd welcome any other ideas, or general info about memory.

Ron M.

Regarding mail holdups, I have been contacted by zoho support, and they
have taken steps to allow posts from this mailing list to get through
greylisting, so I'll be checking this one. A better response than is
possible from gmail, regarding long term builtin spamlisting problems.



_______________________________________________
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] RPCEmu pre release test version 0.8.100

I suspect this may have been asked before but are there any plans to merge the functionality of Arculator and RPCEmu? I wonder how different the ARM2/3 based machines are to the RPC based ones. I've found myself trying tech-demos on RPCEmu and then separately on Arculator due to compatibility issues and I think it would be great to have an "all-in-one" solution, both for existing software and development.

On 22 January 2018 at 17:12, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

On Tue, Jan 02, 2018 at 03:01:37AM +0000, J Percival wrote:
>    Hi, I did a little more experimentation to see exactly at what point
>    RiscOS locks up when running the universal-boot-2 sequence under the
>    recompiler.
>    It seems to be on execution of !Boot.Utils.BootVars so probably a bug in
>    the recompiler code.

To let you know we have reproduced this and are investigating. Initial
looks says it's not a quick fix (nor a regression in 0.8.100), as such
it's unlikely to be fixed before the next release version and the
workaround of choosing 'StrongARM' is probably a good idea here.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] BASIC mouse-pointer issue

Thanks for the workaround!

On 22 January 2018 at 17:08, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

On Sat, Jan 20, 2018 at 03:34:29PM +0000, J Percival wrote:
>    RPCEmu Version: 0.8.15 and later
>    Config: RPC-StrongARM/16MB/No VRAM/Sound Enabled
>    I'm not sure if this is an emulator bug or not but I've noticed that the
>    BASIC "MOUSE TO" command under RO3.71 changes the size of the pointer
>    instead of its location - specifically the 'x' argument has no effect and
>    the 'y' argument modifies the pointer's height.
>    To reproduce:
>    MOUSE ON:MOUSE TO 0,20

Thanks for this report, I've been able to reproduce it and am
investigating. Oddly the reduction in the size of the pointer is related
to the amount that is offscreen when moving TO the Y coord, e.g. MOUSE TO
0, 2 means you have an even smaller pointer.

This only affects 'Follow host mouse' mode, so if you need a temporary
workaround, use 'Capture Mouse' mode by deselecting 'Follow host mouse'
(0.8.100) or chosing Capture Mouse (0.8.15).

Peter


--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

On Tue, Jan 02, 2018 at 03:01:37AM +0000, J Percival wrote:
> Hi, I did a little more experimentation to see exactly at what point
> RiscOS locks up when running the universal-boot-2 sequence under the
> recompiler.
> It seems to be on execution of !Boot.Utils.BootVars so probably a bug in
> the recompiler code.

To let you know we have reproduced this and are investigating. Initial
looks says it's not a quick fix (nor a regression in 0.8.100), as such
it's unlikely to be fixed before the next release version and the
workaround of choosing 'StrongARM' is probably a good idea here.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] BASIC mouse-pointer issue

On Sat, Jan 20, 2018 at 03:34:29PM +0000, J Percival wrote:
> RPCEmu Version: 0.8.15 and later
> Config: RPC-StrongARM/16MB/No VRAM/Sound Enabled
> I'm not sure if this is an emulator bug or not but I've noticed that the
> BASIC "MOUSE TO" command under RO3.71 changes the size of the pointer
> instead of its location - specifically the 'x' argument has no effect and
> the 'y' argument modifies the pointer's height.
> To reproduce:
> MOUSE ON:MOUSE TO 0,20

Thanks for this report, I've been able to reproduce it and am
investigating. Oddly the reduction in the size of the pointer is related
to the amount that is offscreen when moving TO the Y coord, e.g. MOUSE TO
0, 2 means you have an even smaller pointer.

This only affects 'Follow host mouse' mode, so if you need a temporary
workaround, use 'Capture Mouse' mode by deselecting 'Follow host mouse'
(0.8.100) or chosing Capture Mouse (0.8.15).

Peter


--
Peter Howkins
peter.howkins@marutan.net

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

Re: [NetSurf 0002266]: URLs about:welcome, about:credits and about:licence don't load localized version when the corresponding files are available

On 21 Jan, NetSurf Bug Tracker <help@netsurf-browser.org> wrote:
> The following issue has been RESOLVED.
> ======================================================================
> http://bugs.netsurf-browser.org/mantis/view.php?id=2266
> ----------------------------------------------------------------------
> (0001714) John-Mark Bell (administrator) - 2018-01-21 14:29
> http://bugs.netsurf-browser.org/mantis/view.php?id=2266#c1714
> ----------------------------------------------------------------------
> Fixed in 4302. sprintf approach is fine, but I disliked the assumption that
> ro_gui_default_language() returned a string that was 2 characters long, so
> the preceding length calculation has been updated to take account of the
> actual length of the language identifier.

I'd, perhaps wrongly, assumed that ro_gui_default_language() always returned
an ISO3166-1 country code, and hence the 2 character length was OK to
hardcode.

Regardless your mods look fine to me - thanks for integrating this,
Sprow.

PS: Can't seem to add comments to tickets once they're resolved.

[Rpcemu] BASIC mouse-pointer issue

RPCEmu Version: 0.8.15 and later

Config: RPC-StrongARM/16MB/No VRAM/Sound Enabled

I'm not sure if this is an emulator bug or not but I've noticed that the BASIC "MOUSE TO" command under RO3.71 changes the size of the pointer instead of its location - specifically the 'x' argument has no effect and the 'y' argument modifies the pointer's height.

To reproduce:

MOUSE ON:MOUSE TO 0,20

Kind Regards,

James

[gccsdk] Special case made for zlib -requires DIR set

I posted this problem yesterday, but though the post in the archive for
January, I haven't received it back so I cant follow the same thread.
Is anyone receiving posts?

After searching the configure file for zlib.h, I found that they have made
a special case and it required --with-zlib=$GCCSDK_INSTALL_ENV otherwise
it wont look.
I have my doubts wether telegram-cli will be suitable for the autobuilder,
As I've run into a lot of things needing manual intervention in the
makefile.
I may need to add in libconfig to obtain the internal library makefiles,
if the CYGWIN readme is anything to go by.

Autobuilder has output the root makefile, but as is, it is not enough for
the build, missing rules and the LD variables are including native linux
path which I dont think will ever fly, so some editting is needed.

Thankfully the makefile is only one page in size.

Ron M.



_______________________________________________
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

[gccsdk] zlib.h not found suitable

I'm having a go at getting telegram.cli working and hopefully in the
autobuilder.
A dependancy libevent from testing seems to have built OK, but would be
good if someone knowledgeable about pthreads etc could give it a look and
include it in the autobuilder.
There is an existing Event.h from OSLib which doesn't appear to conflict.

A problem with telegram-cli is it is only available from git as a zip and
on my local (ftp) network anyway, the autobuilder wont load it unless I
convert it to a tar/xx first.

Having met the dependancies I then get an error to do with zlib.h
It is in the same env/include directory as the new event.h and must be to
do with version, though the current 1.2.8 was installed recently.

The tail of the failure log:

checking for stdint.h... yes
checking for unistd.h... yes
checking event2/event.h usability... yes
checking event2/event.h presence... yes
checking for event2/event.h... yes
checking for openssl/ssl.h in /home/ron/gccsdk/env... yes
checking whether compiling and linking against OpenSSL works... yes
checking if zlib is wanted... yes
checking for inflateEnd in -lz... yes
checking zlib.h usability... no
checking zlib.h presence... no
checking for zlib.h... no
configure: error: No zlib found
Autobuilder: Running make command: /home/ron/gccsdk/env/ro-make
Autobuilder: No known build method

Ron M.



_______________________________________________
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] RPCEmu pre release test version 0.8.100

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> I will need the MDF for this, also what boot sequence disc setup are you
> using, is it your own? I've not heard of that MDF before.

I think the MDF was put together over the years with
input from V-RPC-Adjust and a generic VESA MDF IIRC.

Boot sequence is fairly standard 4.02 with all the
ROM patches and a few special modules. I think it will
be sensible if I try plain RO5 with plain !Boot first, this
will be easier to use as a base to reproduce the problem.

Bets accepted if the problem also happens with RO5 :-)

> Also do you know if it was also an issue in 0.8.15?

Difficult to test, because it does not scale the window
content, so the mode changer is not easily acessible...
will try later.

But I managed to crash RPCEmu 0.8.15 when switching into
fullscreen when booting was not completely done (RO4 splash
still visible). Maybe it is an old concurrency problem?

Have fun
Steffen

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

On Thu, Jan 04, 2018 at 01:13:58PM +0100, Steffen Huber wrote:
> I had a go at testing 0.8.100.
>
> I was no longer able to provoke that crash. Thanks for fixing!

Good.

> However, I can half-reliably crash 0.8.100 by doing the following
> (Recompiler, StrongARM, 128MiB, RISC OS 4.02):
> - switch RPCEmu into fullscreen
> - change screenmode to "2560x1440 RPCEmu" 256 colours
> - try to change screenmode to "1920x1080" 32k colour
> - fatal crash
>
> I had it once that it already crashed when changing to 2560x1440.
> I had it once that it did not crash when switching to 1920x1080,
> but it crashed later when switching between the two screenmodes.
>
> I have collected the debug files that Windows provides. Let me know
> if you need anything (the MDF?) or if it is also reproducable for
> you. rpclog.txt says nothing.

I will need the MDF for this, also what boot sequence disc setup are you
using, is it your own? I've not heard of that MDF before.

Also do you know if it was also an issue in 0.8.15?

>
> Another problem:
> - fullscreen, change screenmode to 2560x1440, go back to window mode,
> go back fullsctreen -> no longer scaled to available res, but
> unscaled
>
> Currently on a dual screen setup in Windows with 2x 1920x1200.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

I had a go at testing 0.8.100.

> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> Please test this version as thoroughly as possible, and if you previously
> reported an issue with 0.8.99 and it is listed below, please test and
> confirm it is fixed.
>
> - Crash bug caused by dragging window to bottom of screen fixed.

I was no longer able to provoke that crash. Thanks for fixing!

However, I can half-reliably crash 0.8.100 by doing the following
(Recompiler, StrongARM, 128MiB, RISC OS 4.02):
- switch RPCEmu into fullscreen
- change screenmode to "2560x1440 RPCEmu" 256 colours
- try to change screenmode to "1920x1080" 32k colour
- fatal crash

I had it once that it already crashed when changing to 2560x1440.
I had it once that it did not crash when switching to 1920x1080,
but it crashed later when switching between the two screenmodes.

I have collected the debug files that Windows provides. Let me know
if you need anything (the MDF?) or if it is also reproducable for
you. rpclog.txt says nothing.

Another problem:
- fullscreen, change screenmode to 2560x1440, go back to window mode,
go back fullsctreen -> no longer scaled to available res, but
unscaled

Currently on a dual screen setup in Windows with 2x 1920x1200.

Steffen

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

Hi, I did a little more experimentation to see exactly at what point RiscOS locks up when running the universal-boot-2 sequence under the recompiler.

It seems to be on execution of !Boot.Utils.BootVars so probably a bug in the recompiler code. This happens when run from ADFS as well so doesn't appear to be HostFS related after all.

Kind Regards,

James

On 2 January 2018 at 01:18, J Percival <perciv.js@gmail.com> wrote:

Hi there! Apologies for not providing more details.

Host OS: Windows 10 64-Bit (Intel i5 CPU)

Emulated OS: RiscOS 3.71

Settings: Default (2MB VRAM, 32MB RAM)

After more in-depth testing, it appears to be an issue with the UniBoot2 archive from https://www.retro-kit.co.uk/user/custom/Software/Acorn/RISCOS/UniBoo2.zip when !Boot or !Run gets executed whether it be at boot time, via display of the directory or directly.

To reproduce:

Install fresh copy of RPCEmu 0.8.100 and add RO3.71 ROM

Add UniBoot2 to the root of HostFS

Run !Boot or !Run by any method

Behaviour for each HW configuration (apart from Phoebe) is as follows:

Interpreter

--------------

ARM610/710/StrongARM/A7000/A7000+: Works

ARM810: RPCEmu Fatal Error - Bad LDRH/STRH opcode 0000ADB8

Recompiler

----------------

StrongARM: Works
ARM610/710/A7000/A7000+: RiscOS locks up (although the mouse pointer *usually* remains working)
ARM810: Some garbled RiscOS error box that just recurs if you try to cancel it

- rpc.cfg -

===============================================================

[General]
bridgename=rpcemu
cdrom_enabled=1
cdrom_iso=
cdrom_type=0
cpu_idle=0
ipaddress=172.31.0.1
macaddress=
mem_size=32
model=RPC610
mouse_following=1
mouse_twobutton=0
network_type=off
refresh_rate=60
sound_enabled=0
stretch_mode=1
username=
vram_size=2
===============================================================

- rpclog.txt -

===============================================================
localtime: 2018-01-02 01:07:31
   gmtime: 2018-01-02 01:07:31
RPCEmu 0.8.100 VERY SECRET EDITION [DYNAREC NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.9.2
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 2
OS: ProductType = 1
OS: SuiteMask = 0x100
OS: ServicePackMajor = 0
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 48
QT5: 5.6.2
Number of screens: 1
Primary screen: \\.\DISPLAY1
Information for screen: \\.\DISPLAY1
 Resolution: 1920 x 1080
 Colour depth: 32
Working Directory: D:\Emu\Acorn\RPCEmu_Test
Host CD/DVD Drive (F:)romload: Loaded 'risocs-3.71.rom' 4194304 bytes
romload: Total ROM size 4 MB
romload: ROM patch applied: 8MB VRAM RISC OS 3.71
plt_sound: qt5 Audio Device: Speakers (Realtek High Definition Audio)
plt_sound: qt5 Audio Codecs Supported: 1
0: audio/pcm
plt_sound: qt5 Audio SampleRates Supported: 10
0: 8000
1: 11025
2: 16000
3: 22050
4: 32000
5: 44100
6: 48000
7: 88200
8: 96000
9: 192000
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
RPCEmu: Machine reset
RPCEmu: Machine reset complete
HostFS: Registration request version 3 accepted
===============================================================

Kind Regards,

James

On 1 January 2018 at 15:59, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

On Sun, Dec 31, 2017 at 02:05:45PM +0000, J Percival wrote:
>    Also just noticed that HostFS access crashes the recompiler except for
>    CPU=StrongARM but it's not a regression as it does so in 0.8.15 as well.

Erm, this doesn't happen here, as such let's try to reproduce it.

- What do you mean by crash? Emulator exits? with or without error
  message? emulator stops running (lock up)? Error reported in RISC OS?
  something else?
- At which point does the 'crash' happen, on boot? on accessing a
  particular file? something else?
- Which version of RISC OS are you running?
- What files have you put in HostFS, a boot sequence? which? something
  else?
- What settings are you using for, memory, vram?

Can you also post your rpc.cfg and rpclog.txt files.

>    Think you must already be aware of it

This isn't directed at you particulaly, but to all users of rpcemu.

We really really need people to report all the bugs they find, there are
so many potential configurations and pieces of software out there that we
can't run everything, as such the chances are that we're not aware of it.

But every good bug report stands a very good chance of being fixed which
makes everyone's life a little better.

Even if you figure out a workaround (e.g. change setting to something
else) please still report the original issue.

> is there a list of known issues somewhere?

There isn't at the moment, I'll look into adding one.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

Hi there! Apologies for not providing more details.

Host OS: Windows 10 64-Bit (Intel i5 CPU)

Emulated OS: RiscOS 3.71

Settings: Default (2MB VRAM, 32MB RAM)

After more in-depth testing, it appears to be an issue with the UniBoot2 archive from https://www.retro-kit.co.uk/user/custom/Software/Acorn/RISCOS/UniBoo2.zip when !Boot or !Run gets executed whether it be at boot time, via display of the directory or directly.

To reproduce:

Install fresh copy of RPCEmu 0.8.100 and add RO3.71 ROM

Add UniBoot2 to the root of HostFS

Run !Boot or !Run by any method

Behaviour for each HW configuration (apart from Phoebe) is as follows:

Interpreter

--------------

ARM610/710/StrongARM/A7000/A7000+: Works

ARM810: RPCEmu Fatal Error - Bad LDRH/STRH opcode 0000ADB8

Recompiler

----------------

StrongARM: Works
ARM610/710/A7000/A7000+: RiscOS locks up (although the mouse pointer *usually* remains working)
ARM810: Some garbled RiscOS error box that just recurs if you try to cancel it

- rpc.cfg -

===============================================================

[General]
bridgename=rpcemu
cdrom_enabled=1
cdrom_iso=
cdrom_type=0
cpu_idle=0
ipaddress=172.31.0.1
macaddress=
mem_size=32
model=RPC610
mouse_following=1
mouse_twobutton=0
network_type=off
refresh_rate=60
sound_enabled=0
stretch_mode=1
username=
vram_size=2
===============================================================

- rpclog.txt -

===============================================================
localtime: 2018-01-02 01:07:31
   gmtime: 2018-01-02 01:07:31
RPCEmu 0.8.100 VERY SECRET EDITION [DYNAREC NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.9.2
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 2
OS: ProductType = 1
OS: SuiteMask = 0x100
OS: ServicePackMajor = 0
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 48
QT5: 5.6.2
Number of screens: 1
Primary screen: \\.\DISPLAY1
Information for screen: \\.\DISPLAY1
 Resolution: 1920 x 1080
 Colour depth: 32
Working Directory: D:\Emu\Acorn\RPCEmu_Test
Host CD/DVD Drive (F:)romload: Loaded 'risocs-3.71.rom' 4194304 bytes
romload: Total ROM size 4 MB
romload: ROM patch applied: 8MB VRAM RISC OS 3.71
plt_sound: qt5 Audio Device: Speakers (Realtek High Definition Audio)
plt_sound: qt5 Audio Codecs Supported: 1
0: audio/pcm
plt_sound: qt5 Audio SampleRates Supported: 10
0: 8000
1: 11025
2: 16000
3: 22050
4: 32000
5: 44100
6: 48000
7: 88200
8: 96000
9: 192000
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
RPCEmu: Machine reset
RPCEmu: Machine reset complete
HostFS: Registration request version 3 accepted
===============================================================

Kind Regards,

James

On 1 January 2018 at 15:59, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

On Sun, Dec 31, 2017 at 02:05:45PM +0000, J Percival wrote:
>    Also just noticed that HostFS access crashes the recompiler except for
>    CPU=StrongARM but it's not a regression as it does so in 0.8.15 as well.

Erm, this doesn't happen here, as such let's try to reproduce it.

- What do you mean by crash? Emulator exits? with or without error
  message? emulator stops running (lock up)? Error reported in RISC OS?
  something else?
- At which point does the 'crash' happen, on boot? on accessing a
  particular file? something else?
- Which version of RISC OS are you running?
- What files have you put in HostFS, a boot sequence? which? something
  else?
- What settings are you using for, memory, vram?

Can you also post your rpc.cfg and rpclog.txt files.

>    Think you must already be aware of it

This isn't directed at you particulaly, but to all users of rpcemu.

We really really need people to report all the bugs they find, there are
so many potential configurations and pieces of software out there that we
can't run everything, as such the chances are that we're not aware of it.

But every good bug report stands a very good chance of being fixed which
makes everyone's life a little better.

Even if you figure out a workaround (e.g. change setting to something
else) please still report the original issue.

> is there a list of known issues somewhere?

There isn't at the moment, I'll look into adding one.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

On Sun, Dec 31, 2017 at 02:05:45PM +0000, J Percival wrote:
> Also just noticed that HostFS access crashes the recompiler except for
> CPU=StrongARM but it's not a regression as it does so in 0.8.15 as well.

Erm, this doesn't happen here, as such let's try to reproduce it.

- What do you mean by crash? Emulator exits? with or without error
message? emulator stops running (lock up)? Error reported in RISC OS?
something else?
- At which point does the 'crash' happen, on boot? on accessing a
particular file? something else?
- Which version of RISC OS are you running?
- What files have you put in HostFS, a boot sequence? which? something
else?
- What settings are you using for, memory, vram?

Can you also post your rpc.cfg and rpclog.txt files.

> Think you must already be aware of it

This isn't directed at you particulaly, but to all users of rpcemu.

We really really need people to report all the bugs they find, there are
so many potential configurations and pieces of software out there that we
can't run everything, as such the chances are that we're not aware of it.

But every good bug report stands a very good chance of being fixed which
makes everyone's life a little better.

Even if you figure out a workaround (e.g. change setting to something
else) please still report the original issue.

> is there a list of known issues somewhere?

There isn't at the moment, I'll look into adding one.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

On Sun, Dec 31, 2017 at 12:56:59PM +0000, J Percival wrote:
> All fixes mentioned on the webpage seem to work except for the
> Alt-Handling. The menus are no longer accessed accidentally but it seems
> the key is now also ignored in the emulated system.
> I noticed this when trying to strafe in !Doom but it's easier to see just
> by pressing F12 from RiscOS and hitting Alt-A which should produce an 'ae'
> character.

OK, I think I have a fix for this, when blocking the alt effect in windows
I wasn't also passing the key onto the emulator.

I've not got Doom to hand to test, but the 'ae' thing is working.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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