Re: [Rpcemu] HDF file format

On Fri, 24 Dec 2021, Peter Howkins wrote:

> On Sun, 19 Dec 2021 at 14:34, Justin F <gerph@gerph.org> wrote:
>
> There's no justification given in the comments, so I tried to work out a
> reason for it.
>
>
> It was a bug, one that we now have to work around to not make sure lots of people's disc
> images don't just stop working.

Thanks - I'll update my comments in the code. Losing 512 bytes on a HD
image really isn't a big deal anyhow :-)

--
Charles Justin Ferguson

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

Dark Mode

Hi guys!
I've recently implemented dark mode for Netsurf. Basically inverting white and black colors to avoid eye-strain. There are 3 options - None(by default), Preserve Colors(tries to invert just black and white, avoiding inverting bright colors), Full(just inverts everything). It works well for me, and I'm using this solution on all machines I've got NSGTK3 built. Here is the patch: https://gitlab.com/megastallman/netsurf_dark_mode/-/raw/main/DarkMode.patch

But still there is a problem with GTK3: https://ibb.co/cbXTm8h
The combobox behind the "Dark Mode" label looks empty before I click it, thus options are saved well and persist through the browser launches. Also, probably we need to make "Netsurf Preferences" form bigger to fit all controls.
Please help me fix those issues, and probably provide some upstreaming guidelines.

Re: [Rpcemu] HDF file format

On Sun, 19 Dec 2021 at 14:34, Justin F <gerph@gerph.org> wrote:

There's no justification given in the comments, so I tried to work out a
reason for it.

It was a bug, one that we now have to work around to not make sure lots of people's disc images don't just stop working.

Peter

Scrolling to found text (was: Bug reporting pause)

On 23 Dec 2021, lists@bazleyfamily.co.uk wrote:

> Were you by any chance trying to search Wikipedia pages?

Good question, Harriet, but no, it's on quite ordinary pages that I have
experienced this for a while now. And if others (you, Dave H,...) don't
see it there must be some oddity in some of my setups. I have now had a
look at F4 search in these three cases:

