> 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
Subscribe to:
Posts (Atom)