> On 25 Nov 2018, at 11:32 pm, Theo Markettos <theo@markettos.org.uk> wrote:
>
> On Thu, Nov 22, 2018 at 07:32:32PM +0000, Matthew Howkins wrote:
>> I have previously done some work integrating Slirp with RPCEmu, and got
>> further than you, because I can send and receive network packets :)
>
> That's good to know. I'm sure your proof-of-concept is better than mine :)
>
> (I have previously dug out the QEMU networking code on another project, but
> quite a lot of QEMU came with it. We should be releasing this in a few
> weeks, but I don't think the codebase will necessarily be helpful here)
>
>> I expect that there's still a lot to do on networking, but the long-term
>> plan is definitely to go with Slirp (or if not Slirp, something
>> equivalent). This would become the recommended networking option, and the
>> most portable option.
>
> That sounds like a good plan. It would seem to make more sense to work on
> that rather than platform-specific TUN/TAP code.
>
> Theo
>
I've been having a bit of sick leave (from retirement) so am only now getting back to the mailing lists and can reply to this exciting note of a month ago.
I am enormously thrilled by this thread as it looks like there is now a chance that RISC OS may run with networking under RPCEMU on a Mac. Thanks to all concerned in these developments.
My coding days are totally over. But if anyone wants, or needs, a Mac for testing purposes, I do have two old ones that I could put out on indefinite loan. The trouble with them is that they won't run the latest macOS, Mojave, though do run all macOS up to that. So, if it really is vital for this development for someone to have a Mac running current macOS for testing, or other purpose to do with this project, I could be persuaded to provide a new model Mac Mini which would run Mojave and be thoroughly up to date. Mac Minis only need a keyboard and monitor to work.
--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 26 December 2018
Sunday, 23 December 2018
[PATCH] SVG content handler: Fix plot style stroke_width
In 8332bf6b2a, when the stroke width was moved from a parameter to
the plot style field, it accidentally used the `stroke` field of
the svgtiny shape (the color) instead of `stroke_width`.
---
content/handlers/image/svg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/handlers/image/svg.c b/content/handlers/image/svg.c
index 51260733d..99722495f 100644
--- a/content/handlers/image/svg.c
+++ b/content/handlers/image/svg.c
@@ -189,7 +189,7 @@ svg_redraw_internal(struct content *c,
for (i = 0; i != diagram->shape_count; i++) {
if (diagram->shape[i].path) {
pstyle.stroke_width = plot_style_int_to_fixed(
- diagram->shape[i].stroke);
+ diagram->shape[i].stroke_width);
pstyle.stroke_colour = BGR(diagram->shape[i].stroke);
pstyle.fill_colour = BGR(diagram->shape[i].fill);
res = ctx->plot->path(ctx,
--
2.20.1
the plot style field, it accidentally used the `stroke` field of
the svgtiny shape (the color) instead of `stroke_width`.
---
content/handlers/image/svg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/handlers/image/svg.c b/content/handlers/image/svg.c
index 51260733d..99722495f 100644
--- a/content/handlers/image/svg.c
+++ b/content/handlers/image/svg.c
@@ -189,7 +189,7 @@ svg_redraw_internal(struct content *c,
for (i = 0; i != diagram->shape_count; i++) {
if (diagram->shape[i].path) {
pstyle.stroke_width = plot_style_int_to_fixed(
- diagram->shape[i].stroke);
+ diagram->shape[i].stroke_width);
pstyle.stroke_colour = BGR(diagram->shape[i].stroke);
pstyle.fill_colour = BGR(diagram->shape[i].fill);
res = ctx->plot->path(ctx,
--
2.20.1
Saturday, 22 December 2018
[libwapcaplet] [PATCH] Use a wrapper for memcpy to work around Werror
>From 1cac76658a8b02892cfd59f9dd0a9efaf4ac774f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= <revol@free.fr>
Date: Sat, 22 Dec 2018 21:00:52 +0100
Subject: [PATCH] Use a wrapper for memcpy to work around
-Werror=type-function-cast
---
src/libwapcaplet.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/libwapcaplet.c b/src/libwapcaplet.c
index 3ef0003..cd51559 100644
--- a/src/libwapcaplet.c
+++ b/src/libwapcaplet.c
@@ -49,6 +49,12 @@ typedef lwc_hash (*lwc_hasher)(const char *, size_t);
typedef int (*lwc_strncmp)(const char *, const char *, size_t);
typedef void (*lwc_memcpy)(char * restrict, const char * restrict, size_t);
+static void
+lwc__memcpy(char *restrict target, const char *restrict source, size_t n)
+{
+ memcpy(target, source, n);
+}
+
static lwc_error
lwc__initialise(void)
{
@@ -145,7 +151,7 @@ lwc_intern_string(const char *s, size_t slen,
{
return lwc__intern(s, slen, ret,
lwc__calculate_hash,
- strncmp, (lwc_memcpy)memcpy);
+ strncmp, (lwc_memcpy)lwc__memcpy);
}
lwc_error
--
2.20.1
Hi,
I'm using GCC 8.2.0 here and it breaks with the return type of memcpy.
Attached patch fixes it.
Another option would be to change the return type of lwc_memcpy.
François.
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= <revol@free.fr>
Date: Sat, 22 Dec 2018 21:00:52 +0100
Subject: [PATCH] Use a wrapper for memcpy to work around
-Werror=type-function-cast
---
src/libwapcaplet.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/libwapcaplet.c b/src/libwapcaplet.c
index 3ef0003..cd51559 100644
--- a/src/libwapcaplet.c
+++ b/src/libwapcaplet.c
@@ -49,6 +49,12 @@ typedef lwc_hash (*lwc_hasher)(const char *, size_t);
typedef int (*lwc_strncmp)(const char *, const char *, size_t);
typedef void (*lwc_memcpy)(char * restrict, const char * restrict, size_t);
+static void
+lwc__memcpy(char *restrict target, const char *restrict source, size_t n)
+{
+ memcpy(target, source, n);
+}
+
static lwc_error
lwc__initialise(void)
{
@@ -145,7 +151,7 @@ lwc_intern_string(const char *s, size_t slen,
{
return lwc__intern(s, slen, ret,
lwc__calculate_hash,
- strncmp, (lwc_memcpy)memcpy);
+ strncmp, (lwc_memcpy)lwc__memcpy);
}
lwc_error
--
2.20.1
Hi,
I'm using GCC 8.2.0 here and it breaks with the return type of memcpy.
Attached patch fixes it.
Another option would be to change the return type of lwc_memcpy.
François.
Monday, 17 December 2018
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
Timothy Coltman, on 19 Nov, wrote:
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS.
Thanks for the patches, a build is running well on this Mojave 10.14.2 iMac
using QT5 5.12.0.
[snip]
> There are a few things to note:
>
> 1. The keyboard mimics that of a RISC PC,
Keyboard mappings have been setup within RISC OS, using the KeyMapper module
and the freeware iMacKB app, as supplied with VRPC, to match the small Apple
Magic Keyboard. As there is no Break key the key to the left of "1" has been
hijacked. Do I need § and ± more than alt-Break!!
[snip]
> Please note that there is no networking support.
In lieu of networking Moonfish NFS serves on the Titanium can be seen in
RPCEmu with symlinks and the Finder's "Connect to server", and similarly
with samba for pen inserted in the router.
> Any comments and suggestions would be appreciated.
One little snag is that RISC OS time is not maintained over sleep and other
circumstances where RPCEmu is hidden such as not being on the current
desktop. The workaround was to reinstate the SyncClock module. That works
just fine with ROL ROMs bit OS5 seems to get locked in GMT. This issue is
nothing to do with the Mac patches the same thing happens on a Linux build
in a VM on the same Mac.
Thanks again.
--
David Pitt
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS.
Thanks for the patches, a build is running well on this Mojave 10.14.2 iMac
using QT5 5.12.0.
[snip]
> There are a few things to note:
>
> 1. The keyboard mimics that of a RISC PC,
Keyboard mappings have been setup within RISC OS, using the KeyMapper module
and the freeware iMacKB app, as supplied with VRPC, to match the small Apple
Magic Keyboard. As there is no Break key the key to the left of "1" has been
hijacked. Do I need § and ± more than alt-Break!!
[snip]
> Please note that there is no networking support.
In lieu of networking Moonfish NFS serves on the Titanium can be seen in
RPCEmu with symlinks and the Finder's "Connect to server", and similarly
with samba for pen inserted in the router.
> Any comments and suggestions would be appreciated.
One little snag is that RISC OS time is not maintained over sleep and other
circumstances where RPCEmu is hidden such as not being on the current
desktop. The workaround was to reinstate the SyncClock module. That works
just fine with ROL ROMs bit OS5 seems to get locked in GMT. This issue is
nothing to do with the Mac patches the same thing happens on a Linux build
in a VM on the same Mac.
Thanks again.
--
David Pitt
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] hdf file format
In message <041a01d49337$7d74adb0$785e0910$@hollypops.co.uk>
on 13 Dec 2018 Gerald Holdsworth wrote:
> ADF and HDF are, effectively, exactly the same. I have written
> documentation and published it here:
>
> http://www.geraldholdsworth.co.uk/GuideToDiscImage/DiscImage.pdf
>
> and I've tried to write it so it makes more sense than the Programmer's
> Reference Manuals.
>
> (This also includes other formats: Amiga ADF and HDF; Acorn/Watford DFS;
> and Commodore 1541/1571/1581)
This is an interesting document. I think you could do with expanding on the
area of double-sided discs. I think there is also a mistake on page 6 where
you say
"Double-sided disc images are stored where the tracks are interleaved. That
is, you get ten tracks of side 1, followed by ten tracks of side 2, and so
on."
I think you mean ten sectors of side 1, and then ten sectors of side 2.
The document is very much written from the point of view of understanding a
disc image file, rather than a physical disc. What is lacking, perhaps, is
something about how the operating system sees the physical disc, and also a
distinction between double-sided formats where the user has to physically
turn the floppy disc over (where in reality the operating system sees the
floppy as two independent single-sided discs) and floppy formats where the
drive has a head for each side of the disc and the floppy disc has to be put
in the correct way up. Obviously 3.5" discs are always the latter. On the
Amstrad, the 3" disc drives originally supplied only had one head, so the
user flipped the disc manually to use the other side. When people started
switching to 3.5" drives, some suppliers added a toggle switch to the drive
so that you could use both sides of a 3.5" disc in a similar way, because the
Amstrad's operating system could not actually access the other side of the
disc. I don't know anything about BBC discs of that era: there were probably
lots of different solutions.
It is important, I think, to separate the explanation of how the operating
system accesses the disc from how the contents of the disc get stored in an
image file. It is easier to talk about sides and tracks than to try to
reduce everything to sectors. With ADF and HDF formats, it is just the
sector contents that are stored, but with some emulators, e.g. Amstrad and
Spectrum, the sector metadata also need to be stored, hence the more
complicated DSK and EDSK formats.
So I would split the problem into three:
1) how to translate from head/track/sector to a position in the image file
2) what order the operating system accesses the heads/tracks/sectors
3) how the disc contents is interpreted
Operating systems that can access double-headed drives might
order the tracks in different ways. I have extracted the following from the
documentation from my !DiscImage application which you will find at
http://sinenomine.co.uk/software/
Something along these lines might be useful.
----------
For a double-sided disc, the order in which the sectors and tracks are
arranged is not obvious, because as well as moving from one track to
another, you must change sides (heads) at some point.
There are three common possibilities. The examples that follow assume an
80 track disc:
a) Interleaved
Reading swaps to the other side of the disc before the track is
incremented:
head 0, track 0
head 1, track 0
head 0, track 1
head 1, track 1
head 0, track 2
...
head 0, track 79
head 1, track 79
This is now the most common arrangement.
b) Sequenced
The whole of the first side is read in order, and then the whole of the
second side is read starting again from track 0:
head 0, track 0
head 0, track 1
...
head 0, track 79
head 1, track 0
head 1, track 1
...
head 1, track 79
Used for some older ADFS and DFS formats, as well as the 400K Acorn
CP/M format.
c) "Up and over"
After reading the whole of the first side, the second side is read in
reverse order:
head 0, track 0
head 0, track 1
...
head 0, track 79
head 1, track 79
head 1, track 78
...
head 1, track 0
This arrangement is not used by RISC OS, but is used as a less common
alternative to interleaved in some implementations of CP/M.
It is the responsibility of the identifier component of image filing
systems such as DOSFS, MacFS and CPMFS to represent foreign disc formats to
RISC OS in a suitable way. Formats which are interleaved or sequenced will
normally be presented to RISC OS as such, and so in a plain image created
by DiscImage the tracks will be stored in the order shown above.
-------------
--
Matthew Phillips
Durham
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
on 13 Dec 2018 Gerald Holdsworth wrote:
> ADF and HDF are, effectively, exactly the same. I have written
> documentation and published it here:
>
> http://www.geraldholdsworth.co.uk/GuideToDiscImage/DiscImage.pdf
>
> and I've tried to write it so it makes more sense than the Programmer's
> Reference Manuals.
>
> (This also includes other formats: Amiga ADF and HDF; Acorn/Watford DFS;
> and Commodore 1541/1571/1581)
This is an interesting document. I think you could do with expanding on the
area of double-sided discs. I think there is also a mistake on page 6 where
you say
"Double-sided disc images are stored where the tracks are interleaved. That
is, you get ten tracks of side 1, followed by ten tracks of side 2, and so
on."
I think you mean ten sectors of side 1, and then ten sectors of side 2.
The document is very much written from the point of view of understanding a
disc image file, rather than a physical disc. What is lacking, perhaps, is
something about how the operating system sees the physical disc, and also a
distinction between double-sided formats where the user has to physically
turn the floppy disc over (where in reality the operating system sees the
floppy as two independent single-sided discs) and floppy formats where the
drive has a head for each side of the disc and the floppy disc has to be put
in the correct way up. Obviously 3.5" discs are always the latter. On the
Amstrad, the 3" disc drives originally supplied only had one head, so the
user flipped the disc manually to use the other side. When people started
switching to 3.5" drives, some suppliers added a toggle switch to the drive
so that you could use both sides of a 3.5" disc in a similar way, because the
Amstrad's operating system could not actually access the other side of the
disc. I don't know anything about BBC discs of that era: there were probably
lots of different solutions.
It is important, I think, to separate the explanation of how the operating
system accesses the disc from how the contents of the disc get stored in an
image file. It is easier to talk about sides and tracks than to try to
reduce everything to sectors. With ADF and HDF formats, it is just the
sector contents that are stored, but with some emulators, e.g. Amstrad and
Spectrum, the sector metadata also need to be stored, hence the more
complicated DSK and EDSK formats.
So I would split the problem into three:
1) how to translate from head/track/sector to a position in the image file
2) what order the operating system accesses the heads/tracks/sectors
3) how the disc contents is interpreted
Operating systems that can access double-headed drives might
order the tracks in different ways. I have extracted the following from the
documentation from my !DiscImage application which you will find at
http://sinenomine.co.uk/software/
Something along these lines might be useful.
----------
For a double-sided disc, the order in which the sectors and tracks are
arranged is not obvious, because as well as moving from one track to
another, you must change sides (heads) at some point.
There are three common possibilities. The examples that follow assume an
80 track disc:
a) Interleaved
Reading swaps to the other side of the disc before the track is
incremented:
head 0, track 0
head 1, track 0
head 0, track 1
head 1, track 1
head 0, track 2
...
head 0, track 79
head 1, track 79
This is now the most common arrangement.
b) Sequenced
The whole of the first side is read in order, and then the whole of the
second side is read starting again from track 0:
head 0, track 0
head 0, track 1
...
head 0, track 79
head 1, track 0
head 1, track 1
...
head 1, track 79
Used for some older ADFS and DFS formats, as well as the 400K Acorn
CP/M format.
c) "Up and over"
After reading the whole of the first side, the second side is read in
reverse order:
head 0, track 0
head 0, track 1
...
head 0, track 79
head 1, track 79
head 1, track 78
...
head 1, track 0
This arrangement is not used by RISC OS, but is used as a less common
alternative to interleaved in some implementations of CP/M.
It is the responsibility of the identifier component of image filing
systems such as DOSFS, MacFS and CPMFS to represent foreign disc formats to
RISC OS in a suitable way. Formats which are interleaved or sequenced will
normally be presented to RISC OS as such, and so in a plain image created
by DiscImage the tracks will be stored in the order shown above.
-------------
--
Matthew Phillips
Durham
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 14 December 2018
Re: [Rpcemu] hdf file format
Just had a look over the riscos.info page - not entirely sure where the link to my document would fit in as, although it covers a part of RISC OS (i.e. Filecore/ADFS), is not specific to it.
If anyone wants to add it in, please feel free - you have my permission to publish this anywhere (although if you just put a link to the document, as I will update it from time to time as and when I discover more).
Going back to the original question - Reuben, the offset you refer to (&FC1) points directly into the disc record, with the &200 byte header added on the top of the file (so it is an actual HDF file created by an emulator). Just zeroing these values will not make the file readable by an emulator. You will need to recreate the disc record, and details are in my document (and the Programmer's Reference Manual).
Cheers,
Gerald.
On 14/12/2018, 09:59, "Gerald Holdsworth" <rpcemu-bounces@riscos.info on behalf of gerald@hollypops.co.uk> wrote:
Hi Ralph,
Do you know why Googling for `site:geraldholdsworth.co.uk disc image'
doesn't find it? Neither does
`site:geraldholdsworth.co.uk filetype:pdf'. Are you restricting
Google's access in some way?
I have no idea - I don't use Google (nor do I usually search for my own sites). I've done nothing to restrict any search engine or any web bots on any of my sites.
Can I suggest you also work a mention into the wiki at
http://www.riscos.info/index.php/RISC_OS
It was posted on Stardot. I tried to put a link on Wikipedia but their Gestapo took it off, because I was posting a link to my own document on my own site and claimed that it had no references to other sources (which it does) or can be proved (which it was, as it was written alongside some code also on the same site). But I will look into the RiscOS Wiki.
Cheers,
Gerald.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] hdf file format
Hi Ralph,
Do you know why Googling for `site:geraldholdsworth.co.uk disc image'
doesn't find it? Neither does
`site:geraldholdsworth.co.uk filetype:pdf'. Are you restricting
Google's access in some way?
I have no idea - I don't use Google (nor do I usually search for my own sites). I've done nothing to restrict any search engine or any web bots on any of my sites.
Can I suggest you also work a mention into the wiki at
http://www.riscos.info/index.php/RISC_OS
It was posted on Stardot. I tried to put a link on Wikipedia but their Gestapo took it off, because I was posting a link to my own document on my own site and claimed that it had no references to other sources (which it does) or can be proved (which it was, as it was written alongside some code also on the same site). But I will look into the RiscOS Wiki.
Cheers,
Gerald.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Do you know why Googling for `site:geraldholdsworth.co.uk disc image'
doesn't find it? Neither does
`site:geraldholdsworth.co.uk filetype:pdf'. Are you restricting
Google's access in some way?
I have no idea - I don't use Google (nor do I usually search for my own sites). I've done nothing to restrict any search engine or any web bots on any of my sites.
Can I suggest you also work a mention into the wiki at
http://www.riscos.info/index.php/RISC_OS
It was posted on Stardot. I tried to put a link on Wikipedia but their Gestapo took it off, because I was posting a link to my own document on my own site and claimed that it had no references to other sources (which it does) or can be proved (which it was, as it was written alongside some code also on the same site). But I will look into the RiscOS Wiki.
Cheers,
Gerald.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] hdf file format
Hi Gerald,
> ADF and HDF are, effectively, exactly the same. I have written
> documentation and published it here:
>
> http://www.geraldholdsworth.co.uk/GuideToDiscImage/DiscImage.pdf
Do you know why Googling for `site:geraldholdsworth.co.uk disc image'
doesn't find it? Neither does
`site:geraldholdsworth.co.uk filetype:pdf'. Are you restricting
Google's access in some way?
Can I suggest you also work a mention into the wiki at
http://www.riscos.info/index.php/RISC_OS
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> ADF and HDF are, effectively, exactly the same. I have written
> documentation and published it here:
>
> http://www.geraldholdsworth.co.uk/GuideToDiscImage/DiscImage.pdf
Do you know why Googling for `site:geraldholdsworth.co.uk disc image'
doesn't find it? Neither does
`site:geraldholdsworth.co.uk filetype:pdf'. Are you restricting
Google's access in some way?
Can I suggest you also work a mention into the wiki at
http://www.riscos.info/index.php/RISC_OS
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] hdf file format
On Thu, 13 Dec 2018, at 23:20, Reuben Thomas wrote:
The problem was that the disk image has its first few sectors mostly containing &deadbeef. In the loadhd function in ide.c, at the check marked with the log message "First check", rpcemu assumes that non-zero values are valid.
Have you seen these links?
Some time ago, there were some 'oddities' with the hdf file format which had to be worked around. Might be worth trying the advice in there?
Cheers,
Richard.
--
Richard Walker
richardwalker@letterboxes.org
Thursday, 13 December 2018
Re: [Rpcemu] hdf file format
On Thu, 13 Dec 2018 at 22:02, Reuben Thomas <rrt@sc3d.org> wrote:
I can't find any documentation on the file format for .hdf files. I would like to turn an ADFS disc image (which I can mount under Linux) into a .hdf file. (I can already get at the data by mounting it under Linux on my hostfs directory; however, some things then don't work that e.g. rely on the disc name).Any hints before I dive into the source code will be gratefully accepted!
In fact, only a little source-diving was required.
The problem was that the disk image has its first few sectors mostly containing &deadbeef. In the loadhd function in ide.c, at the check marked with the log message "First check", rpcemu assumes that non-zero values are valid.
I'm afraid I don't know enough about IDE disks to know whether this is a valid assumption; I didn't make the disk image myself (it was made by Chris Evans at CJE Micros), but as far as I know it's just a raw disk image, and there's nothing funny about the disk it came from (an old Connor 420Mb disk).
So should the check be loosened to for example check for sane values, or even the specific bytes of &deadbeef that might be found at offset 0xfc1? Or should I simply hand-edit some zeros into my disk image file, and expect to have to do that again possibly in future?
Re: [Rpcemu] hdf file format
ADF and HDF are, effectively, exactly the same. I have written documentation and published it here:
http://www.geraldholdsworth.co.uk/GuideToDiscImage/DiscImage.pdf
and I've tried to write it so it makes more sense than the Programmer's Reference Manuals.
(This also includes other formats: Amiga ADF and HDF; Acorn/Watford DFS; and Commodore 1541/1571/1581)
From: rpcemu-bounces@riscos.info <rpcemu-bounces@riscos.info> On Behalf Of Reuben Thomas
Sent: 13 December 2018 22:03
To: rpcemu@riscos.info
Subject: [Rpcemu] hdf file format
I can't find any documentation on the file format for .hdf files. I would like to turn an ADFS disc image (which I can mount under Linux) into a .hdf file. (I can already get at the data by mounting it under Linux on my hostfs directory; however, some things then don't work that e.g. rely on the disc name).
Any hints before I dive into the source code will be gratefully accepted!
--
[Rpcemu] hdf file format
I can't find any documentation on the file format for .hdf files. I would like to turn an ADFS disc image (which I can mount under Linux) into a .hdf file. (I can already get at the data by mounting it under Linux on my hostfs directory; however, some things then don't work that e.g. rely on the disc name).
Any hints before I dive into the source code will be gratefully accepted!
--
Wednesday, 12 December 2018
[gccsdk] curl with ssl
Hi
Curl fails in libnettle.. I can build curl without ssl support.
I have tried to manually compile libraries , but most often it fails
due to the mix of static / shared flags and the lack of -fPIC for
shared.
I would be most happy if someone could check autobuilder for shared
linked curl. It is libcurl I am after.
Michael
_______________________________________________
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
Curl fails in libnettle.. I can build curl without ssl support.
I have tried to manually compile libraries , but most often it fails
due to the mix of static / shared flags and the lack of -fPIC for
shared.
I would be most happy if someone could check autobuilder for shared
linked curl. It is libcurl I am after.
Michael
_______________________________________________
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
Friday, 7 December 2018
[gccsdk] march=armv4 machines
Using gcc -E -dM foo.c
I noticed that when using march=armv4 that gcc sets __ARM_ARCH_4__ 1
otherwise it will be __ARM_ARCH_3__ 1
using -mfpu=vfp sets __ARM_ARCH_6ZK__ 1
Just want to be clear on what RISC OS machines these cover with regard to
assembler routines.
None applied for smaller than __ARM_ARCH_4__ so perhaps a recipe for
earlier than arch 4 could be described as the default?
Also, for the vfp useage, is there anything extra to be specified to build
for the vfp directory library for either/both static and shared?
I think it just puts it in abi-2 .0 if left alone?
Thanks for any help
RonM.
_______________________________________________
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
I noticed that when using march=armv4 that gcc sets __ARM_ARCH_4__ 1
otherwise it will be __ARM_ARCH_3__ 1
using -mfpu=vfp sets __ARM_ARCH_6ZK__ 1
Just want to be clear on what RISC OS machines these cover with regard to
assembler routines.
None applied for smaller than __ARM_ARCH_4__ so perhaps a recipe for
earlier than arch 4 could be described as the default?
Also, for the vfp useage, is there anything extra to be specified to build
for the vfp directory library for either/both static and shared?
I think it just puts it in abi-2 .0 if left alone?
Thanks for any help
RonM.
_______________________________________________
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
Wednesday, 28 November 2018
Re: [gccsdk] mmap
> 1) OS_DynamicArea returns an error. This could happen if the memory
> request was too big, for example, but seems unlikely.
>
> 2) Only 8 mmap sections at any one time are supported. That includes
> those that malloc may create for large requests, however, malloc
> falls back to its normal allocation routines if there are already
> 8 mmaps. Attempting to create a 9th will result in ENOMEM.
> memalign uses malloc and so will suffer the same limitations.
>
> I usually replace any mmap calls with my own dynamic area memory
> allocator.
>
OK I am not sure , but I belive this is the frist one. Will hunt for others
_______________________________________________
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
> request was too big, for example, but seems unlikely.
>
> 2) Only 8 mmap sections at any one time are supported. That includes
> those that malloc may create for large requests, however, malloc
> falls back to its normal allocation routines if there are already
> 8 mmaps. Attempting to create a 9th will result in ENOMEM.
> memalign uses malloc and so will suffer the same limitations.
>
> I usually replace any mmap calls with my own dynamic area memory
> allocator.
>
OK I am not sure , but I belive this is the frist one. Will hunt for others
_______________________________________________
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: [gccsdk] mmap
On 28/11/2018 12:33, Michael Grunditz wrote:
> On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>>
>> On 26/11/2018 15:53, Michael Grunditz wrote:
>>> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
>>> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>>>
>>> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>>>
>>> This error is from my "new" OWB codebase. Exactly the same mmap
>>> succeeds in old code.
>>>
>>> I have experimented with wimpslot , but no luck.
>>
>> That error is not from Unixlib. Best thing to do is to search your
>> code base for the error and see what leads to it being generated.
>>
>> Lee.
>
> memalign also fails in the same way. How can I allocate memory inside
> a shared lib? The same code works just find in a standalone file. btw
> it is "perror" that prints the errmessage,
Ok, there are 2 reasons why mmap can fail:
1) OS_DynamicArea returns an error. This could happen if the memory
request was too big, for example, but seems unlikely.
2) Only 8 mmap sections at any one time are supported. That includes
those that malloc may create for large requests, however, malloc
falls back to its normal allocation routines if there are already
8 mmaps. Attempting to create a 9th will result in ENOMEM.
memalign uses malloc and so will suffer the same limitations.
I usually replace any mmap calls with my own dynamic area memory
allocator.
Lee.
_______________________________________________
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
> On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>>
>> On 26/11/2018 15:53, Michael Grunditz wrote:
>>> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
>>> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>>>
>>> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>>>
>>> This error is from my "new" OWB codebase. Exactly the same mmap
>>> succeeds in old code.
>>>
>>> I have experimented with wimpslot , but no luck.
>>
>> That error is not from Unixlib. Best thing to do is to search your
>> code base for the error and see what leads to it being generated.
>>
>> Lee.
>
> memalign also fails in the same way. How can I allocate memory inside
> a shared lib? The same code works just find in a standalone file. btw
> it is "perror" that prints the errmessage,
Ok, there are 2 reasons why mmap can fail:
1) OS_DynamicArea returns an error. This could happen if the memory
request was too big, for example, but seems unlikely.
2) Only 8 mmap sections at any one time are supported. That includes
those that malloc may create for large requests, however, malloc
falls back to its normal allocation routines if there are already
8 mmaps. Attempting to create a 9th will result in ENOMEM.
memalign uses malloc and so will suffer the same limitations.
I usually replace any mmap calls with my own dynamic area memory
allocator.
Lee.
_______________________________________________
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: [gccsdk] mmap
On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>
> On 26/11/2018 15:53, Michael Grunditz wrote:
> > void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> > PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
> >
> > Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
> >
> > This error is from my "new" OWB codebase. Exactly the same mmap
> > succeeds in old code.
> >
> > I have experimented with wimpslot , but no luck.
>
> That error is not from Unixlib. Best thing to do is to search your
> code base for the error and see what leads to it being generated.
>
> Lee.
memalign also fails in the same way. How can I allocate memory inside
a shared lib? The same code works just find in a standalone file. btw
it is "perror" that prints the errmessage,
Michael
_______________________________________________
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
>
> On 26/11/2018 15:53, Michael Grunditz wrote:
> > void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> > PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
> >
> > Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
> >
> > This error is from my "new" OWB codebase. Exactly the same mmap
> > succeeds in old code.
> >
> > I have experimented with wimpslot , but no luck.
>
> That error is not from Unixlib. Best thing to do is to search your
> code base for the error and see what leads to it being generated.
>
> Lee.
memalign also fails in the same way. How can I allocate memory inside
a shared lib? The same code works just find in a standalone file. btw
it is "perror" that prints the errmessage,
Michael
_______________________________________________
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: [gccsdk] mmap
On 26/11/2018 15:53, Michael Grunditz wrote:
> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>
> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>
> This error is from my "new" OWB codebase. Exactly the same mmap
> succeeds in old code.
>
> I have experimented with wimpslot , but no luck.
That error is not from Unixlib. Best thing to do is to search your
code base for the error and see what leads to it being generated.
Lee.
_______________________________________________
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
> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>
> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>
> This error is from my "new" OWB codebase. Exactly the same mmap
> succeeds in old code.
>
> I have experimented with wimpslot , but no luck.
That error is not from Unixlib. Best thing to do is to search your
code base for the error and see what leads to it being generated.
Lee.
_______________________________________________
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
Monday, 26 November 2018
[gccsdk] mmap
void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
This error is from my "new" OWB codebase. Exactly the same mmap
succeeds in old code.
I have experimented with wimpslot , but no luck.
Please CC me when replying.
Michael
_______________________________________________
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
PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
This error is from my "new" OWB codebase. Exactly the same mmap
succeeds in old code.
I have experimented with wimpslot , but no luck.
Please CC me when replying.
Michael
_______________________________________________
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
Sunday, 25 November 2018
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Thu, Nov 22, 2018 at 07:32:32PM +0000, Matthew Howkins wrote:
> I have previously done some work integrating Slirp with RPCEmu, and got
> further than you, because I can send and receive network packets :)
That's good to know. I'm sure your proof-of-concept is better than mine :)
(I have previously dug out the QEMU networking code on another project, but
quite a lot of QEMU came with it. We should be releasing this in a few
weeks, but I don't think the codebase will necessarily be helpful here)
> I expect that there's still a lot to do on networking, but the long-term
> plan is definitely to go with Slirp (or if not Slirp, something
> equivalent). This would become the recommended networking option, and the
> most portable option.
That sounds like a good plan. It would seem to make more sense to work on
that rather than platform-specific TUN/TAP code.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I have previously done some work integrating Slirp with RPCEmu, and got
> further than you, because I can send and receive network packets :)
That's good to know. I'm sure your proof-of-concept is better than mine :)
(I have previously dug out the QEMU networking code on another project, but
quite a lot of QEMU came with it. We should be releasing this in a few
weeks, but I don't think the codebase will necessarily be helpful here)
> I expect that there's still a lot to do on networking, but the long-term
> plan is definitely to go with Slirp (or if not Slirp, something
> equivalent). This would become the recommended networking option, and the
> most portable option.
That sounds like a good plan. It would seem to make more sense to work on
that rather than platform-specific TUN/TAP code.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 22 November 2018
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
I have previously done some work integrating Slirp with RPCEmu, and got further than you, because I can send and receive network packets :)
There's a lot to think about before integrating and releasing the code as is, but the ultimate aim is to get user-friendly networking with the absolute minimum number of configuration steps.
One of the challenges of incorporating Slirp was that there are so many derivatives of the original code base, and they tend to differ in their suitability. Here are some of the things I've considered when selecting which Slirp code to integrate:
* Not all Slirp derivatives are easy to extract and integrate with RPCEmu. The copies in QEMU and VirtualBox are fully-featured, but are very difficult to integrate.
* Not all Slirp code is portable to 64-bit platforms or Windows, as the original code was only for Unix.
* Only some Slirp code has good support for DHCP.
* Only some Slirp codebases support port-forwarding, which I consider a highly desirable feature.
* Few Slirp codebases support DNS proxying, and this I consider an essential feature (see below).
The DNS proxying I consider an essential feature, because without it the user would not only have to manually configure DNS (which would seem odd given that the rest of the config would be automatic), but they would have to change their RISC OS config every time they moved to another network, which laptop users would be very likely to do.
I got to the point of having Slirp integrated and working on Linux, though without support for the DNS proxying feature. However, testing showed up deficiencies and bugs in the other parts of the network code including the EtherRPCEm driver, and that is where most of the recent effort has been expended.
I expect that there's still a lot to do on networking, but the long-term plan is definitely to go with Slirp (or if not Slirp, something equivalent). This would become the recommended networking option, and the most portable option.
Matthew
Wednesday, 21 November 2018
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Wed, Nov 21, 2018 at 02:07:11PM +0000, David Gee wrote:
> The Mac emulator BasiliskII uses slirp for networking. It doesn't require
> setting up. It's open source so it may be easier than QEMU (or it may
> just use the same code).
Thanks. It appears to use an earlier fork of the same code, without the
library-ification.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> The Mac emulator BasiliskII uses slirp for networking. It doesn't require
> setting up. It's open source so it may be easier than QEMU (or it may
> just use the same code).
Thanks. It appears to use an earlier fork of the same code, without the
library-ification.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
The Mac emulator BasiliskII uses slirp for networking. It doesn't require setting up. It's open source so it may be easier than QEMU (or it may just use the same code).
David Gee
David Gee
Gateshead
On Tue, Nov 20, 2018 at 10:08:40PM +0000, Theo Markettos wrote:
There are also things like: https://github.com/zhuhaow/NEKit that build on
top of NETunnelProvider and handle the entitlement, like you do with
Tunnelblick.
Shortly after writing that post, I had a better idea.
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)
Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().
As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Tue, Nov 20, 2018 at 10:08:40PM +0000, Theo Markettos wrote:
> There are also things like: https://github.com/zhuhaow/NEKit that build on
> top of NETunnelProvider and handle the entitlement, like you do with
> Tunnelblick.
Shortly after writing that post, I had a better idea.
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)
Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().
As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> There are also things like: https://github.com/zhuhaow/NEKit that build on
> top of NETunnelProvider and handle the entitlement, like you do with
> Tunnelblick.
Shortly after writing that post, I had a better idea.
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)
Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().
As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 20 November 2018
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On Tue, Nov 20, 2018 at 09:38:56PM +0000, lists@maemagel.com wrote:
> My hacked version would have been pretty awful, even if it had worked.
> Kernel extensions need to be signed in newer versions of OS X and I'm
> not a registered developer, so I ended up downloading an application
> called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which
> were signed. The emulator would randomly stall during !Boot when
> setting up networking, so I decided to cut my losses and gave it up as a
> bad job. I'll have a look at "networkextension", just to see, though
> I'm not too experienced when it comes to OS X development.
Using Tunnelblick's TUN/TAP was what I did - it worked, but it wasn't exactly
user friendly. I don't think I've tried it on anything post Mavericks,
though.
Apple does say:
The com.apple.developer.networking.networkextension entitlement is required
in order to use the NETunnelProvider class. Enable this entitlement when
creating an App ID in your developer account.
but according to StackOverflow (which must be true) that's no longer the
case. (It may still apply to iOS). There are also things like:
https://github.com/zhuhaow/NEKit
that build on top of NETunnelProvider and handle the entitlement, like you
do with Tunnelblick.
> Peter did ask me whether I'd be prepared to create Mac binaries when I
> emailed him previously off-list, and I "umm"ed and "ah"ed about it. It
> really depends on how much work there is, and whether there are any
> other oddities thrown up by OS X that need to be worked around (such as
> the keyboard and networking). It would be nice to have a proper
> installer as well (there is an installer builder in QT apparently,
> though I've not investigated in any detail).
I don't think there's much to do beyond putting the files in a .app bundle
inside a .dmg archive? I don't think there's any need for an installer,
users open the .dmg and just drag RPCEmu.app to /Applications. You'd
probably put the Qt libraries inside the .app so there's no system
dependencies, or even statically link.
Looks like this is the tool to make a bundle including Qt libraries:
http://doc.qt.io/qt-5/osx-deployment.html
A wizard that's roughly 'what ROM image do you want', 'where do you want
your hostfs to go' etc would be nice, but not critical.
My Allegro binaries were pretty much fire-and-forget - I got a few people
asking about stuff, but not a lot.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> My hacked version would have been pretty awful, even if it had worked.
> Kernel extensions need to be signed in newer versions of OS X and I'm
> not a registered developer, so I ended up downloading an application
> called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which
> were signed. The emulator would randomly stall during !Boot when
> setting up networking, so I decided to cut my losses and gave it up as a
> bad job. I'll have a look at "networkextension", just to see, though
> I'm not too experienced when it comes to OS X development.
Using Tunnelblick's TUN/TAP was what I did - it worked, but it wasn't exactly
user friendly. I don't think I've tried it on anything post Mavericks,
though.
Apple does say:
The com.apple.developer.networking.networkextension entitlement is required
in order to use the NETunnelProvider class. Enable this entitlement when
creating an App ID in your developer account.
but according to StackOverflow (which must be true) that's no longer the
case. (It may still apply to iOS). There are also things like:
https://github.com/zhuhaow/NEKit
that build on top of NETunnelProvider and handle the entitlement, like you
do with Tunnelblick.
> Peter did ask me whether I'd be prepared to create Mac binaries when I
> emailed him previously off-list, and I "umm"ed and "ah"ed about it. It
> really depends on how much work there is, and whether there are any
> other oddities thrown up by OS X that need to be worked around (such as
> the keyboard and networking). It would be nice to have a proper
> installer as well (there is an installer builder in QT apparently,
> though I've not investigated in any detail).
I don't think there's much to do beyond putting the files in a .app bundle
inside a .dmg archive? I don't think there's any need for an installer,
users open the .dmg and just drag RPCEmu.app to /Applications. You'd
probably put the Qt libraries inside the .app so there's no system
dependencies, or even statically link.
Looks like this is the tool to make a bundle including Qt libraries:
http://doc.qt.io/qt-5/osx-deployment.html
A wizard that's roughly 'what ROM image do you want', 'where do you want
your hostfs to go' etc would be nice, but not critical.
My Allegro binaries were pretty much fire-and-forget - I got a few people
asking about stuff, but not a lot.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On 19 Nov 2018, at 21:49, Theo Markettos <theo@markettos.org.uk> wrote:
I'd imagine that most of the US keyboard layout will work, though I've not tried it myself. The code works by defining a base keyboard layout (UK) and you can add additional layouts to the code by telling it which keys are handled differently - so for French, for example, I've told it that "Y" and "Z" are different. It reads the current keyboard layout in when the application starts and goes from there (all in the "src/qt5/keyboard_macosx.c" file). It's probably not the best solution, but it does work. If there are keys on a US layout that are different, it would be trivial to add in the relevant mappings, whilst allowing other layouts to work unaffected. None of this would be needed if you could obtain scan codes from OS X, but you have do make do with virtual keys, handle modifiers separately and handle CAPS LOCK even more separately.
My hacked version would have been pretty awful, even if it had worked. Kernel extensions need to be signed in newer versions of OS X and I'm not a registered developer, so I ended up downloading an application called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which were signed. The emulator would randomly stall during !Boot when setting up networking, so I decided to cut my losses and gave it up as a bad job. I'll have a look at "networkextension", just to see, though I'm not too experienced when it comes to OS X development.
Peter did ask me whether I'd be prepared to create Mac binaries when I emailed him previously off-list, and I "umm"ed and "ah"ed about it. It really depends on how much work there is, and whether there are any other oddities thrown up by OS X that need to be worked around (such as the keyboard and networking). It would be nice to have a proper installer as well (there is an installer builder in QT apparently, though I've not investigated in any detail).
Cheers
Tim
On Mon, Nov 19, 2018 at 07:43:18PM +0000, Timothy Coltman wrote:
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu
0.9.1 that implements keyboard support for OS X/macOS. The file contains
a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
("macosx") containing the icons for the Mac's dock. This should be
unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
4. The patch uses virtual key codes and assumes a UK keyboard layout.
There is support for other keyboard layouts, but needs these to be defined
in the "keyboard_macosx.c" file (there is a very basic French layout
defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I'd imagine that most of the US keyboard layout will work, though I've not tried it myself. The code works by defining a base keyboard layout (UK) and you can add additional layouts to the code by telling it which keys are handled differently - so for French, for example, I've told it that "Y" and "Z" are different. It reads the current keyboard layout in when the application starts and goes from there (all in the "src/qt5/keyboard_macosx.c" file). It's probably not the best solution, but it does work. If there are keys on a US layout that are different, it would be trivial to add in the relevant mappings, whilst allowing other layouts to work unaffected. None of this would be needed if you could obtain scan codes from OS X, but you have do make do with virtual keys, handle modifiers separately and handle CAPS LOCK even more separately.
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
Please note that there is no networking support. I did try and get it up
and running, using some of the code from the "Caliston" builds of Francis
Devereux and whilst it did look promising at one point (I could ping from
one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
My hacked version would have been pretty awful, even if it had worked. Kernel extensions need to be signed in newer versions of OS X and I'm not a registered developer, so I ended up downloading an application called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which were signed. The emulator would randomly stall during !Boot when setting up networking, so I decided to cut my losses and gave it up as a bad job. I'll have a look at "networkextension", just to see, though I'm not too experienced when it comes to OS X development.
Any comments and suggestions would be appreciated. If anyone wants
binaries (so they don't have to compile), please let me know and I'll make
some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Peter did ask me whether I'd be prepared to create Mac binaries when I emailed him previously off-list, and I "umm"ed and "ah"ed about it. It really depends on how much work there is, and whether there are any other oddities thrown up by OS X that need to be worked around (such as the keyboard and networking). It would be nice to have a proper installer as well (there is an installer builder in QT apparently, though I've not investigated in any detail).
Theo
Cheers
Tim
Re: [Rpcemu] Keyboard layout 'UK international with dead keys'
Hi Frank.
I think the issue with dead keys on all operating systems was caused by the switch to Qt. As per the site, the fix was only for Windows unfortunately. I did write an experimental patch to fix it on Linux/X11 but it was never tested as I'm just running Windows here. I think I included it in the patches I sent to Matthew but I don't know if my approach was the right one as it may well have stopped the normal host-side keyboard shortcuts working thereby requiring a workaround for the workaround!
Kind Regards,
James
On Tue, Nov 20, 2018 at 5:16 PM Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:
Finally got round to compiling RPCEmu 0.9.1 (Debian Testing with XFCE).
Noticed the dead keys still didn't work. From the release notes:
"Dead keys are used to compose accented characters, and are not found on
the UK keyboard layout"
Say what?
Somebody missed the layout 'UK international with dead keys' which has
been available for decades? It worked like a charm with the 0.8.x
versions.
May be an idea to keep this in mind for a next version...
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Keyboard layout 'UK international with dead keys'
Finally got round to compiling RPCEmu 0.9.1 (Debian Testing with XFCE).
Noticed the dead keys still didn't work. From the release notes:
"Dead keys are used to compose accented characters, and are not found on
the UK keyboard layout"
Say what?
Somebody missed the layout 'UK international with dead keys' which has
been available for decades? It worked like a charm with the 0.8.x
versions.
May be an idea to keep this in mind for a next version...
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Noticed the dead keys still didn't work. From the release notes:
"Dead keys are used to compose accented characters, and are not found on
the UK keyboard layout"
Say what?
Somebody missed the layout 'UK international with dead keys' which has
been available for decades? It worked like a charm with the 0.8.x
versions.
May be an idea to keep this in mind for a next version...
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 19 November 2018
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On Mon, Nov 19, 2018 at 07:43:18PM +0000, Timothy Coltman wrote:
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS. The file contains
> a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
> ("macosx") containing the icons for the Mac's dock. This should be
> unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
> 4. The patch uses virtual key codes and assumes a UK keyboard layout.
> There is support for other keyboard layouts, but needs these to be defined
> in the "keyboard_macosx.c" file (there is a very basic French layout
> defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
> Please note that there is no networking support. I did try and get it up
> and running, using some of the code from the "Caliston" builds of Francis
> Devereux and whilst it did look promising at one point (I could ping from
> one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
> Any comments and suggestions would be appreciated. If anyone wants
> binaries (so they don't have to compile), please let me know and I'll make
> some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS. The file contains
> a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
> ("macosx") containing the icons for the Mac's dock. This should be
> unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
> 4. The patch uses virtual key codes and assumes a UK keyboard layout.
> There is support for other keyboard layouts, but needs these to be defined
> in the "keyboard_macosx.c" file (there is a very basic French layout
> defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
> Please note that there is no networking support. I did try and get it up
> and running, using some of the code from the "Caliston" builds of Francis
> Devereux and whilst it did look promising at one point (I could ping from
> one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
> Any comments and suggestions would be appreciated. If anyone wants
> binaries (so they don't have to compile), please let me know and I'll make
> some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Patch for 0.9.1 - Mac keyboard support
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu 0.9.1 that implements keyboard support for OS X/macOS. The file contains a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder ("macosx") containing the icons for the Mac's dock. This should be unpacked in the "src" folder and the patch applied from there.
This is a development of the same patch that I had previously posted on the Stardot forums (where I used to post as "VincentVega"), and incorporates some of the suggestions made there.
Once compiled, a Mac RPCEmu application will appear in the top-level "rpcemu-0.9.x" folder. Double-click in the normal way to run. You can compile the interpreter or dynamic recompilation versions - both work on a Mac. The patch has been developed on "Sierra" 10.12.6 - it should hopefully work on all later versions.
When you run the application for the first time, it will prompt you to configure a directory where the emulator can expect to find the various files it needs to run, such as the RISC OS ROMs, hard drive images and so on. This allows you to copy the RPCEmu application into the "/Applications" folder if you want, but keep the other files in a separate location in your home folder. Once you've selected a folder with the "Select" button and pressed "OK" the emulated machine will start as normal. If you want to change the folder at a later date, hold down the "Cmd" key as the application starts. You can also delete the "~/Library/Preferences/org.marutan.rpcemu.plist" file.
There are a few things to note:
1. The keyboard mimics that of a RISC PC, so the key to the left of "Z" is blackslash/pipe and the one to the left of RETURN is hash/tilde.
2. There are a few quirks with the keyboard: SHIFT-3 produces an anged bar; pilcrow (to left of "1") produces a pound sign.
3. F13/F14/F15 on a standard Apple aluminium keyboard are mapped to "Print Screen/SysRq", "Scroll Lock" and "BREAK". "Fn" should be mapped to "INSERT".
4. The patch uses virtual key codes and assumes a UK keyboard layout. There is support for other keyboard layouts, but needs these to be defined in the "keyboard_macosx.c" file (there is a very basic French layout defined that swaps "Y" and "Z").
Please note that there is no networking support. I did try and get it up and running, using some of the code from the "Caliston" builds of Francis Devereux and whilst it did look promising at one point (I could ping from one end), I wasn't able to get it to work fully.
Any comments and suggestions would be appreciated. If anyone wants binaries (so they don't have to compile), please let me know and I'll make some available in due course.
Many thanks.
Tim
Please find attached a ZIP archive (169K) containing a patch for RPCEmu 0.9.1 that implements keyboard support for OS X/macOS. The file contains a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder ("macosx") containing the icons for the Mac's dock. This should be unpacked in the "src" folder and the patch applied from there.
This is a development of the same patch that I had previously posted on the Stardot forums (where I used to post as "VincentVega"), and incorporates some of the suggestions made there.
Once compiled, a Mac RPCEmu application will appear in the top-level "rpcemu-0.9.x" folder. Double-click in the normal way to run. You can compile the interpreter or dynamic recompilation versions - both work on a Mac. The patch has been developed on "Sierra" 10.12.6 - it should hopefully work on all later versions.
When you run the application for the first time, it will prompt you to configure a directory where the emulator can expect to find the various files it needs to run, such as the RISC OS ROMs, hard drive images and so on. This allows you to copy the RPCEmu application into the "/Applications" folder if you want, but keep the other files in a separate location in your home folder. Once you've selected a folder with the "Select" button and pressed "OK" the emulated machine will start as normal. If you want to change the folder at a later date, hold down the "Cmd" key as the application starts. You can also delete the "~/Library/Preferences/org.marutan.rpcemu.plist" file.
There are a few things to note:
1. The keyboard mimics that of a RISC PC, so the key to the left of "Z" is blackslash/pipe and the one to the left of RETURN is hash/tilde.
2. There are a few quirks with the keyboard: SHIFT-3 produces an anged bar; pilcrow (to left of "1") produces a pound sign.
3. F13/F14/F15 on a standard Apple aluminium keyboard are mapped to "Print Screen/SysRq", "Scroll Lock" and "BREAK". "Fn" should be mapped to "INSERT".
4. The patch uses virtual key codes and assumes a UK keyboard layout. There is support for other keyboard layouts, but needs these to be defined in the "keyboard_macosx.c" file (there is a very basic French layout defined that swaps "Y" and "Z").
Please note that there is no networking support. I did try and get it up and running, using some of the code from the "Caliston" builds of Francis Devereux and whilst it did look promising at one point (I could ping from one end), I wasn't able to get it to work fully.
Any comments and suggestions would be appreciated. If anyone wants binaries (so they don't have to compile), please let me know and I'll make some available in due course.
Many thanks.
Tim
Re: [gccsdk] SimpleGit (!Nettle & ssh keys)
On Mon, 19 Nov 2018, Alan Williams wrote:
> It might be worthwhile storing the keys somewhere consistent so pre-shared
> keys stored for the git client can also be used by !nettle. I used
> !Nettle's hot list 'command' field to pass in the key file name, and at
> present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
The openssh package that's currently on riscos.info tries to use keys from
a /ssh folder in Choices. I say "tries" because it looks like some
filename translation issues stop it from working properly.
This was on a system without UnixHome installed - possibly it works a bit
better if that's present (ISTR that an older version of ssh did use
UnixHome).
Regardless, Choices:/ssh seems like a reasonable place to me for storing
SSH keys.
Cheers,
- Jeffrey
_______________________________________________
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
> It might be worthwhile storing the keys somewhere consistent so pre-shared
> keys stored for the git client can also be used by !nettle. I used
> !Nettle's hot list 'command' field to pass in the key file name, and at
> present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
The openssh package that's currently on riscos.info tries to use keys from
a /ssh folder in Choices. I say "tries" because it looks like some
filename translation issues stop it from working properly.
This was on a system without UnixHome installed - possibly it works a bit
better if that's present (ISTR that an older version of ssh did use
UnixHome).
Regardless, Choices:/ssh seems like a reasonable place to me for storing
SSH keys.
Cheers,
- Jeffrey
_______________________________________________
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: [gccsdk] Building OWB
On Fri, 9 Nov 2018 at 15:26, Michael Grunditz
<michael.grunditz@gmail.com> wrote:
> I must miss something ..
Thanks for the reply. I can't see it using gmal. so please cc me.
-fPIC was the main problem.
_______________________________________________
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
<michael.grunditz@gmail.com> wrote:
> I must miss something ..
Thanks for the reply. I can't see it using gmal. so please cc me.
-fPIC was the main problem.
_______________________________________________
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
Sunday, 18 November 2018
Re: [gccsdk] SimpleGit (!Nettle & ssh keys)
> I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
> libssh2 on RISC OS, BICBW.
I believe the stock !Nettle only does user/pass. I worked on this a while
ago and I built a version that would use pre shared keys. It worked ok on
Virtual Acorn but crashed on my pi so I abandoned it and went back to the
stock one. Recently I have updated my RISC OS builder VM with the current
GCC-SDK with a mind to fix this.
It might be worthwhile storing the keys somewhere consistent so pre-shared
keys stored for the git client can also be used by !nettle. I used
!Nettle's hot list 'command' field to pass in the key file name, and at
present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
Alan
On 19/11/18, 10:00 am, "Theo Markettos" <gcc-bounces@gccsdk.riscos.info on
behalf of theo@markettos.org.uk> wrote:
>On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try
>>to get
>> your public/private key by using a Unix domain socket to connect to the
>>ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there
>>are
>> two problems to solve.
>
>That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib
>will handle
>Unix domain sockets (RISC OS doesn't really do IPC as there's no P to
>speak
>of), but if not is there a way to make it use use key files
>($HOME/.ssh/id_rsa and similar)?
>
>I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
>libssh2 on RISC OS, BICBW.
>
>> I've added a !Help file which covers common operations and RISC OS
>>specific
>> usage info. It's a bit awkward to use, but since "awkward git client" is
>> better than "no git client", I think it's probably in a suitable state
>>for
>> us to make a first release.
>
>I'll try and turn the handle manually when I get a minute, unless anyone
>gets there first.
>
>Thanks for the patches,
>Theo
>
>_______________________________________________
>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 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
> libssh2 on RISC OS, BICBW.
I believe the stock !Nettle only does user/pass. I worked on this a while
ago and I built a version that would use pre shared keys. It worked ok on
Virtual Acorn but crashed on my pi so I abandoned it and went back to the
stock one. Recently I have updated my RISC OS builder VM with the current
GCC-SDK with a mind to fix this.
It might be worthwhile storing the keys somewhere consistent so pre-shared
keys stored for the git client can also be used by !nettle. I used
!Nettle's hot list 'command' field to pass in the key file name, and at
present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
Alan
On 19/11/18, 10:00 am, "Theo Markettos" <gcc-bounces@gccsdk.riscos.info on
behalf of theo@markettos.org.uk> wrote:
>On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try
>>to get
>> your public/private key by using a Unix domain socket to connect to the
>>ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there
>>are
>> two problems to solve.
>
>That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib
>will handle
>Unix domain sockets (RISC OS doesn't really do IPC as there's no P to
>speak
>of), but if not is there a way to make it use use key files
>($HOME/.ssh/id_rsa and similar)?
>
>I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
>libssh2 on RISC OS, BICBW.
>
>> I've added a !Help file which covers common operations and RISC OS
>>specific
>> usage info. It's a bit awkward to use, but since "awkward git client" is
>> better than "no git client", I think it's probably in a suitable state
>>for
>> us to make a first release.
>
>I'll try and turn the handle manually when I get a minute, unless anyone
>gets there first.
>
>Thanks for the patches,
>Theo
>
>_______________________________________________
>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 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: [gccsdk] SimpleGit
On Sun, 18 Nov 2018, Theo Markettos wrote:
> On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try to get
>> your public/private key by using a Unix domain socket to connect to the ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there are
>> two problems to solve.
>
> That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
> Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
> of), but if not is there a way to make it use use key files
> ($HOME/.ssh/id_rsa and similar)?
libgit2 does allow programs to provide the keys directly in memory, it's
just not hooked up to sgit. So that would probably be the easiest way of
getting it working.
Cheers,
- Jeffrey
_______________________________________________
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
> On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try to get
>> your public/private key by using a Unix domain socket to connect to the ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there are
>> two problems to solve.
>
> That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
> Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
> of), but if not is there a way to make it use use key files
> ($HOME/.ssh/id_rsa and similar)?
libgit2 does allow programs to provide the keys directly in memory, it's
just not hooked up to sgit. So that would probably be the easiest way of
getting it working.
Cheers,
- Jeffrey
_______________________________________________
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: [gccsdk] SimpleGit
On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
> Also, a quick look through the libssh2 source suggests that it'll try to get
> your public/private key by using a Unix domain socket to connect to the ssh
> agent - which obviously won't exist on RISC OS. So it might be that that
> error message is indicative of that failure, or it might be that there are
> two problems to solve.
That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
of), but if not is there a way to make it use use key files
($HOME/.ssh/id_rsa and similar)?
I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
libssh2 on RISC OS, BICBW.
> I've added a !Help file which covers common operations and RISC OS specific
> usage info. It's a bit awkward to use, but since "awkward git client" is
> better than "no git client", I think it's probably in a suitable state for
> us to make a first release.
I'll try and turn the handle manually when I get a minute, unless anyone
gets there first.
Thanks for the patches,
Theo
_______________________________________________
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
> Also, a quick look through the libssh2 source suggests that it'll try to get
> your public/private key by using a Unix domain socket to connect to the ssh
> agent - which obviously won't exist on RISC OS. So it might be that that
> error message is indicative of that failure, or it might be that there are
> two problems to solve.
That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
of), but if not is there a way to make it use use key files
($HOME/.ssh/id_rsa and similar)?
I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
libssh2 on RISC OS, BICBW.
> I've added a !Help file which covers common operations and RISC OS specific
> usage info. It's a bit awkward to use, but since "awkward git client" is
> better than "no git client", I think it's probably in a suitable state for
> us to make a first release.
I'll try and turn the handle manually when I get a minute, unless anyone
gets there first.
Thanks for the patches,
Theo
_______________________________________________
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: [gccsdk] SimpleGit
On Sat, 10 Nov 2018, Theo Markettos wrote:
> On Sat, Nov 10, 2018 at 10:07:03PM +0000, Jeffrey Lee wrote:
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
>> bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
>> for the time being.
>
> It is, until I get some time to redo the CI system, entirely manual.
>
> When it's stable enough for us to advertise builds, do let us know.
I tested out https and git (ssh) push support today. https works, but ssh
(using public/private key pairs) appears to be broken - generating a
rather un-useful message of "libgit error: No detailed error message!". So
that'll need some debugging to find out where & why it's being generated.
Also, a quick look through the libssh2 source suggests that it'll try to
get your public/private key by using a Unix domain socket to connect to
the ssh agent - which obviously won't exist on RISC OS. So it might be
that that error message is indicative of that failure, or it might be that
there are two problems to solve.
I've added a !Help file which covers common operations and RISC OS
specific usage info. It's a bit awkward to use, but since "awkward git
client" is better than "no git client", I think it's probably in a
suitable state for us to make a first release.
Cheers,
- Jeffrey
_______________________________________________
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
> On Sat, Nov 10, 2018 at 10:07:03PM +0000, Jeffrey Lee wrote:
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
>> bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
>> for the time being.
>
> It is, until I get some time to redo the CI system, entirely manual.
>
> When it's stable enough for us to advertise builds, do let us know.
I tested out https and git (ssh) push support today. https works, but ssh
(using public/private key pairs) appears to be broken - generating a
rather un-useful message of "libgit error: No detailed error message!". So
that'll need some debugging to find out where & why it's being generated.
Also, a quick look through the libssh2 source suggests that it'll try to
get your public/private key by using a Unix domain socket to connect to
the ssh agent - which obviously won't exist on RISC OS. So it might be
that that error message is indicative of that failure, or it might be that
there are two problems to solve.
I've added a !Help file which covers common operations and RISC OS
specific usage info. It's a bit awkward to use, but since "awkward git
client" is better than "no git client", I think it's probably in a
suitable state for us to make a first release.
Cheers,
- Jeffrey
_______________________________________________
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
Thursday, 15 November 2018
Re: [Rpcemu] Mount other Harddrives
In article
<CANc9Z=x2_V7Q4xvbu06vUvcXZDzfysty5rt4WOPMCuwU41zBgw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
[Snip]
> Instructions
> Use the windows filesystem link tool to create a subfolder inside hostfs
> that points to a different location on windows.
> mklink /d FoldernameinHostFS PathToItemYouWantToLink
> Open windows command prompt as administrator
> cd c:/path/to/RPCEmu/hostfs
> mklink /d C C:\
> mklink /d D D:\
> mklink /d X X:\
> You will now have three directories inside your hostfs root folder that
> link directly to the windows drives.
> > Q2) I have a portable USB SSD drive (R:), is there a way to either
> > access or mount that SSD in RPCEmu.
> I believe this should work the same way as above but haven't tested it.
> mklink /d R R:\
> Peter
Thanks for that info Peter, appreciated.
ATM. very busy with other stuff, but later I'll give that a try and
comment afterwards on the result.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CANc9Z=x2_V7Q4xvbu06vUvcXZDzfysty5rt4WOPMCuwU41zBgw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
[Snip]
> Instructions
> Use the windows filesystem link tool to create a subfolder inside hostfs
> that points to a different location on windows.
> mklink /d FoldernameinHostFS PathToItemYouWantToLink
> Open windows command prompt as administrator
> cd c:/path/to/RPCEmu/hostfs
> mklink /d C C:\
> mklink /d D D:\
> mklink /d X X:\
> You will now have three directories inside your hostfs root folder that
> link directly to the windows drives.
> > Q2) I have a portable USB SSD drive (R:), is there a way to either
> > access or mount that SSD in RPCEmu.
> I believe this should work the same way as above but haven't tested it.
> mklink /d R R:\
> Peter
Thanks for that info Peter, appreciated.
ATM. very busy with other stuff, but later I'll give that a try and
comment afterwards on the result.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Mount other Harddrives
> Q1) In RPCEmu Is there a way to Mount the Harddrives in the Host machine
> so they can be accessed from the icon bar as can be done in VRPC?
With multiple icons on the iconbar, no. However there is a workaround, but please read and understand these caveats first
1) The webpage states "and all files used with it should be well backed up before using them with RPCEmu.", this will now include any folders you access via hostfs.
2) Due to the different way that windows/linux and RISC OS deal with filetype information, windows/linux files that do not have a risc os filetype that are loaded by a risc os app are often assigned one, this will rename the file on the windows/linux filesystem. As you can imagine renaming files that are used by windows/linux programs or the system can render them unusable. (This is the same behaviour as VRPC).
3) If and when it all goes wrong, do not whinge here, you got warned, which is more than VRPC has ever done.
Instructions
Use the windows filesystem link tool to create a subfolder inside hostfs that points to a different location on windows.
mklink /d FoldernameinHostFS PathToItemYouWantToLink
Open windows command prompt as administrator
cd c:/path/to/RPCEmu/hostfs
mklink /d C C:\
mklink /d D D:\
mklink /d X X:\
You will now have three directories inside your hostfs root folder that link directly to the windows drives.
> Q2) I have a portable USB SSD drive (R:), is there a way to either access
> or mount that SSD in RPCEmu.
I believe this should work the same way as above but haven't tested it.
mklink /d R R:\
> so they can be accessed from the icon bar as can be done in VRPC?
With multiple icons on the iconbar, no. However there is a workaround, but please read and understand these caveats first
1) The webpage states "and all files used with it should be well backed up before using them with RPCEmu.", this will now include any folders you access via hostfs.
2) Due to the different way that windows/linux and RISC OS deal with filetype information, windows/linux files that do not have a risc os filetype that are loaded by a risc os app are often assigned one, this will rename the file on the windows/linux filesystem. As you can imagine renaming files that are used by windows/linux programs or the system can render them unusable. (This is the same behaviour as VRPC).
3) If and when it all goes wrong, do not whinge here, you got warned, which is more than VRPC has ever done.
Instructions
Use the windows filesystem link tool to create a subfolder inside hostfs that points to a different location on windows.
mklink /d FoldernameinHostFS PathToItemYouWantToLink
Open windows command prompt as administrator
cd c:/path/to/RPCEmu/hostfs
mklink /d C C:\
mklink /d D D:\
mklink /d X X:\
You will now have three directories inside your hostfs root folder that link directly to the windows drives.
> Q2) I have a portable USB SSD drive (R:), is there a way to either access
> or mount that SSD in RPCEmu.
I believe this should work the same way as above but haven't tested it.
mklink /d R R:\
Peter
Re: [Rpcemu] Any fixes for certain games?
> Leigh Randle <LeighRandle@hotmail.com> hat am 14. November 2018 um 21:15 geschrieben:
>
>
> Hi
>
> I'm a new user to RPCEmu and have been able to get some game
> ROMS to work. But one game I particularly wanted to work is
> 4th Dimension's Apocalypse.
>
>
> Hi
>
> I'm a new user to RPCEmu and have been able to get some game
> ROMS to work. But one game I particularly wanted to work is
> 4th Dimension's Apocalypse.
For Gaming purposes, for classic games, it is often better to
use Arculator instead of RPCEmu. Not all classic games are
Risc PC compatible, some are timing-sensitive, and RPCEmu is
not cycle-exact.
> However, I've seen this game working on YouTube with RPCEmu
> specifically, with the same RISK version but older version of RPCEmu.
My guess would be that there are multiple versions of
Apocalypse out there, with a new version possibly patched to
work on a Risc PC, while the original version possibly only
worked on Archimedes/RISC OS 3.1 machines.
I know that a lot of 4th Dimension games have multiple
versions out there - often "RISC OS 3.1x only" vs. "Risc PC compatible"
vs. "StrongARM compatible".
Another possibility would be that someone used GameOn or
StrongGuard to get Apocalypse running on RPCEmu.
The StrongGuard Game database however
https://armclub.org.uk/products/strongguard/
does not mark Apocalypse as being made compatible.
> Are there any solutions to this? Or perhaps any other places I can go to ask?
The Stardot forums are a good place to ask, also the JASPP forum.
Jon Abbott of JASPP will know if there are multiple versions of
Apocalypse floating around, he has catalgued every game in every
variant under the sun.
Have fun
hubersn
--
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
Wednesday, 14 November 2018
Evaluating NetSurf for project
Hello,
I have recently started investigating the possible use of NetSurf for use in my project which is being built on Ubuntu 18.04 and has a majority of it already written in C++ but now need to integrate some features for which NetSurf seems to be a perfect fit.
Currently, I have been able to compile & run the "nsgtk" browser which runs nicely.
Additionally, I have been able to complie the "nsfb" (framebuffer) frontend example which seems to compile just fine, but when I try to run it, I keep getting the same error messages:
--------------------------------------------
~/scraping$ ./nsfb
Message translations failed to load
Unable to initialise framebuffer
--------------------------------------------
I have tired to place the "framebuffer/res" and "netsurf/resources" folders in various locations as described in the documentation, but still I get the same message above.
I think that the nsfb is the starting point that I need, but would like to see it function as the build went well, but just the placement of some files seems to be the problem, although I am not completely sure.
Actually, it would be good to just have the needed "res" folder relative to the nsfb application which seems simplest to me but that is for later.
can you please assist?
Best Regards,
Lonnie T. Cumberland, PhD.
Email: Lonnie.Cumberland@Outstep.com
[Rpcemu] Any fixes for certain games?
Hi
I'm a new user to RPCEmu and have been able to get some game ROMS to work. But one game I particularly wanted to work is 4th Dimension's Apocalypse.
Currently it won't run, regardless of the ROM I use or the settings I use for RPCEmu. First disk is fine, but I can't get the second disk to load up.
However, I've seen this game working on YouTube with RPCEmu specifically, with the same RISK version but older version of RPCEmu.
Are there any solutions to this? Or perhaps any other places I can go to ask?
Best wishes 😊
Leigh.
Sent from Mail for Windows 10
Re: [Rpcemu] RPCEmu (linux) Hangs on seeing uniboot (RO 3.71)
On 26/10/2018 10:39, Richard Walker wrote:
> On Thu, 25 Oct 2018, at 04:38, Bryan Hogan wrote:
>> In message <a7b85a11-151e-bbb7-ba8d-ae4d388f8a38@dewberryfields.co.uk>
>> Michael Howard <mike@dewberryfields.co.uk> wrote:
>>
>>> Using any cpu configuration other that SA causes the emulator to hang as
>>> soon as it 'sees' the uniboot !Boot folder.
>> IIRC this is caused by the StrongARM version of the BootVars program
>> failing on any other cpu type. Maybe you could use a copy of BootVars
>> from an earlier uniboot?
> If there is an issue with BootVars, then I suspect later (post-Acorn?) builds
> will be fine.
>
> You can use the RISC OS 5 disc image (including the boot sequence) on
> versions of RISC OS right back to 3.1.
>
> Apart from historical interest, I'm not sure there is much reason to use
> the old Acorn boot sequence.
Revisiting this ....
> On Thu, 25 Oct 2018, at 04:38, Bryan Hogan wrote:
>> In message <a7b85a11-151e-bbb7-ba8d-ae4d388f8a38@dewberryfields.co.uk>
>> Michael Howard <mike@dewberryfields.co.uk> wrote:
>>
>>> Using any cpu configuration other that SA causes the emulator to hang as
>>> soon as it 'sees' the uniboot !Boot folder.
>> IIRC this is caused by the StrongARM version of the BootVars program
>> failing on any other cpu type. Maybe you could use a copy of BootVars
>> from an earlier uniboot?
> If there is an issue with BootVars, then I suspect later (post-Acorn?) builds
> will be fine.
>
> You can use the RISC OS 5 disc image (including the boot sequence) on
> versions of RISC OS right back to 3.1.
>
> Apart from historical interest, I'm not sure there is much reason to use
> the old Acorn boot sequence.
Revisiting this ....
Although the 'ARM710' option can indeed be used with the latest RISC OS
5 disc image, networking doesn't then work with that image. An ip
address, netmask, route etc can be assigned but no external connectivity
exists.
The only apparent error when setting up networking is that in the 'Host
names' dialog box, only the 'Host name' textbox is editable (the
nameserver boxes are greyed out) and the 'Reset now' button doesn't work
in the final dialog box.
Networking works with the RISC OS 3.7 Uniboot setup, but 'ARM710' does not.
So, my question is, as the only configuration setting that works here
with Uniboot is 'StrongARM', is RPCemu meant to be fully compatible
with 'ARM710' and RISC OS 3.7? If so, how do I achieve it?
Using different versions of BootVars does not resolve the issue. I tried
the newer version from the RISC OS 5 disc image (5.33 I think) and I
can't find any versions older than the one included in Uniboot (5.0).
--
Mike Howard
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 12 November 2018
[Rpcemu] Mount other Harddrives
Q1) In RPCEmu Is there a way to Mount the Harddrives in the Host machine
so they can be accessed from the icon bar as can be done in VRPC?
ATM: I have three drives. C:, D:, and X: (D and X are partitions on a
single spinning rust...
Q2) I have a portable USB SSD drive (R:), is there a way to either access
or mount that SSD in RPCEmu.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
so they can be accessed from the icon bar as can be done in VRPC?
ATM: I have three drives. C:, D:, and X: (D and X are partitions on a
single spinning rust...
Q2) I have a portable USB SSD drive (R:), is there a way to either access
or mount that SSD in RPCEmu.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [gccsdk] SimpleGit
On Sun, 11 Nov 2018, Jeffrey Lee wrote:
> The other things I want to do are to enable libssh2 (for git: protocol
> support) and test pushing via https & git. After that I'll send my updated
> recipes and we can probably upload a proper release.
I didn't really have the time to do anything today, but since Chris has
sorted out the libgit2 compatibility & libssh2, I've gone ahead and
committed the changes I was sitting on for tidying up the packages (also
thanks to Theo for getting me commit access!)
Cheers,
- Jeffrey
_______________________________________________
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
> The other things I want to do are to enable libssh2 (for git: protocol
> support) and test pushing via https & git. After that I'll send my updated
> recipes and we can probably upload a proper release.
I didn't really have the time to do anything today, but since Chris has
sorted out the libgit2 compatibility & libssh2, I've gone ahead and
committed the changes I was sitting on for tidying up the packages (also
thanks to Theo for getting me commit access!)
Cheers,
- Jeffrey
_______________________________________________
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
Sunday, 11 November 2018
Re: [gccsdk] SimpleGit
On Sun, Nov 11, 2018 at 08:33:53PM +0000, Jeffrey Lee wrote:
> However, there is still at least one problem with the simplegit-libgit2
> package: When I pulled in Chris's changes I also ended up pulling in the
> change to autobuilder/fetch-program from rev 7196. This means that instead
> of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
> libgit2-0.24.6 from the stable distro, which is older than the libgit2 that
> simplegit supports, causing at least one build error due to API changes
> (simplegit's integrated version claims to be 0.26.3).
The reason for switching from 'testing stable' to 'stable oldstable' Debian
releases is that a lot of the autobuilder packages date from older Debian
releases. When Debian release a new version they bump 'stable' to new
codebases, which causes us a lot of work to keep up (and in some cases,
packages can't be fixed). Since we don't have the manpower to keep up with
Debian versions, I dropped the sources back to the version before the most
recent Debian release where more things worked.
If you need a particularly current source tree, using an explicit reference
to git sources is the thing to do. Either a particular tag/branch (for
stability), or master if you are optimistic that upstream won't break
something.
Theo
_______________________________________________
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
> However, there is still at least one problem with the simplegit-libgit2
> package: When I pulled in Chris's changes I also ended up pulling in the
> change to autobuilder/fetch-program from rev 7196. This means that instead
> of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
> libgit2-0.24.6 from the stable distro, which is older than the libgit2 that
> simplegit supports, causing at least one build error due to API changes
> (simplegit's integrated version claims to be 0.26.3).
The reason for switching from 'testing stable' to 'stable oldstable' Debian
releases is that a lot of the autobuilder packages date from older Debian
releases. When Debian release a new version they bump 'stable' to new
codebases, which causes us a lot of work to keep up (and in some cases,
packages can't be fixed). Since we don't have the manpower to keep up with
Debian versions, I dropped the sources back to the version before the most
recent Debian release where more things worked.
If you need a particularly current source tree, using an explicit reference
to git sources is the thing to do. Either a particular tag/branch (for
stability), or master if you are optimistic that upstream won't break
something.
Theo
_______________________________________________
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: [gccsdk] SimpleGit
On Sun, 11 Nov 2018, Chris Gransden wrote:
> In article <alpine.WNT.2.00.1811102200330.8924@Jeffrey-PC>,
> Jeffrey Lee <me@phlamethrower.co.uk> wrote:
>> On Sat, 10 Nov 2018, Theo Markettos wrote:
>
>>> Now committed - I renamed it to 'simplegit' because most of the other
>>> packages are lower case. (I'm not sure we have a policy on that)
>
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package
>> a bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
> Hope it's OK. I've checked in some changes to the standalone libgit2 so it
> uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
> in Choices$Write.
That's great, thanks. "sgit status" seems to be a lot faster in this new
version, so it gets my approval!
However, there is still at least one problem with the simplegit-libgit2
package: When I pulled in Chris's changes I also ended up pulling in the
change to autobuilder/fetch-program from rev 7196. This means that instead
of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
libgit2-0.24.6 from the stable distro, which is older than the libgit2
that simplegit supports, causing at least one build error due to API
changes (simplegit's integrated version claims to be 0.26.3).
Possibly the solution there is to switch to fetching libgit2 straight from
its git repo. I'll try and sort that out in the next day or two, unless
someone objects. Plus, changing it to pull the sources from git will make
it easier if/when we fork the repo and start adding our own patches.
The other things I want to do are to enable libssh2 (for git: protocol
support) and test pushing via https & git. After that I'll send my updated
recipes and we can probably upload a proper release.
Cheers,
- Jeffrey
_______________________________________________
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
> In article <alpine.WNT.2.00.1811102200330.8924@Jeffrey-PC>,
> Jeffrey Lee <me@phlamethrower.co.uk> wrote:
>> On Sat, 10 Nov 2018, Theo Markettos wrote:
>
>>> Now committed - I renamed it to 'simplegit' because most of the other
>>> packages are lower case. (I'm not sure we have a policy on that)
>
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package
>> a bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
> Hope it's OK. I've checked in some changes to the standalone libgit2 so it
> uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
> in Choices$Write.
That's great, thanks. "sgit status" seems to be a lot faster in this new
version, so it gets my approval!
However, there is still at least one problem with the simplegit-libgit2
package: When I pulled in Chris's changes I also ended up pulling in the
change to autobuilder/fetch-program from rev 7196. This means that instead
of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
libgit2-0.24.6 from the stable distro, which is older than the libgit2
that simplegit supports, causing at least one build error due to API
changes (simplegit's integrated version claims to be 0.26.3).
Possibly the solution there is to switch to fetching libgit2 straight from
its git repo. I'll try and sort that out in the next day or two, unless
someone objects. Plus, changing it to pull the sources from git will make
it easier if/when we fork the repo and start adding our own patches.
The other things I want to do are to enable libssh2 (for git: protocol
support) and test pushing via https & git. After that I'll send my updated
recipes and we can probably upload a proper release.
Cheers,
- Jeffrey
_______________________________________________
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: [gccsdk] SimpleGit
In article <alpine.WNT.2.00.1811102200330.8924@Jeffrey-PC>,
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Theo Markettos wrote:
> > Now committed - I renamed it to 'simplegit' because most of the other
> > packages are lower case. (I'm not sure we have a policy on that)
> Cheers. I'll hopefully have an update tomorrow that tidies up the package
> a bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
Hope it's OK. I've checked in some changes to the standalone libgit2 so it
uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
in Choices$Write.
_______________________________________________
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
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Theo Markettos wrote:
> > Now committed - I renamed it to 'simplegit' because most of the other
> > packages are lower case. (I'm not sure we have a policy on that)
> Cheers. I'll hopefully have an update tomorrow that tidies up the package
> a bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
Hope it's OK. I've checked in some changes to the standalone libgit2 so it
uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
in Choices$Write.
_______________________________________________
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
Saturday, 10 November 2018
Re: [gccsdk] SimpleGit
On Sat, Nov 10, 2018 at 10:07:03PM +0000, Jeffrey Lee wrote:
> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
> bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
> for the time being.
It is, until I get some time to redo the CI system, entirely manual.
When it's stable enough for us to advertise builds, do let us know.
Theo
_______________________________________________
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
> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
> bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
> for the time being.
It is, until I get some time to redo the CI system, entirely manual.
When it's stable enough for us to advertise builds, do let us know.
Theo
_______________________________________________
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: [gccsdk] SimpleGit
On Sun, 11 Nov 2018, Ron wrote:
> Good to have examples of AB_GIT and cmake useage too.
> A quick look inside the debian src for libgit2 -dev, namely unix/map.c
> shows
>
> #if !defined(GIT_WIN32) && !defined(NO_MMAP)
>
> indicating at least for that file NO_MMAP can be defined.
> could be worth exporting from the setvars file
That's the problem - you turn off mmap and then libgit2's own mmap
emulation moans at you :-)
Possibly it would work with UnixLib's mmap emulation, so that might be
worth trying if we can't work out how to fix libgit2 properly.
Cheers,
- Jeffrey
_______________________________________________
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
> Good to have examples of AB_GIT and cmake useage too.
> A quick look inside the debian src for libgit2 -dev, namely unix/map.c
> shows
>
> #if !defined(GIT_WIN32) && !defined(NO_MMAP)
>
> indicating at least for that file NO_MMAP can be defined.
> could be worth exporting from the setvars file
That's the problem - you turn off mmap and then libgit2's own mmap
emulation moans at you :-)
Possibly it would work with UnixLib's mmap emulation, so that might be
worth trying if we can't work out how to fix libgit2 properly.
Cheers,
- Jeffrey
_______________________________________________
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: [gccsdk] SimpleGit
On Sat, 10 Nov 2018, Theo Markettos wrote:
> Now committed - I renamed it to 'simplegit' because most of the other
> packages are lower case. (I'm not sure we have a policy on that)
Cheers. I'll hopefully have an update tomorrow that tidies up the package
a bit (e.g. proper version number), so if uploading the built version to
riscos.info is a manual thing then it's probably best to hold off on that
for the time being.
- Jeffrey
_______________________________________________
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
> Now committed - I renamed it to 'simplegit' because most of the other
> packages are lower case. (I'm not sure we have a policy on that)
Cheers. I'll hopefully have an update tomorrow that tidies up the package
a bit (e.g. proper version number), so if uploading the built version to
riscos.info is a manual thing then it's probably best to hold off on that
for the time being.
- Jeffrey
_______________________________________________
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: [gccsdk] SimpleGit
On Sat, Nov 10, 2018 at 12:46:10AM +0000, Jeffrey Lee wrote:
> Hi,
>
> Attached is a first-pass autobuilder recipe for SimpleGit
> (https://github.com/sba1/simplegit). The resulting binary seems to work well
> enough to clone repositories via https - I haven't tested it much beyond
> that.
Neat! I wasn't expecting anyone to take my bait so soon :)
Now committed - I renamed it to 'simplegit' because most of the other
packages are lower case. (I'm not sure we have a policy on that)
I also committed the other version as 'simplegit-libgit2' with some warnings
at build time - probably better to keep track of the code in the SVN tree
than in a list attachment that will likely get lost.
I'd be really interested how this build works out - I'd quite like to move
more riscos.info stuff towards git in due course.
Theo
_______________________________________________
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
> Hi,
>
> Attached is a first-pass autobuilder recipe for SimpleGit
> (https://github.com/sba1/simplegit). The resulting binary seems to work well
> enough to clone repositories via https - I haven't tested it much beyond
> that.
Neat! I wasn't expecting anyone to take my bait so soon :)
Now committed - I renamed it to 'simplegit' because most of the other
packages are lower case. (I'm not sure we have a policy on that)
I also committed the other version as 'simplegit-libgit2' with some warnings
at build time - probably better to keep track of the code in the SVN tree
than in a list attachment that will likely get lost.
I'd be really interested how this build works out - I'd quite like to move
more riscos.info stuff towards git in due course.
Theo
_______________________________________________
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: [gccsdk] Patch to update libpng to the latest version
On Fri, Nov 09, 2018 at 03:31:47PM +0000, Cameron Cawley wrote:
> Hi
>
> It appears that the new files added by the patch weren't added as part of
> the commit.
Apologies, I didn't notice there were new files and used 'patch -p0' instead
of 'svn patch'. Now commited as r7209.
Theo
_______________________________________________
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
> Hi
>
> It appears that the new files added by the patch weren't added as part of
> the commit.
Apologies, I didn't notice there were new files and used 'patch -p0' instead
of 'svn patch'. Now commited as r7209.
Theo
_______________________________________________
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: [gccsdk] SimpleGit
In article <alpine.WNT.2.00.1811101643001.8924@Jeffrey-PC>,
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Jeffrey Lee wrote:
> > This recipe builds libgit2 from the submodule that's imported by SimpleGit.
> > But I also have patches for building libgit2 from the upstream libgit2 git
> > repo, so I might experiment with them to produce a libgit2 recipe which
> > SimpleGit can then use instead.
> After a bit of trial and error I managed to get it building in this
> manner - however the upstream libgit2 seems to be broken on systems which
> don't support mmap.
> https://github.com/libgit2/libgit2/issues/4281
> I'm not planning on looking into this any time soon (I'll be sticking to
> the version with the integrated libgit2) - but I have attached the updated
> recipes, just in case anyone else finds them useful. There is a basic
> recipe for http-parser in there which might be useful for other projects.
Good to have examples of AB_GIT and cmake useage too.
A quick look inside the debian src for libgit2 -dev, namely unix/map.c
shows
#if !defined(GIT_WIN32) && !defined(NO_MMAP)
indicating at least for that file NO_MMAP can be defined.
could be worth exporting from the setvars file
Thanks for simplegit
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
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Jeffrey Lee wrote:
> > This recipe builds libgit2 from the submodule that's imported by SimpleGit.
> > But I also have patches for building libgit2 from the upstream libgit2 git
> > repo, so I might experiment with them to produce a libgit2 recipe which
> > SimpleGit can then use instead.
> After a bit of trial and error I managed to get it building in this
> manner - however the upstream libgit2 seems to be broken on systems which
> don't support mmap.
> https://github.com/libgit2/libgit2/issues/4281
> I'm not planning on looking into this any time soon (I'll be sticking to
> the version with the integrated libgit2) - but I have attached the updated
> recipes, just in case anyone else finds them useful. There is a basic
> recipe for http-parser in there which might be useful for other projects.
Good to have examples of AB_GIT and cmake useage too.
A quick look inside the debian src for libgit2 -dev, namely unix/map.c
shows
#if !defined(GIT_WIN32) && !defined(NO_MMAP)
indicating at least for that file NO_MMAP can be defined.
could be worth exporting from the setvars file
Thanks for simplegit
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
Subscribe to:
Posts (Atom)