Pi 4, [ROOL ePic] OS 5.24, NetSurf 3.8 (Dev CI #3418) -- result normal

Pi 400, [Cloverleaf] OS 5.29 (18-Jul-2021), NetSurf 3.11 (Dev) -- result
abnormal in that scrolling doesn't happen, plus several of the found
strings are not even highlighted.

ARMX6, [R-Comp] OS 5.29 (03-Nov-2020), NetSurf 3.11 (Dev CI #5313 --
result abnormal as I originally described.

So, if it's an effect involving both 3.11 Dev versions _and_ something
either in 5.29 or in those setups, then I think I should leave the bug
report up for further probing.

Dave asks for a specimen URL. Any simple page shows the effect I describe
on those machines. For example use the ROOL forum search to list a bunch
of postings and then step through them with NetSurf F4 quoting the same
search string.

--
Bernard
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

On 23 Dec 2021 as I do recall,
David Higton wrote:

> In message <232d559f59.boase@boase.myzen.co.uk>
> Bernard Boase <b.boase@bcs.org> wrote:
>
> > On 23 Dec 2021, lists@bazleyfamily.co.uk wrote:
> >
> > > That's interesting - I just tried again (same computer, same network,
> > > same incarnation of NetSurf; I hadn't quit the program or rebooted) and
> > > this time it worked. So whatever the issue is, it's clearly
> > > intermittent, and probably intermittent somewhere further down the line.
> >
> > Agreed. Access to Mantis appears to have been restored here today.
> >
> > Does anyone agree with my report there #0002834?
>
> I cannot reproduce the problem, and I've added a note to that effect.
>
I wondered if it was something to do with searches in scrolling frames -
see also https://bugs.netsurf-browser.org/mantis/view.php?id=2740

Were you by any chance trying to search Wikipedia pages?

--
Harriet Bazley == Loyaulte me lie ==

He who always ploughs a straight furrow is in a rut.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

In message <232d559f59.boase@boase.myzen.co.uk>
Bernard Boase <b.boase@bcs.org> wrote:

> On 23 Dec 2021, lists@bazleyfamily.co.uk wrote:
>
> > That's interesting - I just tried again (same computer, same network,
> > same incarnation of NetSurf; I hadn't quit the program or rebooted) and
> > this time it worked. So whatever the issue is, it's clearly
> > intermittent, and probably intermittent somewhere further down the line.
>
> Agreed. Access to Mantis appears to have been restored here today.
>
> Does anyone agree with my report there #0002834?

I cannot reproduce the problem, and I've added a note to that effect.

Perhaps you need to tell us a specimen URL?

David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

In message <599f304824dave@triffid.co.uk>
Dave <dave@triffid.co.uk> wrote:

> In article <be8ffe9e59.harriet@bazleyfamily.co.uk>,
> Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
>
> > I haven't seen any posts on this list since the first of December.
>
> > (And I can't access that domain either....)
>
> Two from Dec 01 Netsurf for Palm OS. One from Dec 22 Scroll wheel
> support. Four from Dec 22 Bug reporting pause. One from Dec 23 Bug
> reporting pause. (Harriet).

Yes, I got all those too.

David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

On 23 Dec 2021, lists@bazleyfamily.co.uk wrote:

> That's interesting - I just tried again (same computer, same network, same
> incarnation of NetSurf; I hadn't quit the program or rebooted) and this
> time it worked. So whatever the issue is, it's clearly intermittent, and
> probably intermittent somewhere further down the line.

Agreed. Access to Mantis appears to have been restored here today.

Does anyone agree with my report there #0002834?

--
Bernard
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

In article <be8ffe9e59.harriet@bazleyfamily.co.uk>,
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
> On 22 Dec 2021 as I do recall,
> Bernard Boase wrote:

> > Over the last few days,I am not getting any connection to
> > https://bugs.netsurf-browser.org/mantis/
> >
> > Anyone know what's being done?
> >
> > (This is the second time I have tried posting this question. Where did
> > my first post of 15 December get to, I wonder? And it was not
> > repeated back to me by the mailing list.)
> >

> I haven't seen any posts on this list since the first of December.

> (And I can't access that domain either....)

Two from Dec 01 Netsurf for Palm OS.
One from Dec 22 Scroll wheel support.
Four from Dec 22 Bug reporting pause.
One from Dec 23 Bug reporting pause. (Harriet).

Dave

--

Dave Triffid
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

On 22 Dec 2021 as I do recall,
David Higton wrote:

> In message <be8ffe9e59.harriet@bazleyfamily.co.uk>
> Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
>
> > On 22 Dec 2021 as I do recall,
> > Bernard Boase wrote:
> >
> > > Over the last few days,I am not getting any connection to
> > > https://bugs.netsurf-browser.org/mantis/

[snip]

> > I haven't seen any posts on this list since the first of December.
> >
> > (And I can't access that domain either....)
>
> I haven't seen a post on this list for a while, until today, and there
> isn't a post from Bernard on the 15th.
>
> But I got straight into Mantis, twice (including just now), using the
> current version of NetSurf.
>
That's interesting - I just tried again (same computer, same network,
same incarnation of NetSurf; I hadn't quit the program or rebooted) and
this time it worked. So whatever the issue is, it's clearly
intermittent, and probably intermittent somewhere further down the line.

--
Harriet Bazley == Loyaulte me lie ==

Profanity is the one language all programmers know best.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

In message <be8ffe9e59.harriet@bazleyfamily.co.uk>
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

> On 22 Dec 2021 as I do recall,
> Bernard Boase wrote:
>
> > Over the last few days,I am not getting any connection to
> > https://bugs.netsurf-browser.org/mantis/
> >
> > Anyone know what's being done?
> >
> > (This is the second time I have tried posting this question. Where did my
> > first post of 15 December get to, I wonder? And it was not repeated back
> > to me by the mailing list.)
> >
>
> I haven't seen any posts on this list since the first of December.
>
> (And I can't access that domain either....)

I haven't seen a post on this list for a while, until today, and there
isn't a post from Bernard on the 15th.

But I got straight into Mantis, twice (including just now), using the
current version of NetSurf.

Sorry this muddies the waters because my observations don't match yours,
but I hope it helps. Try a different browser, try using a mobile phone
on its network's data 'cos it will be a different path...

David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

On 22 Dec 2021 as I do recall,
Bernard Boase wrote:

> Over the last few days,I am not getting any connection to
> https://bugs.netsurf-browser.org/mantis/
>
> Anyone know what's being done?
>
> (This is the second time I have tried posting this question. Where did my
> first post of 15 December get to, I wonder? And it was not repeated back
> to me by the mailing list.)
>

I haven't seen any posts on this list since the first of December.

(And I can't access that domain either....)


--
Harriet Bazley == Loyaulte me lie ==

When you breathe you inspire; when you do not breathe, you expire.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Bug reporting pause

> (This is the second time I have tried posting this question. Where
> did my first post of 15 December get to, I wonder? And it was not
> repeated back to me by the mailing list.)

I searched my back mail for the last nine or ten weeks for
"bugs.netsurf-browser.org" and this message was the only hit, so it
didn't make it to me via the list either. At least, assuming you
mentioned that domain in the older posting too.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Bug reporting pause

Over the last few days,I am not getting any connection to
https://bugs.netsurf-browser.org/mantis/

Anyone know what's being done?

(This is the second time I have tried posting this question. Where did my
first post of 15 December get to, I wonder? And it was not repeated back
to me by the mailing list.)

--
Bernard
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Scroll wheel support

Dear developers,

This may have been raised before, but I can't find anything about it.
If a page in NetSurf has its own scroll bar, i.e. not a RISC OS scroll bar,
then it won't react on the scroll wheel, at least not here. The funny thing
is that if I control the same page in NetSurf from my Windows computer
through VNC, then it does react on the scroll wheel of that computer.
Now, what is that?

4té, RISC OS 5.29
NetSurf 3.11 (Dev CI #5318)

Kind regards,
Paul Sprangers
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: [Rpcemu] HDF file format

If I recall correctly, the original implementation had an off-by-one, which was corrected in a backwards-compatible way later.

On 19 December 2021 16:04:53 GMT, Gerald Holdsworth <gerald@hollypops.co.uk> wrote:

That's pretty much how I do it with Disc Image Manager - I read where the header should be and if it isn't valid, try again 512 bytes later.

On 19/12/2021, 14:34, "Justin F" <rpcemu-bounces@riscos.info on behalf of gerph@gerph.org> wrote:

    Hiya,

    I've been implementing a fake block device driver in Pyromaniac and found 
    that I was unable to access the hard disc files used by RPCEmu. All I was 
    doing was the (I thought) most obvious solution of treating the disc file 
    as a raw sequence of bytes. That's not how the HDF works, and from reading 
    the ide.c source in loadhd and a clue from David Thomas, I see that it 
    does some jumping around to decide whether it should skip 512 bytes at the 
    start of the file.

    There's no justification given in the comments, so I tried to work out a 
    reason for it. Other than 'leaving space for a potential header in the 
    future, but still working with raw disc dumps', I couldn't come up with 
    one. It would be handy if such things were described, so in my 
    implementation I've left some commentary of this to explain it in the 
    future. I offer that code and commentary in case it helps someone to 
    improve the existing RPCEmu (ie someone could explain why this juggling is 
    done), or someone can explain where it's wrong and I can update my code 

    This is python code, and it's based an an existing BlockData class which 
    provides the guarded access to the disc image between a given offset and 
    size:
    class HDFBlockData(BlockData):
        """
        Handle a block file for a HDF file, as used by RPCEmu.

        These files are based around the storage of a harddisc image as written by
        the controller in RPCEmu using the parameters stored in the FileCore
        disc record at the start of the disc (disc address &C00). However, there is
        the potential for all the disc data to be offset by 512 bytes.

        The algorithm basically allows the HDF reader to read a raw FileCore image
        if one has been given, but defaults to the image being at offset 512.

        The result is that newly created discs will have the 512 byte header.
        Existing discs which skip a 512 byte header will be just fine.
        Existing, and newly ripped, discs that are just a dump of the disc contents
        will be fine.

        There's a risk that another format might have data in these low sectors but
        then the chance of those discs being supplied to RPCEmu is low, so this is
        probably reasonable.

        The probable reason for this offset was that some header containing metadata
        could be included in the future. However, no such metadata is used or present
        at the current time.
        """

        def __init__(self, *args, **kwargs):
            super(HDFBlockData, self).__init__(*args, **kwargs)

            # First read some data from the start of the file.
            sector_c00 = bytearray(self.read(DiscTransfer(address=0xc00, size=0x200), 0x200))
            sector_e00 = bytearray(self.read(DiscTransfer(address=0xe00, size=0x200), 0x200))

            if len(sector_c00) < 0x200 or len(sector_e00) < 0x200:
                # This disc is short, so we'll do no manipulation at all.
                return

            secspertrack_c00 = sector_c00[0x1c1]
            heads_c00 = sector_c00[0x1c2]
            secspertrack_e00 = sector_e00[0x1c1]
            heads_e00 = sector_e00[0x1c2]

            offset = 0
            if secspertrack_e00 != 0 and heads_e00 != 0:
                # The two fields we're using as our basis are valid at offset 512. So
                # we use that. So there is a disc record here, we'll use it
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] HDF file format

That's pretty much how I do it with Disc Image Manager - I read where the header should be and if it isn't valid, try again 512 bytes later.

On 19/12/2021, 14:34, "Justin F" <rpcemu-bounces@riscos.info on behalf of gerph@gerph.org> wrote:

Hiya,

I've been implementing a fake block device driver in Pyromaniac and found
that I was unable to access the hard disc files used by RPCEmu. All I was
doing was the (I thought) most obvious solution of treating the disc file
as a raw sequence of bytes. That's not how the HDF works, and from reading
the ide.c source in loadhd and a clue from David Thomas, I see that it
does some jumping around to decide whether it should skip 512 bytes at the
start of the file.

There's no justification given in the comments, so I tried to work out a
reason for it. Other than 'leaving space for a potential header in the
future, but still working with raw disc dumps', I couldn't come up with
one. It would be handy if such things were described, so in my
implementation I've left some commentary of this to explain it in the
future. I offer that code and commentary in case it helps someone to
improve the existing RPCEmu (ie someone could explain why this juggling is
done), or someone can explain where it's wrong and I can update my code

This is python code, and it's based an an existing BlockData class which
provides the guarded access to the disc image between a given offset and
size:

----
class HDFBlockData(BlockData):
"""
Handle a block file for a HDF file, as used by RPCEmu.

These files are based around the storage of a harddisc image as written by
the controller in RPCEmu using the parameters stored in the FileCore
disc record at the start of the disc (disc address &C00). However, there is
the potential for all the disc data to be offset by 512 bytes.

The algorithm basically allows the HDF reader to read a raw FileCore image
if one has been given, but defaults to the image being at offset 512.

The result is that newly created discs will have the 512 byte header.
Existing discs which skip a 512 byte header will be just fine.
Existing, and newly ripped, discs that are just a dump of the disc contents
will be fine.

There's a risk that another format might have data in these low sectors but
then the chance of those discs being supplied to RPCEmu is low, so this is
probably reasonable.

The probable reason for this offset was that some header containing metadata
could be included in the future. However, no such metadata is used or present
at the current time.
"""

def __init__(self, *args, **kwargs):
super(HDFBlockData, self).__init__(*args, **kwargs)

# First read some data from the start of the file.
sector_c00 = bytearray(self.read(DiscTransfer(address=0xc00, size=0x200), 0x200))
sector_e00 = bytearray(self.read(DiscTransfer(address=0xe00, size=0x200), 0x200))

if len(sector_c00) < 0x200 or len(sector_e00) < 0x200:
# This disc is short, so we'll do no manipulation at all.
return

secspertrack_c00 = sector_c00[0x1c1]
heads_c00 = sector_c00[0x1c2]
secspertrack_e00 = sector_e00[0x1c1]
heads_e00 = sector_e00[0x1c2]

offset = 0
if secspertrack_e00 != 0 and heads_e00 != 0:
# The two fields we're using as our basis are valid at offset 512. So
# we use that. So there is a disc record here, we'll use it
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] HDF file format

Hiya,

I've been implementing a fake block device driver in Pyromaniac and found
that I was unable to access the hard disc files used by RPCEmu. All I was
doing was the (I thought) most obvious solution of treating the disc file
as a raw sequence of bytes. That's not how the HDF works, and from reading
the ide.c source in loadhd and a clue from David Thomas, I see that it
does some jumping around to decide whether it should skip 512 bytes at the
start of the file.

There's no justification given in the comments, so I tried to work out a
reason for it. Other than 'leaving space for a potential header in the
future, but still working with raw disc dumps', I couldn't come up with
one. It would be handy if such things were described, so in my
implementation I've left some commentary of this to explain it in the
future. I offer that code and commentary in case it helps someone to
improve the existing RPCEmu (ie someone could explain why this juggling is
done), or someone can explain where it's wrong and I can update my code.

This is python code, and it's based an an existing BlockData class which
provides the guarded access to the disc image between a given offset and
size:

----
class HDFBlockData(BlockData):
"""
Handle a block file for a HDF file, as used by RPCEmu.

These files are based around the storage of a harddisc image as written by
the controller in RPCEmu using the parameters stored in the FileCore
disc record at the start of the disc (disc address &C00). However, there is
the potential for all the disc data to be offset by 512 bytes.

The algorithm basically allows the HDF reader to read a raw FileCore image
if one has been given, but defaults to the image being at offset 512.

The result is that newly created discs will have the 512 byte header.
Existing discs which skip a 512 byte header will be just fine.
Existing, and newly ripped, discs that are just a dump of the disc contents
will be fine.

There's a risk that another format might have data in these low sectors but
then the chance of those discs being supplied to RPCEmu is low, so this is
probably reasonable.

The probable reason for this offset was that some header containing metadata
could be included in the future. However, no such metadata is used or present
at the current time.
"""

def __init__(self, *args, **kwargs):
super(HDFBlockData, self).__init__(*args, **kwargs)

# First read some data from the start of the file.
sector_c00 = bytearray(self.read(DiscTransfer(address=0xc00, size=0x200), 0x200))
sector_e00 = bytearray(self.read(DiscTransfer(address=0xe00, size=0x200), 0x200))

if len(sector_c00) < 0x200 or len(sector_e00) < 0x200:
# This disc is short, so we'll do no manipulation at all.
return

secspertrack_c00 = sector_c00[0x1c1]
heads_c00 = sector_c00[0x1c2]
secspertrack_e00 = sector_e00[0x1c1]
heads_e00 = sector_e00[0x1c2]

offset = 0
if secspertrack_e00 != 0 and heads_e00 != 0:
# The two fields we're using as our basis are valid at offset 512. So
# we use that. So there is a disc record here, we'll use it.
print("HDF disc record lives at offset 512 + 0xc00")
offset = 512
elif secspertrack_c00 == 0 and heads_c00 == 0:
# The two fields aren't valid without any offset. We will apply the
# offset of 512.
print("HDF disc record not present so assumingdisc offset at offset 512")
offset = 512
else:
# There was a disc record at offset 0, so we use that.
print("HDF disc record lives at offset 0 + 0xc00")
offset = 0

if offset:
# We need to change the data access offsets for this data so that we only
# access the actual data which RISC OS expects to see.
self.close()
if self._initial_limit:
self._initial_limit -= offset
self.data_offset += offset
----

It's not at all complex, but it matches the results of what loadhd does,
and allows me to mount existing .hdf files and raw dumps of a disc.

--
Charles Justin Ferguson
[ All information, speculation, opinion or data within, or attached to,
this email is private and confidential. Such content may not be
disclosed to third parties, or a public forum, without explicit
permission being granted. ]


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

Re: [Rpcemu] pound key not registering

On 2021-12-14, John Rickman wrote:
> Try some experiments with alt key combinations you might strike lucky.
>

No luck - I tried just about everything! I did get it working though -
keymap did work, and 29 is the right code - I think I must have messed
up the modifiers the last time I tried (it turns out randomly hitting
keys isn't always the best idea!)

As far as I can tell, the game is playable now - although mouse controls
don't really work. The manual says you can use 'M' to enable mouse
movement and 'Home' to adjust sensitivity - but even at maximum
sensitivity it barely moves... any ideas? :)

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso


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

Re: [Rpcemu] pound key not registering

In message <sp9fkd$ih6$1@ciao.gmane.io>
Tavis Ormandy <taviso@gmail.com> wrote:

> Hello, I'm trying to play a game (U.I.M.) in RPCEmu (0.9.4) that uses
> the £ key, but it just never registers the keypress. You really need the
> key to play the game, it's used to manipulate the navigation map.

> If I press Shift-3 on my UK PC keyboard in !Edit, then the £ symbol
> does appear, but it still doesn't work in this game.

...

> But that didn't work... I was hoping pressing '`' would generate
> a '£', but it actually generates '\'. I suppose that means '£' has some
> special handling?

It falls into "God Bless America" category.
Pound sign and hash sign are in an unholy alliance. They are Jekyl and
Hyde characters. They share a key.
My problem is the obverse of yours. On my Mac mini, shift-3 gives a pound
sign but pressing the hash key gives a backslash.
Very inconvenient when you wish to write a comment in Python.
Fortunately on Mac alt 3 produces a hash symbol.
Try some experiments with alt key combinations you might strike lucky.

John

--
John Rickman

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

[Rpcemu] pound key not registering

Hello, I'm trying to play a game (U.I.M.) in RPCEmu (0.9.4) that uses
the £ key, but it just never registers the keypress. You really need the
key to play the game, it's used to manipulate the navigation map.

If I press Shift-3 on my UK PC keyboard in !Edit, then the £ symbol
does appear, but it still doesn't work in this game.

I thought maybe I can jsut workaround it in software, and grabbed
KeyMapper from here (http://www.effarig.co.uk/riscos/)

I tried '*KeyMap 16 29' which seems right based on this table:

https://www.riscosopen.org/wiki/documentation/show/Low-Level%20Internal%20Key%20Numbers

But that didn't work... I was hoping pressing '`' would generate
a '£', but it actually generates '\'. I suppose that means '£' has some
special handling?

Maybe I have the scancodes wrong - I know zero about riscos internals!

Thanks!

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso

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

Re: [Rpcemu] Problem with build-essential dependencies

In article <592ded9786j.mccartney@blueyonder.co.uk>, John
McCartney <j.mccartney@blueyonder.co.uk> wrote:
> In article <592da604darpcemu1-sub@aconet.org>, Frank de
> Bruijn <rpcemu1-sub@aconet.org> wrote:

> > Changed the subject line, as this has nothing to do
> > with Qt5.

> > If your main machine has an up-to-date Mint setup, does
> > following the advice in this Reddit thread help?

https://www.reddit.com/r/linuxmint/comments/n1lx3e/cant_install_buildessential/

> Thanks for the link. I can't immediately say whether or
> not it's useful to me because I haven't had time to
> digest it. Bearing in mind my limited Linux skills, when
> I have digested it, it might still be beyond me.

Well, that was May, now it's December (cue Broadway hit
song).

I don't know why it's taken me so long to get round to
implementing this solution when it turns out to be
trivially easy!

The solution was to use apt to install aptitude and then
use aptitude to install the build-essentials. After that it
was all plain (and familiar) sailing.

<snip claim to be confused>

> Ideally, I'd like to completely uninstall what is already
> there and start again from the beginning.

No need for that now, though I was getting ready to do so.

Many thanks for the link Frank. I'm just sorry I didn't
follow it up sooner.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

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

[gccsdk] New release of the GCC 4 compiler

It's been brought to my attention that the Shared Unix library and related files (and probably GCC4) have had a some useful work done since the last RISC OS release.

 

Are we in a state where I create and upload a new version (Release 6)?

 

i.e. Is it in a stable enough state? Are the SharedLibs ABIs still compatible with the previous versions?

 

Regards,

Alan

 

RetroComputing devroom CfP

Hi there,

as with last year, we'll have an online FOSDEM.

Anyone care to propose a talk about NetSurf this time?

https://lists.fosdem.org/pipermail/retrocomputing-devroom/2021-December/000028.html

Deadline December 26th.

Event will be February 5th.

François.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: Netsurf for Palm OS

On Wed, Dec 01, 2021 at 12:59:51PM +0000, boeing chan wrote:
> I was not sure where to direct this email to, but I was wondering if netsurf is available for Palm OS? Thank you in advance for any reply.

Nobody has attempted a port to PalmOS as far as I am aware. I think it
might be a tight fit, even on the very last models of Pilot PDA though.

B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Netsurf for Palm OS

Hi,

I was not sure where to direct this email to, but I was wondering if netsurf is available for Palm OS? Thank you in advance for any reply.

Warm regards,

Irah C.