John Ballance wrote on Wednesday, December 02, 2015 8:21 PM:
> In a thing I'm working on has the main build dir in a subdir of its source
> tree.
> It does a make and make install something like (cd $myblddir; $AB_MAKE)
> However, whilst it appears that ab_make() and ab_package() can be
> overridden
> in the setvars file, I don't seem to be able to override the
> ab_distclean() function?..
> Should I be able to, or, does the autobuilder build-program script need
> amending to permit this?
I've had a look at the code in build-program this weekend and there isn't an
ab_distclean
overidable function. Instead it does an eval $AB_DISTCLEAN so you would need
to set
the AB_DISTCLEAN variable to the command required to do the clean.
I'm not sure why the distclean didn't follow the same pattern as the others.
Would you be able to set a command in AB_DISTCLEAN for your project?
If not, then I will have a look at what's required to modify build-program
to
provide an ab_distclean override.
Regards,
Alan
_______________________________________________
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, 7 December 2015
Sunday, 6 December 2015
Re: [gccsdk] Autobuilder library packaging
Alan intended to send this to the list...
----- Forwarded message from alan buckley <alan_baa@hotmail.com> -----
From: alan buckley <alan_baa@hotmail.com>
To: Theo Markettos <theo@markettos.org.uk>
Subject: RE: [gccsdk] Autobuilder library packaging
Date: Mon, 30 Nov 2015 08:44:10 +0000
> On Sun, 29 Nov 2015 23:15:21 +0000 Theo Markettos wrote:
>
> Can someone explain the difference between the three library packaging
> streams? I've been trying to work out what's happening with DeskLib, and
> I'm a bit confused.
>
> There are three archives made:
> autobuilder_libraries/desklib_svn_...tar
> autobuilder_libraries/desklib_svn_...zip
> autobuilder_packages/Library/desklib_svn...zip
>
> I had assumed that autobuilder_packages/.../*.zip was for publication of RISC OS
> builds that are destined for PackMan installation - ie should be RISC OS
> applications containing files suitable for use by a compiler on RISC OS, ie
> suffix swapping (h/foo).
That is correct.
>
> I'd assumed that autobuilder_libraries was for downstream consumption by the
> autobuilder - ie you can untar autobuilder_libraries/*.tar in your
> GCCSDK_INSTALL_ENV to allow the cross compiler to use that library.
>
> It seems that autobuilder_libraries/*.zip are getting suffix swapped, but
> autobuilder_packages/**/*.zip are not. But autobuilder_libraries/*.zip are
> not being packaged, they're just collections of header and library files.
> So if users install the autobuilder_packages/**/*.zip then they have files
> in RISC OS called include.foo/h which GCC won't find.
>
> I can understand the need for two library packages, but three?
> http://www.riscos.info/index.php/Autobuilder_development
> just says 'Libraries: to be added'
>
Originally autobuilder_libraries was zip file with the headers and static libraries
in unix format. Peter Naulls created them for me so I could build programs on
Cygwin which needed libraries I could not create on Cygwin.
They were then also used as an intermediate step in creating the
packages for libraries. i.e. they were unzipped copied to the correct
place for the package and suffix swapped in the ab_package function
in setvars.
At some stage it appears that someone modified the ro-libpack file
that creates these to do suffix swapping here as well. I'm not sure
why.
Theo, I thought you created the tgz files for consumption by Jenkins, but it
looks like they were done by someone else. I've just modified them so they
include symbolic links to work better with Jenkins.
Hopefully someone can come along and explain why ro-libpack was changed.
I suspect we can probably get rid of the zip file, and use the tgz file in the
same way the zip file used to be used.
In my opinion, what should be happening in the future is that
autobuilder_packages stays the same as it is. i.e. versions destined to be
unpacked and used on RISC OS machines via PackMan or the
website with suffixes swapped, and autobuilder_libraries should
only contain one of tgz or zip which is in a format that can be
consumed by Jenkins, copied to a new unix machine and used
by ab_package to create the library packages.
> Where is the right place to put suffix swapping so that combinations work
> out? The Desklib setvars just says:
>
> ab_package() {
>
> ab_create_app DeskLib Apps/Library desklib
>
> rsync -av --exclude='*/.svn*' ../\!DLUser $A/..
> rsync -av --exclude='*/.svn*' ../\!DeskLib $A/..
> rsync -av --exclude='*/.svn*' ../Examples $A/../\!DeskLib
>
> $AB_HOME/add-riscpkg -name DeskLib -unixlib
> }
>
> Which looks pretty uncontroversial to me. I haven't looked at RISC OS
> packages of other libraries, but imagine they're similarly affected.
That's fine. It's probably done that way as DeskLib is a pure RISC OS
library. As I said above some ported library, also create the autobuilder_libraries
version first and then use that in packaging.
If Jenkins ever needs to build something that uses DeskLib, it will probably
need to create an autobuilder_libraries version as well. This should be done
using the variables, so ro-libpack is called. AB_INSTALLENV etc? Sorry I can't
check what they are at the moment.
>
> I can figure some things out from the code, but was wondering what the
> philosophy was supposed to be, so I don't end up breaking other things.
>
I hope that explains it, there have been some modifications I don't understand
though and it looks like it could do with being cleaned up.
Regards,
Alan
----- End forwarded message -----
_______________________________________________
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
----- Forwarded message from alan buckley <alan_baa@hotmail.com> -----
From: alan buckley <alan_baa@hotmail.com>
To: Theo Markettos <theo@markettos.org.uk>
Subject: RE: [gccsdk] Autobuilder library packaging
Date: Mon, 30 Nov 2015 08:44:10 +0000
> On Sun, 29 Nov 2015 23:15:21 +0000 Theo Markettos wrote:
>
> Can someone explain the difference between the three library packaging
> streams? I've been trying to work out what's happening with DeskLib, and
> I'm a bit confused.
>
> There are three archives made:
> autobuilder_libraries/desklib_svn_...tar
> autobuilder_libraries/desklib_svn_...zip
> autobuilder_packages/Library/desklib_svn...zip
>
> I had assumed that autobuilder_packages/.../*.zip was for publication of RISC OS
> builds that are destined for PackMan installation - ie should be RISC OS
> applications containing files suitable for use by a compiler on RISC OS, ie
> suffix swapping (h/foo).
That is correct.
>
> I'd assumed that autobuilder_libraries was for downstream consumption by the
> autobuilder - ie you can untar autobuilder_libraries/*.tar in your
> GCCSDK_INSTALL_ENV to allow the cross compiler to use that library.
>
> It seems that autobuilder_libraries/*.zip are getting suffix swapped, but
> autobuilder_packages/**/*.zip are not. But autobuilder_libraries/*.zip are
> not being packaged, they're just collections of header and library files.
> So if users install the autobuilder_packages/**/*.zip then they have files
> in RISC OS called include.foo/h which GCC won't find.
>
> I can understand the need for two library packages, but three?
> http://www.riscos.info/index.php/Autobuilder_development
> just says 'Libraries: to be added'
>
Originally autobuilder_libraries was zip file with the headers and static libraries
in unix format. Peter Naulls created them for me so I could build programs on
Cygwin which needed libraries I could not create on Cygwin.
They were then also used as an intermediate step in creating the
packages for libraries. i.e. they were unzipped copied to the correct
place for the package and suffix swapped in the ab_package function
in setvars.
At some stage it appears that someone modified the ro-libpack file
that creates these to do suffix swapping here as well. I'm not sure
why.
Theo, I thought you created the tgz files for consumption by Jenkins, but it
looks like they were done by someone else. I've just modified them so they
include symbolic links to work better with Jenkins.
Hopefully someone can come along and explain why ro-libpack was changed.
I suspect we can probably get rid of the zip file, and use the tgz file in the
same way the zip file used to be used.
In my opinion, what should be happening in the future is that
autobuilder_packages stays the same as it is. i.e. versions destined to be
unpacked and used on RISC OS machines via PackMan or the
website with suffixes swapped, and autobuilder_libraries should
only contain one of tgz or zip which is in a format that can be
consumed by Jenkins, copied to a new unix machine and used
by ab_package to create the library packages.
> Where is the right place to put suffix swapping so that combinations work
> out? The Desklib setvars just says:
>
> ab_package() {
>
> ab_create_app DeskLib Apps/Library desklib
>
> rsync -av --exclude='*/.svn*' ../\!DLUser $A/..
> rsync -av --exclude='*/.svn*' ../\!DeskLib $A/..
> rsync -av --exclude='*/.svn*' ../Examples $A/../\!DeskLib
>
> $AB_HOME/add-riscpkg -name DeskLib -unixlib
> }
>
> Which looks pretty uncontroversial to me. I haven't looked at RISC OS
> packages of other libraries, but imagine they're similarly affected.
That's fine. It's probably done that way as DeskLib is a pure RISC OS
library. As I said above some ported library, also create the autobuilder_libraries
version first and then use that in packaging.
If Jenkins ever needs to build something that uses DeskLib, it will probably
need to create an autobuilder_libraries version as well. This should be done
using the variables, so ro-libpack is called. AB_INSTALLENV etc? Sorry I can't
check what they are at the moment.
>
> I can figure some things out from the code, but was wondering what the
> philosophy was supposed to be, so I don't end up breaking other things.
>
I hope that explains it, there have been some modifications I don't understand
though and it looks like it could do with being cleaned up.
Regards,
Alan
----- End forwarded message -----
_______________________________________________
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] GCC version
On Mon, Nov 30, 2015 at 08:13:01PM +0000, David Pitt wrote:
> Theo Markettos, on 30 Nov, wrote:
>
> > On Mon, Nov 30, 2015 at 04:28:49PM +0000, Gavin Wraith wrote:
> > > When I do *gcc --version I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4"
> > > . But when I do *show GCC$Version I get "GCC$Version : 4.7.4 Release 1".
> > > I think my !GCC.!Boot, which sets GCC$Version, is either too old or
> > > wrong. Does anybody else have this?
> >
> > That's my fault for not knowing about that setting when I did the version
> > bump.
> >
> > Does anything use GCC$Version?
>
> Not in any substantial way but see HelpScan Lite at :-
> http://www.snowstone.org.uk/riscos/index.html
>
> Isn't it part of Castle's "Application System Variables"?
> http://www.iyonix.com/32bit/help.shtml
> I don't know whether that is still policy under ROOL having failed to find
> any recent mention of it.
Thanks. I've now bumped the version in SVN to 4.7.4 release 3 - which will
be right for the next release. I don't want to change the release 2 build as
that will have other knock-on effects, so we'll have to live with it being
wrong until the next release.
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
> Theo Markettos, on 30 Nov, wrote:
>
> > On Mon, Nov 30, 2015 at 04:28:49PM +0000, Gavin Wraith wrote:
> > > When I do *gcc --version I get "gcc (GCCSDK GCC 4.7.4 Release 2) 4.7.4"
> > > . But when I do *show GCC$Version I get "GCC$Version : 4.7.4 Release 1".
> > > I think my !GCC.!Boot, which sets GCC$Version, is either too old or
> > > wrong. Does anybody else have this?
> >
> > That's my fault for not knowing about that setting when I did the version
> > bump.
> >
> > Does anything use GCC$Version?
>
> Not in any substantial way but see HelpScan Lite at :-
> http://www.snowstone.org.uk/riscos/index.html
>
> Isn't it part of Castle's "Application System Variables"?
> http://www.iyonix.com/32bit/help.shtml
> I don't know whether that is still policy under ROOL having failed to find
> any recent mention of it.
Thanks. I've now bumped the version in SVN to 4.7.4 release 3 - which will
be right for the next release. I don't want to change the release 2 build as
that will have other knock-on effects, so we'll have to live with it being
wrong until the next release.
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
Saturday, 5 December 2015
Re: Segfault: issue 2381
In article <4ffc282455.DaveMeUK@my.inbox.com>,
Dave Higton <dave@davehigton.me.uk> wrote:
> Well, I must say, I've never seen multiple versions kept that way!
> From what I've understood, reading the !Boot and !Run files just
> now, your method should work fine.
I've been away and a little busy but having deleted everything I could
find that might have been !NetSurf related and trimmed my !Fonts down to
only 10 remaining, I've got a fresh copy of 3.2 running correctly.
Having an ARMX6, I deleted the !Fonts directory completely and copied
across the one from the recovery disk image, plus MathPhys (required by
!TechWriter. My 3.2 came from the same source.
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
Dave Higton <dave@davehigton.me.uk> wrote:
> Well, I must say, I've never seen multiple versions kept that way!
> From what I've understood, reading the !Boot and !Run files just
> now, your method should work fine.
I've been away and a little busy but having deleted everything I could
find that might have been !NetSurf related and trimmed my !Fonts down to
only 10 remaining, I've got a fresh copy of 3.2 running correctly.
Having an ARMX6, I deleted the !Fonts directory completely and copied
across the one from the recovery disk image, plus MathPhys (required by
!TechWriter. My 3.2 came from the same source.
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
Re: [Rpcemu] CMOS
Hi,
> I've saved a copy of the corrupted cmos.ram file and after putting it
> and the good version in Zap... There are differences, but to be honest
> I have no idea what the differences mean, except Corrupted.
...
> They are in an archive on http://www.triffid.co.uk/dstuff/Seemoss.zip
In case it helps others,
$ dump() { hexdump -ve '/1 "%2_ax %3_ad %2x\n"' "$@"; }
$ sdiff -lw42 <(dump cmos.ram) <(dump cmos.ramCorrupt)
0 0 0 (
1 1 0 (
2 2 14 | 2 2 49
3 3 11 | 3 3 7
4 4 6 (
5 5 c5 (
6 6 d2 (
7 7 0 (
8 8 0 (
9 9 0 (
a 10 0 (
b 11 0 (
c 12 0 (
d 13 0 (
e 14 0 (
f 15 0 (
10 16 0 (
11 17 76 (
12 18 6 | 12 18 2
13 19 50 (
14 20 0 (
15 21 6c | 15 21 6f
16 22 d1 | 16 22 40
17 23 0 | 17 23 ff
18 24 87 | 18 24 40
19 25 0 (
1a 26 28 (
1b 27 3c (
1c 28 0 (
1d 29 0 (
1e 30 0 (
1f 31 0 (
20 32 0 (
21 33 0 (
22 34 0 (
23 35 0 (
24 36 0 (
25 37 0 (
26 38 0 (
27 39 0 (
28 40 0 (
29 41 0 (
2a 42 0 (
2b 43 0 (
2c 44 10 (
2d 45 0 (
2e 46 0 | 2e 46 80
2f 47 0 (
30 48 0 | 30 48 c0
31 49 0 | 31 49 a8
32 50 0 (
33 51 0 | 33 51 1
34 52 0 (
35 53 0 (
36 54 0 (
37 55 2 | 37 55 0
38 56 0 (
39 57 0 (
3a 58 0 (
3b 59 0 (
3c 60 0 (
3d 61 0 (
3e 62 ea (
3f 63 2e | 3f 63 de
40 64 0 (
41 65 fe (
42 66 0 (
43 67 eb (
44 68 0 (
45 69 99 | 45 69 8
46 70 0 (
47 71 0 (
48 72 0 (
49 73 0 (
4a 74 10 (
4b 75 44 (
4c 76 20 (
4d 77 8 (
4e 78 a (
4f 79 2c (
50 80 91 | 50 80 90
51 81 0 | 51 81 2
52 82 0 (
53 83 0 (
54 84 0 (
55 85 0 (
56 86 0 (
57 87 0 (
58 88 0 (
59 89 0 | 59 89 8
5a 90 0 (
5b 91 0 (
5c 92 13 | 5c 92 c3
5d 93 0 (
5e 94 0 (
5f 95 0 (
60 96 0 (
61 97 0 (
62 98 0 (
63 99 0 (
64 100 0 (
65 101 0 (
66 102 0 (
67 103 0 (
68 104 0 (
69 105 0 (
6a 106 0 (
6b 107 0 (
6c 108 0 (
6d 109 0 (
6e 110 0 (
6f 111 0 (
70 112 0 (
71 113 0 (
72 114 0 (
73 115 0 (
74 116 0 (
75 117 0 (
76 118 0 (
77 119 0 (
78 120 0 (
79 121 0 (
7a 122 0 (
7b 123 0 (
7c 124 0 (
7d 125 0 (
7e 126 0 (
7f 127 0 (
80 128 0 (
81 129 0 (
82 130 0 (
83 131 0 (
84 132 0 (
85 133 0 (
86 134 0 (
87 135 0 (
88 136 0 (
89 137 0 (
8a 138 0 (
8b 139 0 (
8c 140 0 (
8d 141 0 (
8e 142 0 (
8f 143 0 (
90 144 0 (
91 145 0 | 91 145 20
92 146 0 (
93 147 0 (
94 148 0 (
95 149 0 (
96 150 0 (
97 151 0 (
98 152 0 (
99 153 0 (
9a 154 0 (
9b 155 0 (
9c 156 0 (
9d 157 0 (
9e 158 0 (
9f 159 0 (
a0 160 0 (
a1 161 0 (
a2 162 0 (
a3 163 0 (
a4 164 0 (
a5 165 0 (
a6 166 0 (
a7 167 0 (
a8 168 0 (
a9 169 0 (
aa 170 0 (
ab 171 1 | ab 171 0
ac 172 0 | ac 172 c0
ad 173 0 | ad 173 a8
ae 174 0 (
af 175 0 | af 175 c5
b0 176 0 (
b1 177 0 (
b2 178 0 (
b3 179 0 (
b4 180 0 (
b5 181 0 (
b6 182 0 (
b7 183 0 (
b8 184 0 (
b9 185 0 (
ba 186 0 (
bb 187 0 (
bc 188 0 (
bd 189 0 (
be 190 0 (
bf 191 0 (
c0 192 f (
c1 193 14 (
c2 194 0 (
c3 195 0 (
c4 196 a4 (
c5 197 fd (
c6 198 10 (
c7 199 0 | c7 199 41
c8 200 ff (
c9 201 1 | c9 201 ff
ca 202 a1 | ca 202 60
cb 203 0 (
cc 204 1 | cc 204 31
cd 205 0 (
ce 206 0 (
cf 207 0 (
d0 208 0 (
d1 209 2 (
d2 210 40 | d2 210 0
d3 211 0 (
d4 212 d1 | d4 212 f0
d5 213 0 | d5 213 ff
d6 214 0 | d6 214 ff
d7 215 0 | d7 215 ff
d8 216 0 | d8 216 ff
d9 217 0 (
da 218 0 (
db 219 0 (
dc 220 0 (
dd 221 0 (
de 222 0 (
df 223 0 (
e0 224 0 (
e1 225 0 (
e2 226 0 (
e3 227 0 (
e4 228 0 (
e5 229 0 (
e6 230 0 (
e7 231 0 (
e8 232 0 (
e9 233 0 (
ea 234 0 (
eb 235 0 (
ec 236 0 (
ed 237 0 (
ee 238 0 (
ef 239 0 (
f0 240 0 (
f1 241 0 (
f2 242 0 (
f3 243 0 (
f4 244 0 (
f5 245 0 (
f6 246 0 (
f7 247 0 (
f8 248 0 (
f9 249 a | f9 249 0
fa 250 1 (
fb 251 0 (
fc 252 0 (
fd 253 d0 | fd 253 0
fe 254 0 (
ff 255 0 (
$
I don't know if http://www.riscos.com/support/developers/prm/cmos.html
is still relevant.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I've saved a copy of the corrupted cmos.ram file and after putting it
> and the good version in Zap... There are differences, but to be honest
> I have no idea what the differences mean, except Corrupted.
...
> They are in an archive on http://www.triffid.co.uk/dstuff/Seemoss.zip
In case it helps others,
$ dump() { hexdump -ve '/1 "%2_ax %3_ad %2x\n"' "$@"; }
$ sdiff -lw42 <(dump cmos.ram) <(dump cmos.ramCorrupt)
0 0 0 (
1 1 0 (
2 2 14 | 2 2 49
3 3 11 | 3 3 7
4 4 6 (
5 5 c5 (
6 6 d2 (
7 7 0 (
8 8 0 (
9 9 0 (
a 10 0 (
b 11 0 (
c 12 0 (
d 13 0 (
e 14 0 (
f 15 0 (
10 16 0 (
11 17 76 (
12 18 6 | 12 18 2
13 19 50 (
14 20 0 (
15 21 6c | 15 21 6f
16 22 d1 | 16 22 40
17 23 0 | 17 23 ff
18 24 87 | 18 24 40
19 25 0 (
1a 26 28 (
1b 27 3c (
1c 28 0 (
1d 29 0 (
1e 30 0 (
1f 31 0 (
20 32 0 (
21 33 0 (
22 34 0 (
23 35 0 (
24 36 0 (
25 37 0 (
26 38 0 (
27 39 0 (
28 40 0 (
29 41 0 (
2a 42 0 (
2b 43 0 (
2c 44 10 (
2d 45 0 (
2e 46 0 | 2e 46 80
2f 47 0 (
30 48 0 | 30 48 c0
31 49 0 | 31 49 a8
32 50 0 (
33 51 0 | 33 51 1
34 52 0 (
35 53 0 (
36 54 0 (
37 55 2 | 37 55 0
38 56 0 (
39 57 0 (
3a 58 0 (
3b 59 0 (
3c 60 0 (
3d 61 0 (
3e 62 ea (
3f 63 2e | 3f 63 de
40 64 0 (
41 65 fe (
42 66 0 (
43 67 eb (
44 68 0 (
45 69 99 | 45 69 8
46 70 0 (
47 71 0 (
48 72 0 (
49 73 0 (
4a 74 10 (
4b 75 44 (
4c 76 20 (
4d 77 8 (
4e 78 a (
4f 79 2c (
50 80 91 | 50 80 90
51 81 0 | 51 81 2
52 82 0 (
53 83 0 (
54 84 0 (
55 85 0 (
56 86 0 (
57 87 0 (
58 88 0 (
59 89 0 | 59 89 8
5a 90 0 (
5b 91 0 (
5c 92 13 | 5c 92 c3
5d 93 0 (
5e 94 0 (
5f 95 0 (
60 96 0 (
61 97 0 (
62 98 0 (
63 99 0 (
64 100 0 (
65 101 0 (
66 102 0 (
67 103 0 (
68 104 0 (
69 105 0 (
6a 106 0 (
6b 107 0 (
6c 108 0 (
6d 109 0 (
6e 110 0 (
6f 111 0 (
70 112 0 (
71 113 0 (
72 114 0 (
73 115 0 (
74 116 0 (
75 117 0 (
76 118 0 (
77 119 0 (
78 120 0 (
79 121 0 (
7a 122 0 (
7b 123 0 (
7c 124 0 (
7d 125 0 (
7e 126 0 (
7f 127 0 (
80 128 0 (
81 129 0 (
82 130 0 (
83 131 0 (
84 132 0 (
85 133 0 (
86 134 0 (
87 135 0 (
88 136 0 (
89 137 0 (
8a 138 0 (
8b 139 0 (
8c 140 0 (
8d 141 0 (
8e 142 0 (
8f 143 0 (
90 144 0 (
91 145 0 | 91 145 20
92 146 0 (
93 147 0 (
94 148 0 (
95 149 0 (
96 150 0 (
97 151 0 (
98 152 0 (
99 153 0 (
9a 154 0 (
9b 155 0 (
9c 156 0 (
9d 157 0 (
9e 158 0 (
9f 159 0 (
a0 160 0 (
a1 161 0 (
a2 162 0 (
a3 163 0 (
a4 164 0 (
a5 165 0 (
a6 166 0 (
a7 167 0 (
a8 168 0 (
a9 169 0 (
aa 170 0 (
ab 171 1 | ab 171 0
ac 172 0 | ac 172 c0
ad 173 0 | ad 173 a8
ae 174 0 (
af 175 0 | af 175 c5
b0 176 0 (
b1 177 0 (
b2 178 0 (
b3 179 0 (
b4 180 0 (
b5 181 0 (
b6 182 0 (
b7 183 0 (
b8 184 0 (
b9 185 0 (
ba 186 0 (
bb 187 0 (
bc 188 0 (
bd 189 0 (
be 190 0 (
bf 191 0 (
c0 192 f (
c1 193 14 (
c2 194 0 (
c3 195 0 (
c4 196 a4 (
c5 197 fd (
c6 198 10 (
c7 199 0 | c7 199 41
c8 200 ff (
c9 201 1 | c9 201 ff
ca 202 a1 | ca 202 60
cb 203 0 (
cc 204 1 | cc 204 31
cd 205 0 (
ce 206 0 (
cf 207 0 (
d0 208 0 (
d1 209 2 (
d2 210 40 | d2 210 0
d3 211 0 (
d4 212 d1 | d4 212 f0
d5 213 0 | d5 213 ff
d6 214 0 | d6 214 ff
d7 215 0 | d7 215 ff
d8 216 0 | d8 216 ff
d9 217 0 (
da 218 0 (
db 219 0 (
dc 220 0 (
dd 221 0 (
de 222 0 (
df 223 0 (
e0 224 0 (
e1 225 0 (
e2 226 0 (
e3 227 0 (
e4 228 0 (
e5 229 0 (
e6 230 0 (
e7 231 0 (
e8 232 0 (
e9 233 0 (
ea 234 0 (
eb 235 0 (
ec 236 0 (
ed 237 0 (
ee 238 0 (
ef 239 0 (
f0 240 0 (
f1 241 0 (
f2 242 0 (
f3 243 0 (
f4 244 0 (
f5 245 0 (
f6 246 0 (
f7 247 0 (
f8 248 0 (
f9 249 a | f9 249 0
fa 250 1 (
fb 251 0 (
fc 252 0 (
fd 253 d0 | fd 253 0
fe 254 0 (
ff 255 0 (
$
I don't know if http://www.riscos.com/support/developers/prm/cmos.html
is still relevant.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 4 December 2015
[Rpcemu] CMOS
Win 7 Pro 64 bit SP-1
RPCEmu 0.8.13 and RISC OS 6.20
The cmos.ram file that resides in the RPCEmu appdir has become corrupted
twice in the recent few days and I have no idea why.
I've saved a copy of the corrupted cmos.ram file and after putting it and
the good version in Zap... There are differences, but to be honest I have
no idea what the differences mean, except Corrupted.
Any kind person able to read this stuff and say "Ah your grommet was not
configured correctly" or whatever?
They are in an archive on http://www.triffid.co.uk/dstuff/Seemoss.zip
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
RPCEmu 0.8.13 and RISC OS 6.20
The cmos.ram file that resides in the RPCEmu appdir has become corrupted
twice in the recent few days and I have no idea why.
I've saved a copy of the corrupted cmos.ram file and after putting it and
the good version in Zap... There are differences, but to be honest I have
no idea what the differences mean, except Corrupted.
Any kind person able to read this stuff and say "Ah your grommet was not
configured correctly" or whatever?
They are in an archive on http://www.triffid.co.uk/dstuff/Seemoss.zip
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 2 December 2015
[gccsdk] Autobuilder query
Hi
In a thing I'm working on has the main build dir in a subdir of its source tree.
It does a make and make install something like (cd $myblddir; $AB_MAKE)
However, whilst it appears that ab_make() and ab_package() can be overridden in the setvars file, I don't seem to be able to override the ab_distclean() function?..
Should I be able to, or, does the autobuilder build-program script need amending to permit this?
Thanks
John
In a thing I'm working on has the main build dir in a subdir of its source tree.
It does a make and make install something like (cd $myblddir; $AB_MAKE)
However, whilst it appears that ab_make() and ab_package() can be overridden in the setvars file, I don't seem to be able to override the ab_distclean() function?..
Should I be able to, or, does the autobuilder build-program script need amending to permit this?
Thanks
John
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Subscribe to:
Posts (Atom)