On Thu, Jan 30, 2014 at 11:51:34PM +0000, Steve Fryatt wrote:
> On 30 Jan, Daniel Silverstone wrote in message
> <20140130120127.GK26047@somnambulist.local>:
>
> > On Sun, Jan 26, 2014 at 15:44:17 +0000, Steve Fryatt wrote:
> >
> > > PS: Should I be deleting my branches once they're merged? If so, what's
> > > the preferred way to do it?
> >
> > Yes, [...]
>
> Thanks -- I've tidied up after myself now.
I merged your menus branch again, so assuming the merge was correct
you can remove that too.
--
Regards Vincent
http://www.kyllikki.org/
Friday, 31 January 2014
Re: Paypal bank transfer
On 26 Jan 2014 as I do recall,
Cristopher Dewhurst wrote:
[snip]
> Where do you find the options to transfer to/withdraw from bank
> account? As far I know it's in a ribbon of options which doesn't
> appear in Netsurf, though does in other browsers. Is there an
> alternative way of getting at it?
>
When I log in to Paypal.co.uk I get presented with a warning screen
reading 'Logging you in securely...' and under that a list of links
starting with 'My Account' and going down through 'Overview', 'Add
Funds' and 'Withdraw' - 'Transfer to Bank Account' is a subcategory of
'Withdraw' (although in practice the links seem to go to the same page).
However, it no longer works with NetSurf, and nor does the 'Send Money'
link in the second column (haven't tried any of the others recently...)
so I'm not sure how much use this information is. :-(
--
Harriet Bazley == Loyaulte me lie ==
When you breathe you inspire; when you do not breathe, you expire.
Cristopher Dewhurst wrote:
[snip]
> Where do you find the options to transfer to/withdraw from bank
> account? As far I know it's in a ribbon of options which doesn't
> appear in Netsurf, though does in other browsers. Is there an
> alternative way of getting at it?
>
When I log in to Paypal.co.uk I get presented with a warning screen
reading 'Logging you in securely...' and under that a list of links
starting with 'My Account' and going down through 'Overview', 'Add
Funds' and 'Withdraw' - 'Transfer to Bank Account' is a subcategory of
'Withdraw' (although in practice the links seem to go to the same page).
However, it no longer works with NetSurf, and nor does the 'Send Money'
link in the second column (haven't tried any of the others recently...)
so I'm not sure how much use this information is. :-(
--
Harriet Bazley == Loyaulte me lie ==
When you breathe you inspire; when you do not breathe, you expire.
Thursday, 30 January 2014
Re: Long URLs on RISC OS
On 30 Jan, Daniel Silverstone wrote in message
<20140130120127.GK26047@somnambulist.local>:
> On Sun, Jan 26, 2014 at 15:44:17 +0000, Steve Fryatt wrote:
>
> > PS: Should I be deleting my branches once they're merged? If so, what's
> > the preferred way to do it?
>
> Yes, [...]
Thanks -- I've tidied up after myself now.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<20140130120127.GK26047@somnambulist.local>:
> On Sun, Jan 26, 2014 at 15:44:17 +0000, Steve Fryatt wrote:
>
> > PS: Should I be deleting my branches once they're merged? If so, what's
> > the preferred way to do it?
>
> Yes, [...]
Thanks -- I've tidied up after myself now.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: Long URLs on RISC OS
On Sun, Jan 26, 2014 at 15:44:17 +0000, Steve Fryatt wrote:
> PS: Should I be deleting my branches once they're merged? If so, what's the
> preferred way to do it?
Yes, an easy way to tell if your branches on the server have been merged is:
git checkout origin/master (this detaches you but it's okay)
git branch -r --merged
git checkout mybranchname
Any of the merged branches which are yours can be removed with:
git push --delete origin branchname
e.g.
git push --delete origin stevef/mad-riscos-badgers
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> PS: Should I be deleting my branches once they're merged? If so, what's the
> preferred way to do it?
Yes, an easy way to tell if your branches on the server have been merged is:
git checkout origin/master (this detaches you but it's okay)
git branch -r --merged
git checkout mybranchname
Any of the merged branches which are yours can be removed with:
git push --delete origin branchname
e.g.
git push --delete origin stevef/mad-riscos-badgers
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: [Rpcemu] Patch to abort model for ARM6/7
In article
<CAJjzs2A4NGeEV+fq+OmwegVZz-W1nNj8HYL742dsRAF3WNXRLQ@mail.gmail.com>,
Matthew Howkins <rpcemu-list@howkins.me.uk> wrote:
> > The emulation of memory accesses (LDR[B]/STR[B]/LDM/STM) in RPCEmu
> > currently mostly follows the base restored model, ie. StrongARM
> > or ARM810 class.
>
> Thanks for this patch.
>
> I'm currently spending a lot of time developing test code, and intend to
> use it to both discover deficiencies in the emulation and to verify any
> patches.
>
> It will probably be a few days before I'm in a position to fully test and
> then commit your code; I'm keen to make sure that my testing keeps up with
> any improvements to the ARM core.
Hopefully you new test code will shake out what the subtle difference
between the interpreter and recompiler is now, I took a quick look at the
code generator but I'm not familiar enough with x86 assembler to see
anything obvious.
If you're writing tests, I'm sure someone somewhere will have done something
horrible like
STMIA r5!, {r4-r6}
strictly speaking the above stores an unknown value for r5 according to the
ARM ARM since it's not the first register in the list, but I'm sure it would
have been deterministic prior to ARMv5 it's just ARM aren't saying so!
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAJjzs2A4NGeEV+fq+OmwegVZz-W1nNj8HYL742dsRAF3WNXRLQ@mail.gmail.com>,
Matthew Howkins <rpcemu-list@howkins.me.uk> wrote:
> > The emulation of memory accesses (LDR[B]/STR[B]/LDM/STM) in RPCEmu
> > currently mostly follows the base restored model, ie. StrongARM
> > or ARM810 class.
>
> Thanks for this patch.
>
> I'm currently spending a lot of time developing test code, and intend to
> use it to both discover deficiencies in the emulation and to verify any
> patches.
>
> It will probably be a few days before I'm in a position to fully test and
> then commit your code; I'm keen to make sure that my testing keeps up with
> any improvements to the ARM core.
Hopefully you new test code will shake out what the subtle difference
between the interpreter and recompiler is now, I took a quick look at the
code generator but I'm not familiar enough with x86 assembler to see
anything obvious.
If you're writing tests, I'm sure someone somewhere will have done something
horrible like
STMIA r5!, {r4-r6}
strictly speaking the above stores an unknown value for r5 according to the
ARM ARM since it's not the first register in the list, but I'm sure it would
have been deterministic prior to ARMv5 it's just ARM aren't saying so!
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 29 January 2014
Re: [Rpcemu] Patch to abort model for ARM6/7
The emulation of memory accesses (LDR[B]/STR[B]/LDM/STM) in RPCEmu currently
mostly follows the base restored model, ie. StrongARM or ARM810 class.
Thanks for this patch.
I'm currently spending a lot of time developing test code, and intend to use it to both discover deficiencies in the emulation and to verify any patches.
I'm currently spending a lot of time developing test code, and intend to use it to both discover deficiencies in the emulation and to verify any patches.
It will probably be a few days before I'm in a position to fully test and then commit your code; I'm keen to make sure that my testing keeps up with any improvements to the ARM core.
Matthew
[gccsdk] First lot of component packages uploaded using trunk compiler
I've now uploaded the first batch of packages that use the new packaging
Components fields and have been built by the trunk version of the
compiler.
Due to problems of compiling SDL and libncurses5, the first pass through
didn't update as many packages as it could have. But I intend to
investigate the problems on these two libraries which will add allow a
lot more packages to be updated.
I had 3 packages that compiled, but failed my simple testing on
RISC OS 4 on RPCEmu so I didn't upload them. They were
ctorrent, iperf and p7zip. If anyone who knows the programs
and could investigate why they crash when running it would be
helpful.
Regards,
Alan
Tuesday, 28 January 2014
Re: [Rpcemu] Crash
I thinked of this one. But I have two objections:
1/ I made a benchmark under high load without problems.
2/ CPU load is very high in interpreter mode too.
And the problem is that interpreter mode works absolutely perfectly. No crash at all.
So perhaps it's a driver issue, but why only recompiler mode is affected?
See ya later (sic.), David
2014-01-28 Ralph Corderoy <ralph@inputplus.co.uk>
Hi David,
Could it be the high CPU load of rpcemu is causing the machine problems
Peter Howkins wrote:
> 3) I've used an Atom machine as a dev system for years and never
> encountered this issue.
> 4) Other users have reported success with Atom systems too.
rather than rpcemu's code?
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Mobile : 06 76 67 91 60
Journaliste Silicon.fr & Développeur
Journaliste Silicon.fr & Développeur
Re: [Rpcemu] Crash
Hi David,
Peter Howkins wrote:
> 3) I've used an Atom machine as a dev system for years and never
> encountered this issue.
> 4) Other users have reported success with Atom systems too.
Could it be the high CPU load of rpcemu is causing the machine problems
rather than rpcemu's code?
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Peter Howkins wrote:
> 3) I've used an Atom machine as a dev system for years and never
> encountered this issue.
> 4) Other users have reported success with Atom systems too.
Could it be the high CPU load of rpcemu is causing the machine problems
rather than rpcemu's code?
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Crash
On Mon, Jan 27, 2014 at 10:57:01PM +0100, David Feugey wrote:
> 2014-01-27 Peter Howkins <[1]rpcemu.howkins@marutan.net>
>
> My recomendation is to update your graphics drivers, and to check your
> windows event logs for clues. This seems like a host machine
> hardware/driver issue.
>
> Graphic drivers: I have the latest one (old too). No issue with other
> software.
> Event log: nothing. Crash is to sudden.
> Anyway, graphic problems can't explain slow performance in recompiler
> mode.
> Note that there is no crash in interpreter mode.
> Recompiler works at 30 MIPS and more just a few seconds, then slow down to
> 2-3 MIPS, and a few seconds or minutes later, everything crash... even if
> I leave the application before problems.
I can think of no issue that could cause a crash in this manner other than
a hardware fault or faulty hardware driver *particulaly* if RPCEmu is not
even running at the time of the crash.
There are timing issues between recompiler and interpretter that I've seen
affect display code, in particualar entering full-screen mode crashes
RPCEmu (not the host system) in recompiler mode on accasion, for a reason
not yet tracked down (running with gdb alters the timing enough that it's
not shown).
RPCEmu, and the Allegro game library, call legitimate win32 public API in
non-priviledged modes. Taking out the kernel to the point of not even
getting a blue-screen is probably not possible without the assistance of
buggy kernel mode (driver) level stuff.
> As if the processor didn't manage to execute the generated instructions,
> and just finished to stop after too many errors. Under VPC7, the problem
> was the same, with an illegal instruction error (sometimes) and some
> massive slow down (everytime).
The reason I've been ignoring this one is that it's not the issue here.
1) Windows programs executing unknown instructions fail in a different
manner, the issue would caught by the kernel and the individiual
program stopped with windows error box.
2) There is no x86 instruction in the code that would cause an issue, I
think we're using nothing more complex than 386 level of instructions.
3) I've used an Atom machine as a dev system for years and never
encountered this issue.
4) Other users have reported success with Atom systems too.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> 2014-01-27 Peter Howkins <[1]rpcemu.howkins@marutan.net>
>
> My recomendation is to update your graphics drivers, and to check your
> windows event logs for clues. This seems like a host machine
> hardware/driver issue.
>
> Graphic drivers: I have the latest one (old too). No issue with other
> software.
> Event log: nothing. Crash is to sudden.
> Anyway, graphic problems can't explain slow performance in recompiler
> mode.
> Note that there is no crash in interpreter mode.
> Recompiler works at 30 MIPS and more just a few seconds, then slow down to
> 2-3 MIPS, and a few seconds or minutes later, everything crash... even if
> I leave the application before problems.
I can think of no issue that could cause a crash in this manner other than
a hardware fault or faulty hardware driver *particulaly* if RPCEmu is not
even running at the time of the crash.
There are timing issues between recompiler and interpretter that I've seen
affect display code, in particualar entering full-screen mode crashes
RPCEmu (not the host system) in recompiler mode on accasion, for a reason
not yet tracked down (running with gdb alters the timing enough that it's
not shown).
RPCEmu, and the Allegro game library, call legitimate win32 public API in
non-priviledged modes. Taking out the kernel to the point of not even
getting a blue-screen is probably not possible without the assistance of
buggy kernel mode (driver) level stuff.
> As if the processor didn't manage to execute the generated instructions,
> and just finished to stop after too many errors. Under VPC7, the problem
> was the same, with an illegal instruction error (sometimes) and some
> massive slow down (everytime).
The reason I've been ignoring this one is that it's not the issue here.
1) Windows programs executing unknown instructions fail in a different
manner, the issue would caught by the kernel and the individiual
program stopped with windows error box.
2) There is no x86 instruction in the code that would cause an issue, I
think we're using nothing more complex than 386 level of instructions.
3) I've used an Atom machine as a dev system for years and never
encountered this issue.
4) Other users have reported success with Atom systems too.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 27 January 2014
[Rpcemu] Patch to abort model for ARM6/7
Hi,
The emulation of memory accesses (LDR[B]/STR[B]/LDM/STM) in RPCEmu currently
mostly follows the base restored model, ie. StrongARM or ARM810 class.
This means that RISC OS 5 hangs when entering the desktop as it has detected
that the base restored model is in use and activated lazy task swapping,
when in fact the processor is an ARM610 (or 710 or 7500 or 7500FE).
Older versions of RISC OS get away with this as they have a fixed table
mapping from the processor type from CP15 to know which ones can do lazy
task swapping, rather than auto detecting it.
The following patch fixes the interpreter to emulate "base updated" and
"base restored" abort models (there looked to be partial support for this
with the stm_writeback_at_end flag already) and so allow RISC OS 5 to boot
properly in something other than StrongARM mode.
The patch also does the same for the dynamic recompiler, though the
emulation still isn't quite accurate enough in non-StrongARM mode. Some more
investigation would be needed to work out what's different between the
interpreter and recompiler, since they should behave the same.
It uses the following truth table
Abort model? Was there an abort? Base register
Base updated No Updated
Base restored No Updated
Base updated Yes Updated
Base restored Yes No
The patch is quite long but it's all a copy-and-paste job of the above
principle,
Sprow.
diff -r e0959b8f016a src/ArmDynarecOps.h
--- a/src/ArmDynarecOps.h Sun Jan 26 09:00:47 2014 +0000
+++ b/src/ArmDynarecOps.h Sun Jan 26 23:07:30 2014 +0000
@@ -941,7 +941,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Writeback */
@@ -956,7 +956,7 @@
addr += addr2;
arm.reg[RN] = addr;
- return 0;
+ return (armirq & 0x40);
}
static int opLDRT(uint32_t opcode)
@@ -973,7 +973,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Rotate if load is unaligned */
@@ -994,7 +994,7 @@
/* Write Rd */
LOADREG(RD, templ2);
- return 0;
+ return (armirq & 0x40);
}
static int opSTRBT(uint32_t opcode)
@@ -1011,7 +1011,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Writeback */
@@ -1026,7 +1026,7 @@
addr += addr2;
arm.reg[RN] = addr;
- return 0;
+ return (armirq & 0x40);
}
static int opLDRBT(uint32_t opcode)
@@ -1043,7 +1043,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Writeback */
@@ -1061,7 +1061,7 @@
/* Write Rd */
LOADREG(RD, templ2);
- return 0;
+ return (armirq & 0x40);
}
static int opSTR(uint32_t opcode)
@@ -1098,7 +1098,7 @@
writememl(addr & ~3, value);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
if (!(opcode & 0x1000000)) {
@@ -1110,7 +1110,7 @@
arm.reg[RN] = addr;
}
- return 0;
+ return (armirq & 0x40);
}
static int opLDR(uint32_t opcode)
@@ -1144,7 +1144,7 @@
templ = readmeml(addr & ~3);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Rotate if load is unaligned */
@@ -1162,7 +1162,7 @@
/* Write Rd */
LOADREG(RD, templ);
- return 0;
+ return (armirq & 0x40);
}
static int opSTRB(uint32_t opcode)
@@ -1195,7 +1195,7 @@
writememb(addr, arm.reg[RD]);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
if (!(opcode & 0x1000000)) {
@@ -1207,7 +1207,7 @@
arm.reg[RN] = addr;
}
- return 0;
+ return (armirq & 0x40);
}
static int opLDRB(uint32_t opcode)
@@ -1241,7 +1241,7 @@
templ = readmemb(addr);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
if (!(opcode & 0x1000000)) {
@@ -1256,7 +1256,7 @@
/* Write Rd */
LOADREG(RD, templ);
- return 0;
+ return (armirq & 0x40);
}
static int opSTMD(uint32_t opcode)
diff -r e0959b8f016a src/arm.c
--- a/src/arm.c Sun Jan 26 09:00:47 2014 +0000
+++ b/src/arm.c Sun Jan 26 23:07:30 2014 +0000
@@ -291,10 +291,10 @@
pccache=0xFFFFFFFF;
if (cpu_model == CPUModel_SA110 || cpu_model == CPUModel_ARM810) {
r15diff = 0;
- arm.stm_writeback_at_end = 1;
+ arm.base = AbortModel_BaseRestored;
} else {
r15diff = 4;
- arm.stm_writeback_at_end = 0;
+ arm.base = AbortModel_BaseUpdated;
}
}
@@ -1373,7 +1373,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Writeback */
@@ -1402,7 +1402,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Rotate if load is unaligned */
@@ -1437,7 +1437,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Writeback */
@@ -1466,7 +1466,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Writeback */
@@ -1527,7 +1527,7 @@
writememl(addr & ~3, templ);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
if (!(opcode & 0x1000000)) {
@@ -1578,7 +1578,7 @@
templ = readmeml(addr & ~3);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Rotate if load is unaligned */
@@ -1635,7 +1635,7 @@
writememb(addr, arm.reg[RD]);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
if (!(opcode & 0x1000000)) {
@@ -1686,7 +1686,7 @@
templ = readmemb(addr);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
if (!(opcode & 0x1000000)) {
diff -r e0959b8f016a src/arm.h
--- a/src/arm.h Sun Jan 26 09:00:47 2014 +0000
+++ b/src/arm.h Sun Jan 26 23:07:30 2014 +0000
@@ -3,9 +3,14 @@
#include "rpcemu.h"
+typedef enum {
+ AbortModel_BaseRestored,
+ AbortModel_BaseUpdated
+} AbortModel;
+
typedef struct {
uint32_t reg[18];
- uint8_t stm_writeback_at_end;
+ AbortModel base;
} ARMState;
typedef void (*OpFn)(uint32_t opcode);
diff -r e0959b8f016a src/arm_common.h
--- a/src/arm_common.h Sun Jan 26 09:00:47 2014 +0000
+++ b/src/arm_common.h Sun Jan 26 23:07:30 2014 +0000
@@ -342,11 +342,9 @@
static inline void
arm_store_multiple(uint32_t opcode, uint32_t address, uint32_t writeback)
{
- uint32_t orig_base, addr, mask, exception_flags;
+ uint32_t addr, mask, exception_flags;
int c;
- orig_base = arm.reg[RN];
-
addr = address & ~3;
/* Store first register */
@@ -365,7 +363,8 @@
c++;
/* Perform Writeback (if requested) at end of 2nd cycle */
- if (!arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
+ if ((arm.base == AbortModel_BaseUpdated) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
arm.reg[RN] = writeback;
}
@@ -385,16 +384,15 @@
exception_flags |= armirq;
}
- /* Perform Writeback (if requested) at end of instruction (SA110) */
- if (arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
- arm.reg[RN] = writeback;
+ /* If a Data Abort occurred, update the Data Abort flag */
+ if (exception_flags & 0x40) {
+ armirq |= 0x40;
}
- /* If a Data Abort occurred, update the Data Abort flag and restore
- the Base Register to the value it had before the instruction */
- if (exception_flags & 0x40) {
- armirq |= 0x40;
- arm.reg[RN] = orig_base;
+ /* Perform Writeback (if requested) at end of instruction */
+ if ((arm.base == AbortModel_BaseRestored) && !(armirq & 0x40) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
+ arm.reg[RN] = writeback;
}
}
@@ -412,11 +410,9 @@
static inline void
arm_store_multiple_s(uint32_t opcode, uint32_t address, uint32_t writeback)
{
- uint32_t orig_base, addr, mask, exception_flags;
+ uint32_t addr, mask, exception_flags;
int c;
- orig_base = arm.reg[RN];
-
addr = address & ~3;
/* Store first register */
@@ -435,7 +431,8 @@
c++;
/* Perform Writeback (if requested) at end of 2nd cycle */
- if (!arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
+ if ((arm.base == AbortModel_BaseUpdated) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
arm.reg[RN] = writeback;
}
@@ -455,16 +452,15 @@
exception_flags |= armirq;
}
- /* Perform Writeback (if requested) at end of instruction (SA110) */
- if (arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
- arm.reg[RN] = writeback;
+ /* If a Data Abort occurred, update the Data Abort flag */
+ if (exception_flags & 0x40) {
+ armirq |= 0x40;
}
- /* If a Data Abort occurred, update the Data Abort flag and restore
- the Base Register to the value it had before the instruction */
- if (exception_flags & 0x40) {
- armirq |= 0x40;
- arm.reg[RN] = orig_base;
+ /* Perform Writeback (if requested) at end of instruction */
+ if ((arm.base == AbortModel_BaseRestored) && !(armirq & 0x40) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
+ arm.reg[RN] = writeback;
}
}
@@ -523,7 +519,9 @@
/* A Data Abort occurred, restore the Base Register to the value it
had before the instruction */
data_abort:
- arm.reg[RN] = orig_base;
+ if (arm.base == AbortModel_BaseRestored) {
+ arm.reg[RN] = orig_base;
+ }
}
/**
@@ -599,7 +597,9 @@
/* A Data Abort occurred, restore the Base Register to the value it
had before the instruction */
data_abort:
- arm.reg[RN] = orig_base;
+ if (arm.base == AbortModel_BaseRestored) {
+ arm.reg[RN] = orig_base;
+ }
}
The emulation of memory accesses (LDR[B]/STR[B]/LDM/STM) in RPCEmu currently
mostly follows the base restored model, ie. StrongARM or ARM810 class.
This means that RISC OS 5 hangs when entering the desktop as it has detected
that the base restored model is in use and activated lazy task swapping,
when in fact the processor is an ARM610 (or 710 or 7500 or 7500FE).
Older versions of RISC OS get away with this as they have a fixed table
mapping from the processor type from CP15 to know which ones can do lazy
task swapping, rather than auto detecting it.
The following patch fixes the interpreter to emulate "base updated" and
"base restored" abort models (there looked to be partial support for this
with the stm_writeback_at_end flag already) and so allow RISC OS 5 to boot
properly in something other than StrongARM mode.
The patch also does the same for the dynamic recompiler, though the
emulation still isn't quite accurate enough in non-StrongARM mode. Some more
investigation would be needed to work out what's different between the
interpreter and recompiler, since they should behave the same.
It uses the following truth table
Abort model? Was there an abort? Base register
Base updated No Updated
Base restored No Updated
Base updated Yes Updated
Base restored Yes No
The patch is quite long but it's all a copy-and-paste job of the above
principle,
Sprow.
diff -r e0959b8f016a src/ArmDynarecOps.h
--- a/src/ArmDynarecOps.h Sun Jan 26 09:00:47 2014 +0000
+++ b/src/ArmDynarecOps.h Sun Jan 26 23:07:30 2014 +0000
@@ -941,7 +941,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Writeback */
@@ -956,7 +956,7 @@
addr += addr2;
arm.reg[RN] = addr;
- return 0;
+ return (armirq & 0x40);
}
static int opLDRT(uint32_t opcode)
@@ -973,7 +973,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Rotate if load is unaligned */
@@ -994,7 +994,7 @@
/* Write Rd */
LOADREG(RD, templ2);
- return 0;
+ return (armirq & 0x40);
}
static int opSTRBT(uint32_t opcode)
@@ -1011,7 +1011,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Writeback */
@@ -1026,7 +1026,7 @@
addr += addr2;
arm.reg[RN] = addr;
- return 0;
+ return (armirq & 0x40);
}
static int opLDRBT(uint32_t opcode)
@@ -1043,7 +1043,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Writeback */
@@ -1061,7 +1061,7 @@
/* Write Rd */
LOADREG(RD, templ2);
- return 0;
+ return (armirq & 0x40);
}
static int opSTR(uint32_t opcode)
@@ -1098,7 +1098,7 @@
writememl(addr & ~3, value);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
if (!(opcode & 0x1000000)) {
@@ -1110,7 +1110,7 @@
arm.reg[RN] = addr;
}
- return 0;
+ return (armirq & 0x40);
}
static int opLDR(uint32_t opcode)
@@ -1144,7 +1144,7 @@
templ = readmeml(addr & ~3);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
/* Rotate if load is unaligned */
@@ -1162,7 +1162,7 @@
/* Write Rd */
LOADREG(RD, templ);
- return 0;
+ return (armirq & 0x40);
}
static int opSTRB(uint32_t opcode)
@@ -1195,7 +1195,7 @@
writememb(addr, arm.reg[RD]);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
if (!(opcode & 0x1000000)) {
@@ -1207,7 +1207,7 @@
arm.reg[RN] = addr;
}
- return 0;
+ return (armirq & 0x40);
}
static int opLDRB(uint32_t opcode)
@@ -1241,7 +1241,7 @@
templ = readmemb(addr);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
return 1;
if (!(opcode & 0x1000000)) {
@@ -1256,7 +1256,7 @@
/* Write Rd */
LOADREG(RD, templ);
- return 0;
+ return (armirq & 0x40);
}
static int opSTMD(uint32_t opcode)
diff -r e0959b8f016a src/arm.c
--- a/src/arm.c Sun Jan 26 09:00:47 2014 +0000
+++ b/src/arm.c Sun Jan 26 23:07:30 2014 +0000
@@ -291,10 +291,10 @@
pccache=0xFFFFFFFF;
if (cpu_model == CPUModel_SA110 || cpu_model == CPUModel_ARM810) {
r15diff = 0;
- arm.stm_writeback_at_end = 1;
+ arm.base = AbortModel_BaseRestored;
} else {
r15diff = 4;
- arm.stm_writeback_at_end = 0;
+ arm.base = AbortModel_BaseUpdated;
}
}
@@ -1373,7 +1373,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Writeback */
@@ -1402,7 +1402,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Rotate if load is unaligned */
@@ -1437,7 +1437,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Writeback */
@@ -1466,7 +1466,7 @@
memmode = templ;
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Writeback */
@@ -1527,7 +1527,7 @@
writememl(addr & ~3, templ);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
if (!(opcode & 0x1000000)) {
@@ -1578,7 +1578,7 @@
templ = readmeml(addr & ~3);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
/* Rotate if load is unaligned */
@@ -1635,7 +1635,7 @@
writememb(addr, arm.reg[RD]);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
if (!(opcode & 0x1000000)) {
@@ -1686,7 +1686,7 @@
templ = readmemb(addr);
/* Check for Abort */
- if (armirq & 0x40)
+ if ((arm.base == AbortModel_BaseRestored) && (armirq & 0x40))
break;
if (!(opcode & 0x1000000)) {
diff -r e0959b8f016a src/arm.h
--- a/src/arm.h Sun Jan 26 09:00:47 2014 +0000
+++ b/src/arm.h Sun Jan 26 23:07:30 2014 +0000
@@ -3,9 +3,14 @@
#include "rpcemu.h"
+typedef enum {
+ AbortModel_BaseRestored,
+ AbortModel_BaseUpdated
+} AbortModel;
+
typedef struct {
uint32_t reg[18];
- uint8_t stm_writeback_at_end;
+ AbortModel base;
} ARMState;
typedef void (*OpFn)(uint32_t opcode);
diff -r e0959b8f016a src/arm_common.h
--- a/src/arm_common.h Sun Jan 26 09:00:47 2014 +0000
+++ b/src/arm_common.h Sun Jan 26 23:07:30 2014 +0000
@@ -342,11 +342,9 @@
static inline void
arm_store_multiple(uint32_t opcode, uint32_t address, uint32_t writeback)
{
- uint32_t orig_base, addr, mask, exception_flags;
+ uint32_t addr, mask, exception_flags;
int c;
- orig_base = arm.reg[RN];
-
addr = address & ~3;
/* Store first register */
@@ -365,7 +363,8 @@
c++;
/* Perform Writeback (if requested) at end of 2nd cycle */
- if (!arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
+ if ((arm.base == AbortModel_BaseUpdated) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
arm.reg[RN] = writeback;
}
@@ -385,16 +384,15 @@
exception_flags |= armirq;
}
- /* Perform Writeback (if requested) at end of instruction (SA110) */
- if (arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
- arm.reg[RN] = writeback;
+ /* If a Data Abort occurred, update the Data Abort flag */
+ if (exception_flags & 0x40) {
+ armirq |= 0x40;
}
- /* If a Data Abort occurred, update the Data Abort flag and restore
- the Base Register to the value it had before the instruction */
- if (exception_flags & 0x40) {
- armirq |= 0x40;
- arm.reg[RN] = orig_base;
+ /* Perform Writeback (if requested) at end of instruction */
+ if ((arm.base == AbortModel_BaseRestored) && !(armirq & 0x40) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
+ arm.reg[RN] = writeback;
}
}
@@ -412,11 +410,9 @@
static inline void
arm_store_multiple_s(uint32_t opcode, uint32_t address, uint32_t writeback)
{
- uint32_t orig_base, addr, mask, exception_flags;
+ uint32_t addr, mask, exception_flags;
int c;
- orig_base = arm.reg[RN];
-
addr = address & ~3;
/* Store first register */
@@ -435,7 +431,8 @@
c++;
/* Perform Writeback (if requested) at end of 2nd cycle */
- if (!arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
+ if ((arm.base == AbortModel_BaseUpdated) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
arm.reg[RN] = writeback;
}
@@ -455,16 +452,15 @@
exception_flags |= armirq;
}
- /* Perform Writeback (if requested) at end of instruction (SA110) */
- if (arm.stm_writeback_at_end && (opcode & (1 << 21)) && (RN != 15)) {
- arm.reg[RN] = writeback;
+ /* If a Data Abort occurred, update the Data Abort flag */
+ if (exception_flags & 0x40) {
+ armirq |= 0x40;
}
- /* If a Data Abort occurred, update the Data Abort flag and restore
- the Base Register to the value it had before the instruction */
- if (exception_flags & 0x40) {
- armirq |= 0x40;
- arm.reg[RN] = orig_base;
+ /* Perform Writeback (if requested) at end of instruction */
+ if ((arm.base == AbortModel_BaseRestored) && !(armirq & 0x40) &&
+ (opcode & (1 << 21)) && (RN != 15)) {
+ arm.reg[RN] = writeback;
}
}
@@ -523,7 +519,9 @@
/* A Data Abort occurred, restore the Base Register to the value it
had before the instruction */
data_abort:
- arm.reg[RN] = orig_base;
+ if (arm.base == AbortModel_BaseRestored) {
+ arm.reg[RN] = orig_base;
+ }
}
/**
@@ -599,7 +597,9 @@
/* A Data Abort occurred, restore the Base Register to the value it
had before the instruction */
data_abort:
- arm.reg[RN] = orig_base;
+ if (arm.base == AbortModel_BaseRestored) {
+ arm.reg[RN] = orig_base;
+ }
}
Re: [Rpcemu] Crash
2014-01-27 Peter Howkins <rpcemu.howkins@marutan.net>
My recomendation is to update your graphics drivers, and to check yourwindows event logs for clues. This seems like a host machine
hardware/driver issue.
Graphic drivers: I have the latest one (old too). No issue with other software.
Event log: nothing. Crash is to sudden.
Anyway, graphic problems can't explain slow performance in recompiler mode.
Note that there is no crash in interpreter mode.
Recompiler works at 30 MIPS and more just a few seconds, then slow down to 2-3 MIPS, and a few seconds or minutes later, everything crash... even if I leave the application before problems.
As if the processor didn't manage to execute the generated instructions, and just finished to stop after too many errors. Under VPC7, the problem was the same, with an illegal instruction error (sometimes) and some massive slow down (everytime).
> I'm not sure if the processor is a N230 (32 bits only), or a 230 (32/64You're running 32-bit windows.
> bits) but bios mode is 32 bits.
Yes, but here the Atom is also stuck to 32 bits instructions because of the Bios.
Classic limit of the first Atom: the Bios choose the available instruction set. You can't change it later.
I'm not very lucky with my computers :(
--
Mobile : 06 76 67 91 60
Journaliste Silicon.fr & Développeur
Journaliste Silicon.fr & Développeur
Re: [Rpcemu] Crash
On Mon, Jan 27, 2014 at 09:58:33PM +0100, David Feugey wrote:
> I have no log for recompiler. Crash is so sudden that files are not
> written on disc (no blue screen, just a reboot).
> It's the same configuration, appart from this detail.
> Nota: I have a dual screen config, but acceleration seems only to be
> available on screen 1.
My recomendation is to update your graphics drivers, and to check your
windows event logs for clues. This seems like a host machine
hardware/driver issue.
> I'm not sure if the processor is a N230 (32 bits only), or a 230 (32/64
> bits) but bios mode is 32 bits.
You're running 32-bit windows.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I have no log for recompiler. Crash is so sudden that files are not
> written on disc (no blue screen, just a reboot).
> It's the same configuration, appart from this detail.
> Nota: I have a dual screen config, but acceleration seems only to be
> available on screen 1.
My recomendation is to update your graphics drivers, and to check your
windows event logs for clues. This seems like a host machine
hardware/driver issue.
> I'm not sure if the processor is a N230 (32 bits only), or a 230 (32/64
> bits) but bios mode is 32 bits.
You're running 32-bit windows.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Crash
RPCEmu 0.8.11 [INTERPRETER NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.6.2
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 5
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x300
OS: ServicePackMajor = 3
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 0
OS: SystemMetricsServerR2 = 0
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
Working Directory: C:\Documents and Settings\Utilisateur\Mes documents\RPCEmu
loadconfig: model = "RPCSA"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "off"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "0"
loadconfig: cdrom_enabled = "1"
loadconfig: refresh_rate = "20"
loadconfig: stretch_mode = "1"
loadconfig: sound_enabled = "0"
loadconfig: vram_size = "2"
loadconfig: mem_size = "32"
loadconfig: ipaddress = "172.31.0.1"
loadconfig: cpu_idle = "0"
romload: Loaded 'riscos' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
RPCEmu: Machine reset complete
HostFS: Registration request version 1 accepted
I have no log for recompiler. Crash is so sudden that files are not written on disc (no blue screen, just a reboot).
It's the same configuration, appart from this detail.
Nota: I have a dual screen config, but acceleration seems only to be available on screen 1.
I'm not sure if the processor is a N230 (32 bits only), or a 230 (32/64 bits) but bios mode is 32 bits.
Speed is around 7-13 MIPS in interpreter mode. 2-7 MIPS in recompiler mode, before crash (a few seconds <-> a few minutes). Crash can happens after I leave the application. But it occurs every time.
No crash at all in interpreter mode. Just problems with mouse (follow host mode).
2014-01-27 Peter Howkins <rpcemu.howkins@marutan.net>
On Mon, Jan 27, 2014 at 08:15:37PM +0100, David Feugey wrote:Can you post your rpclog.txt file
>
> RPCEmu 0.8.11
> RISC OS 5.20
> Windows XP SP3 on Intel Atom N230 (first generation)
On XP it's same directory as the binary. [1]
Peter
[1] On Vista/7 it's same directory as the binary if not installed in
Program Files, else it's in C:/Users/<username>/AppData/Local/VirtualStore/Program Files (x86)/RPCEmu
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Mobile : 06 76 67 91 60
Journaliste Silicon.fr & Développeur
Journaliste Silicon.fr & Développeur
Re: [Rpcemu] Crash
On Mon, Jan 27, 2014 at 08:15:37PM +0100, David Feugey wrote:
>
> RPCEmu 0.8.11
> RISC OS 5.20
> Windows XP SP3 on Intel Atom N230 (first generation)
Can you post your rpclog.txt file
On XP it's same directory as the binary. [1]
Peter
[1] On Vista/7 it's same directory as the binary if not installed in
Program Files, else it's in C:/Users/<username>/AppData/Local/VirtualStore/Program Files (x86)/RPCEmu
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> RPCEmu 0.8.11
> RISC OS 5.20
> Windows XP SP3 on Intel Atom N230 (first generation)
Can you post your rpclog.txt file
On XP it's same directory as the binary. [1]
Peter
[1] On Vista/7 it's same directory as the binary if not installed in
Program Files, else it's in C:/Users/<username>/AppData/Local/VirtualStore/Program Files (x86)/RPCEmu
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Crash
Amen to that! But it isn't just a question of configuring RPCEmu,
presumably: as I understand it, before RPCEmu can connect with the
outside world, Windows has to be configured to allow this (i.e,
setting up the network bridge). Automating /that/ procedure for all
the different flavours of Windows would be quite some task, I imagine.
Yep, but network could also works without a bridge.Of course, it's (a bit) less useful (no server applications).
(all code is under GPL :) )
--
Mobile : 06 76 67 91 60
Journaliste Silicon.fr & Développeur
Journaliste Silicon.fr & Développeur
Re: [Rpcemu] Crash
2014-01-27 George <george.greenfield@tiscali.co.uk>
Hi David
It would help if you could confirm the version of RPCEmu (0.8.11,
presumably?), RISC OS and Windows you are using. Here I'm using
0.8.11. Recompiler mode, running 5.20 on Windows7 64-bit, with no
speed problems (ROmark shows approx. 610,000 MIPs). The processor is a
3.4GHz i7 quad-core. I also have an 1.5GHz Atom-powered XP laptop on
which the same RPCEmu setup gives a ROmark score of 205,000 MIPs
(approx. 115% of a S/ARM RPC, which seems reasonable).
RISC OS 5.20
Windows XP SP3 on Intel Atom N230 (first generation)
I suspect the use of some non supported x86 instruction, as I did have the same problem under VirtualPC (illegal instruction + very slow recompiler... slower than the interpreter).
>Amen to that! But it isn't just a question of configuring RPCEmu,
> NB: I have different software projects, and for me, RPCEmu (or a modified
> version) would be a great way to sell them under Windows. For this kind of
> use, a simple network (no bridge, so no server applications), would be
> great (no configuration to do).
presumably: as I understand it, before RPCEmu can connect with the
outside world, Windows has to be configured to allow this (i.e,
setting up the network bridge). Automating /that/ procedure for all
the different flavours of Windows would be quite some task, I imagine.
Yep, but network could also works without a bridge.
Of course, it's (a bit) less useful (no server applications).
Best regard.
-- Mobile : 06 76 67 91 60
Journaliste Silicon.fr & Développeur
Journaliste Silicon.fr & Développeur
Re: [Rpcemu] Crash
In article <c3d4aed053.acld75@george/greenfield.tiscali.co.uk>,
George <george.greenfield@tiscali.co.uk> wrote:
[Snippy]
> Amen to that! But it isn't just a question of configuring RPCEmu,
> presumably: as I understand it, before RPCEmu can connect with the
> outside world, Windows has to be configured to allow this (i.e,
> setting up the network bridge). Automating /that/ procedure for all
> the different flavours of Windows would be quite some task, I imagine.
> George
I wonder why?
On another Win machine where I have VRPC-Adjust SA running, it didn't
require any (Rude word) with the networking to create a Bridge, it just
worked through the Windows networking as is.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
George <george.greenfield@tiscali.co.uk> wrote:
[Snippy]
> Amen to that! But it isn't just a question of configuring RPCEmu,
> presumably: as I understand it, before RPCEmu can connect with the
> outside world, Windows has to be configured to allow this (i.e,
> setting up the network bridge). Automating /that/ procedure for all
> the different flavours of Windows would be quite some task, I imagine.
> George
I wonder why?
On another Win machine where I have VRPC-Adjust SA running, it didn't
require any (Rude word) with the networking to create a Bridge, it just
worked through the Windows networking as is.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Crash
In message <CAC85+4KG=vvAxvoaoeLj8ZVfVXY274u1EP4TmA8RyhGL7Vg8eA@mail.g
mail.com>
David Feugey <dfeugey@ascinfo.fr> wrote:
> I tried to use the latest version of RPCEmu under Windows. I have strange
> results under ROS 5 : recompiler mode is very very slow, and my whole
> system crash in no time. Interpreter mode is OK, and faster. I suspect the
> use of some x86 instructions incompatible with an Intel Atom.
>
> Thanks.
Hi David
It would help if you could confirm the version of RPCEmu (0.8.11,
presumably?), RISC OS and Windows you are using. Here I'm using
0.8.11. Recompiler mode, running 5.20 on Windows7 64-bit, with no
speed problems (ROmark shows approx. 610,000 MIPs). The processor is a
3.4GHz i7 quad-core. I also have an 1.5GHz Atom-powered XP laptop on
which the same RPCEmu setup gives a ROmark score of 205,000 MIPs
(approx. 115% of a S/ARM RPC, which seems reasonable).
>
> NB: I have different software projects, and for me, RPCEmu (or a modified
> version) would be a great way to sell them under Windows. For this kind of
> use, a simple network (no bridge, so no server applications), would be
> great (no configuration to do).
Amen to that! But it isn't just a question of configuring RPCEmu,
presumably: as I understand it, before RPCEmu can connect with the
outside world, Windows has to be configured to allow this (i.e,
setting up the network bridge). Automating /that/ procedure for all
the different flavours of Windows would be quite some task, I imagine.
--
George
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
mail.com>
David Feugey <dfeugey@ascinfo.fr> wrote:
> I tried to use the latest version of RPCEmu under Windows. I have strange
> results under ROS 5 : recompiler mode is very very slow, and my whole
> system crash in no time. Interpreter mode is OK, and faster. I suspect the
> use of some x86 instructions incompatible with an Intel Atom.
>
> Thanks.
Hi David
It would help if you could confirm the version of RPCEmu (0.8.11,
presumably?), RISC OS and Windows you are using. Here I'm using
0.8.11. Recompiler mode, running 5.20 on Windows7 64-bit, with no
speed problems (ROmark shows approx. 610,000 MIPs). The processor is a
3.4GHz i7 quad-core. I also have an 1.5GHz Atom-powered XP laptop on
which the same RPCEmu setup gives a ROmark score of 205,000 MIPs
(approx. 115% of a S/ARM RPC, which seems reasonable).
>
> NB: I have different software projects, and for me, RPCEmu (or a modified
> version) would be a great way to sell them under Windows. For this kind of
> use, a simple network (no bridge, so no server applications), would be
> great (no configuration to do).
Amen to that! But it isn't just a question of configuring RPCEmu,
presumably: as I understand it, before RPCEmu can connect with the
outside world, Windows has to be configured to allow this (i.e,
setting up the network bridge). Automating /that/ procedure for all
the different flavours of Windows would be quite some task, I imagine.
--
George
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Another site crashing NS?
On 26 Jan, Brian Jordan <brian.jordan9@btinternet.com> wrote:
[Snip]
> Other details of my setup in my sig.
Sorry, I should have said: I'm using VARPC-Adjust on Windows7 64bit, though
whether that is elevant or not I don't know.
John
--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS
[Snip]
> Other details of my setup in my sig.
Sorry, I should have said: I'm using VARPC-Adjust on Windows7 64bit, though
whether that is elevant or not I don't know.
John
--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS
[Rpcemu] Crash
I tried to use the latest version of RPCEmu under Windows. I have strange results under ROS 5 : recompiler mode is very very slow, and my whole system crash in no time. Interpreter mode is OK, and faster. I suspect the use of some x86 instructions incompatible with an Intel Atom.
Thanks.
NB: I have different software projects, and for me, RPCEmu (or a modified version) would be a great way to sell them under Windows. For this kind of use, a simple network (no bridge, so no server applications), would be great (no configuration to do).
--
Mobile : 06 76 67 91 60
Journaliste Silicon.fr & Développeur
Journaliste Silicon.fr & Développeur
Sunday, 26 January 2014
Re: Another site crashing NS?
In article <53d02999c8mail@JohnWoodhouse.plus.com>,
<mail@JohnWoodhouse.plus.com> wrote:
> As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens
> with part of the page loaded, and then freezes completely. I am using
> it from VRPC, so need to quit RISC OS to get out of the situation.
> Does this site also cause a freeze using "real" RISC OS, or is it just
> VRPC?
Like you I use VA. I have just visited this site and find that it looks
like it does in Firefox on the other side and I have had no crashes at
all. Where there are Youtube videos in iframes NetSurf displays, as one
would expect, black rectangles. I didn't investigate site searches nor
the booking facilities where there may be problems. This is using NetSurf
3.1 (Dev CI #1659) with Javascript disabled. Other details of my setup in
my sig.
Brian
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
<mail@JohnWoodhouse.plus.com> wrote:
> As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens
> with part of the page loaded, and then freezes completely. I am using
> it from VRPC, so need to quit RISC OS to get out of the situation.
> Does this site also cause a freeze using "real" RISC OS, or is it just
> VRPC?
Like you I use VA. I have just visited this site and find that it looks
like it does in Firefox on the other side and I have had no crashes at
all. Where there are Youtube videos in iframes NetSurf displays, as one
would expect, black rectangles. I didn't investigate site searches nor
the booking facilities where there may be problems. This is using NetSurf
3.1 (Dev CI #1659) with Javascript disabled. Other details of my setup in
my sig.
Brian
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: Another site crashing NS?
On 26 Jan, mail@JohnWoodhouse.plus.com wrote:
> As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens
> with part of the page loaded, and then freezes completely. I am using it
> from VRPC, so need to quit RISC OS to get out of the situation. Does
> this site also cause a freeze using "real" RISC OS, or is it just VRPC?
Works OK on RO 5.20 on Iyonix, with #1659, after a fashion anyway.
The front page loads OK after a fairly long wait, but none of the
links on that page work - they just seem to point back at the main
page.
I guess I won't be booking a break there any time soon...
--
Brian Howlett
---------------------------------------------------------------
I came home from work the other day and found that someone had
stolen all my furniture, and replaced it with exact replicas...
> As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens
> with part of the page loaded, and then freezes completely. I am using it
> from VRPC, so need to quit RISC OS to get out of the situation. Does
> this site also cause a freeze using "real" RISC OS, or is it just VRPC?
Works OK on RO 5.20 on Iyonix, with #1659, after a fashion anyway.
The front page loads OK after a fairly long wait, but none of the
links on that page work - they just seem to point back at the main
page.
I guess I won't be booking a break there any time soon...
--
Brian Howlett
---------------------------------------------------------------
I came home from work the other day and found that someone had
stolen all my furniture, and replaced it with exact replicas...
Re: Another site crashing NS?
On 26 Jan 2014 <mail@JohnWoodhouse.plus.com> wrote:
> As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens with
> part of the page loaded, and then freezes completely. I am using it from
> VRPC, so need to quit RISC OS to get out of the situation.
> Does this site also cause a freeze using "real" RISC OS, or is it just
> VRPC?
Works OK here with #1659 and RISC OS 5.19 on an ARMini
With best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens with
> part of the page loaded, and then freezes completely. I am using it from
> VRPC, so need to quit RISC OS to get out of the situation.
> Does this site also cause a freeze using "real" RISC OS, or is it just
> VRPC?
Works OK here with #1659 and RISC OS 5.19 on an ARMini
With best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Another site crashing NS?
As soon as I open http://www.leroyalmeridien-dubai.com/ the page opens with
part of the page loaded, and then freezes completely. I am using it from
VRPC, so need to quit RISC OS to get out of the situation.
Does this site also cause a freeze using "real" RISC OS, or is it just
VRPC?
John
--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS
part of the page loaded, and then freezes completely. I am using it from
VRPC, so need to quit RISC OS to get out of the situation.
Does this site also cause a freeze using "real" RISC OS, or is it just
VRPC?
John
--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS
Re: Another site crashing NS?
In message <dd252bd053.Brian@bhowlett.plus.net>
Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:
> On 26 Jan, mail@JohnWoodhouse.plus.com wrote:
>
[snip]
>
> Works OK on RO 5.20 on Iyonix, with #1659, after a fashion anyway.
>
> The front page loads OK after a fairly long wait, but none of the
> links on that page work - they just seem to point back at the main
> page.
Same experience here (RPCEmu0.8.11 running RISC OS 5.20 on Win7-64 PC)
using #1659. Enabling/disabling JS made no perceptible difference.
--
George
Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:
> On 26 Jan, mail@JohnWoodhouse.plus.com wrote:
>
[snip]
>
> Works OK on RO 5.20 on Iyonix, with #1659, after a fashion anyway.
>
> The front page loads OK after a fairly long wait, but none of the
> links on that page work - they just seem to point back at the main
> page.
Same experience here (RPCEmu0.8.11 running RISC OS 5.20 on Win7-64 PC)
using #1659. Enabling/disabling JS made no perceptible difference.
--
George
Long URLs on RISC OS
I've made some changes to the RISC OS front-end to partly address tickets
#390 and #2053: URL entry fields are now 2047 characters long (which appears
to be up there with the "best of the worst" of the mainstream browsers), and
changing this is now a case of altering a #define in riscos/gui.h and
recompiling. It's a compromise, as RISC OS's inability to change the size of
writable fields on the fly means that longer sizes waste more memory for
each window that's opened.
In addition, over-size URLs are handled more gracefully by browser toolbars:
the user gets a warning and the field is cleared and terminated safely.
Finally, I've fixed a bug where it was possible for toolbar URLs to miss the
conversion from UTF8 into local encoding under some (probably unlikely)
circumstances.
If anyone has any thoughts about the advisability (or otherwise) of these
changes, I'd welcome comments. Otherwise, they are in the branch
http://git.netsurf-browser.org/netsurf.git/log/?h=stevef/urlsize
if someone with access outside of riscos/ could merge them with the master?
There's a new message token in FatMessages, which could do with the non-en
forms translating into appropriate languages: xx.ro.LongURL is the warning
the user gets of URLs which are too long to display.
PS: Should I be deleting my branches once they're merged? If so, what's the
preferred way to do it?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
#390 and #2053: URL entry fields are now 2047 characters long (which appears
to be up there with the "best of the worst" of the mainstream browsers), and
changing this is now a case of altering a #define in riscos/gui.h and
recompiling. It's a compromise, as RISC OS's inability to change the size of
writable fields on the fly means that longer sizes waste more memory for
each window that's opened.
In addition, over-size URLs are handled more gracefully by browser toolbars:
the user gets a warning and the field is cleared and terminated safely.
Finally, I've fixed a bug where it was possible for toolbar URLs to miss the
conversion from UTF8 into local encoding under some (probably unlikely)
circumstances.
If anyone has any thoughts about the advisability (or otherwise) of these
changes, I'd welcome comments. Otherwise, they are in the branch
http://git.netsurf-browser.org/netsurf.git/log/?h=stevef/urlsize
if someone with access outside of riscos/ could merge them with the master?
There's a new message token in FatMessages, which could do with the non-en
forms translating into appropriate languages: xx.ro.LongURL is the warning
the user gets of URLs which are too long to display.
PS: Should I be deleting my branches once they're merged? If so, what's the
preferred way to do it?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: Paypal bank transfer
In article <04f80fd053.cris@cdewhurst2010.btinternet.com>, Cristopher
Dewhurst <cdewhurst2010@btinternet.com> wrote:
[Snip]
> I have only just found the start of this thread (sent to the spam
> folder by BT for some reason
If they're as useless as some other providers it will be because their
spam filters are simply rubbish. Bigger ISPs are far worse than small
ones at this.
Dewhurst <cdewhurst2010@btinternet.com> wrote:
[Snip]
> I have only just found the start of this thread (sent to the spam
> folder by BT for some reason
If they're as useless as some other providers it will be because their
spam filters are simply rubbish. Bigger ISPs are far worse than small
ones at this.
Re: Paypal bank transfer
Hello Harriet,
In message <31a32dcd53.harriet@blueyonder.co.uk>
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> I can't seem to withdraw money to my bank account from Paypal using
> Netsurf any more (it just gives a page saying there may have been an
> error) -- is it a temporary glitch or have they introduced a JavaScripty
> dependency since I last withdrew money in October?
I have only just found the start of this thread (sent to the spam
folder by BT for some reason so I've only just discovered it there so
sorry for the late reply.
Where do you find the options to transfer to/withdraw from bank
account? As far I know it's in a ribbon of options which doesn't
appear in Netsurf, though does in other browsers. Is there an
alternative way of getting at it?
thanks :)
--
Chris
In message <31a32dcd53.harriet@blueyonder.co.uk>
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> I can't seem to withdraw money to my bank account from Paypal using
> Netsurf any more (it just gives a page saying there may have been an
> error) -- is it a temporary glitch or have they introduced a JavaScripty
> dependency since I last withdrew money in October?
I have only just found the start of this thread (sent to the spam
folder by BT for some reason so I've only just discovered it there so
sorry for the late reply.
Where do you find the options to transfer to/withdraw from bank
account? As far I know it's in a ribbon of options which doesn't
appear in Netsurf, though does in other browsers. Is there an
alternative way of getting at it?
thanks :)
--
Chris
Saturday, 25 January 2014
Re: Iconv report
In article <20140125160616.GA20599@parsifal.org.uk>,
John-Mark Bell <jmb@netsurf-browser.org> wrote:
> This is generated by UnixLib. See
> http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010906.html
> for details.
And GCCSDK hasn't had a release since UnixLib was fixed[1], so we're still
using the old gccsdk 4.1.2 r2 release from October 2012.
[1]
http://www.riscos.info/websvn/revision.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Flocale%2Ficonv.c&rev=6017&peg=6017
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
John-Mark Bell <jmb@netsurf-browser.org> wrote:
> This is generated by UnixLib. See
> http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010906.html
> for details.
And GCCSDK hasn't had a release since UnixLib was fixed[1], so we're still
using the old gccsdk 4.1.2 r2 release from October 2012.
[1]
http://www.riscos.info/websvn/revision.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Flocale%2Ficonv.c&rev=6017&peg=6017
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
[gccsdk] [Bug 248] Decor package is missing Decor binary
http://www.riscos.info/bugzilla3/show_bug.cgi?id=248
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |John.Tytgat@aaug.net
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2014-01-25 08:18:33 PST ---
Should be fixed with r6548. New zip has been uploaded as well.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |John.Tytgat@aaug.net
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2014-01-25 08:18:33 PST ---
Should be fixed with r6548. New zip has been uploaded as well.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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: Iconv report
On Sat, Jan 25, 2014 at 03:23:42PM +0000, mail@JohnWoodhouse.plus.com wrote:
>
> Can someone explain why (at least in !Netsurf 3.0) the !Run file contains :
>
> RMEnsure Iconv 0.12 NetSurfRMLoad System:Modules.Iconv
> RMEnsure Iconv 0.12 Error NetSurf requires Iconv 0.12 or later. This can be
> downloaded from http://www.netsurf-browser.org/iconv/
>
> - and this is the version I have running according to !Verma,
NetSurf requires Iconv 0.12, which the Run file is ensuring.
> and yet, running !Reporter, I see that when running !Netsurf for the first
> time, there is a delay while this is repeated no fewer than 189 times: !
>
> [Appl/NetSurf] RMEnsure Iconv 0.04 RMload System:Modules.Iconv
> [Appl/NetSurf] RMEnsure Iconv 0.04 Error 16_10F iconv support requires the
> Iconv module 0.04 or newer
>
> on subsequent page loads it is repeated a mere 66 times.
>
> Apart from the question of why this is repeated so many times, so slowing
> up page loads, where is this coming from when Iconv 0.04 is called for in
> the !Run file, and in any case Iconv 0.12 is running?
This is generated by UnixLib. See
http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010906.html
for details.
John-Mark.
>
> Can someone explain why (at least in !Netsurf 3.0) the !Run file contains :
>
> RMEnsure Iconv 0.12 NetSurfRMLoad System:Modules.Iconv
> RMEnsure Iconv 0.12 Error NetSurf requires Iconv 0.12 or later. This can be
> downloaded from http://www.netsurf-browser.org/iconv/
>
> - and this is the version I have running according to !Verma,
NetSurf requires Iconv 0.12, which the Run file is ensuring.
> and yet, running !Reporter, I see that when running !Netsurf for the first
> time, there is a delay while this is repeated no fewer than 189 times: !
>
> [Appl/NetSurf] RMEnsure Iconv 0.04 RMload System:Modules.Iconv
> [Appl/NetSurf] RMEnsure Iconv 0.04 Error 16_10F iconv support requires the
> Iconv module 0.04 or newer
>
> on subsequent page loads it is repeated a mere 66 times.
>
> Apart from the question of why this is repeated so many times, so slowing
> up page loads, where is this coming from when Iconv 0.04 is called for in
> the !Run file, and in any case Iconv 0.12 is running?
This is generated by UnixLib. See
http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-September/010906.html
for details.
John-Mark.
Iconv report
Can someone explain why (at least in !Netsurf 3.0) the !Run file contains :
RMEnsure Iconv 0.12 NetSurfRMLoad System:Modules.Iconv
RMEnsure Iconv 0.12 Error NetSurf requires Iconv 0.12 or later. This can be
downloaded from http://www.netsurf-browser.org/iconv/
- and this is the version I have running according to !Verma,
and yet, running !Reporter, I see that when running !Netsurf for the first
time, there is a delay while this is repeated no fewer than 189 times: !
[Appl/NetSurf] RMEnsure Iconv 0.04 RMload System:Modules.Iconv
[Appl/NetSurf] RMEnsure Iconv 0.04 Error 16_10F iconv support requires the
Iconv module 0.04 or newer
on subsequent page loads it is repeated a mere 66 times.
Apart from the question of why this is repeated so many times, so slowing
up page loads, where is this coming from when Iconv 0.04 is called for in
the !Run file, and in any case Iconv 0.12 is running?
John
--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS
RMEnsure Iconv 0.12 NetSurfRMLoad System:Modules.Iconv
RMEnsure Iconv 0.12 Error NetSurf requires Iconv 0.12 or later. This can be
downloaded from http://www.netsurf-browser.org/iconv/
- and this is the version I have running according to !Verma,
and yet, running !Reporter, I see that when running !Netsurf for the first
time, there is a delay while this is repeated no fewer than 189 times: !
[Appl/NetSurf] RMEnsure Iconv 0.04 RMload System:Modules.Iconv
[Appl/NetSurf] RMEnsure Iconv 0.04 Error 16_10F iconv support requires the
Iconv module 0.04 or newer
on subsequent page loads it is repeated a mere 66 times.
Apart from the question of why this is repeated so many times, so slowing
up page loads, where is this coming from when Iconv 0.04 is called for in
the !Run file, and in any case Iconv 0.12 is running?
John
--
____
/__ __________________________
/____Mail from mail@JohnWoodhouse.plus.com
. . . using RISC OS
Friday, 24 January 2014
Re: [PATCH] Partial build fix for atari toolchains on debian unstable
On 24/01/2014 21:36, François Revol wrote:
> On 24/01/2014 21:13, François Revol wrote:
>> It still fails later trying to build pml though:
>> ...
>> make -f Makefile.32 libpml32.a
>> make[2]: Entering directory
>> `/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
>> m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
>> -o cadd.o cadd.c
>> cadd.c:69:19: fatal error: stdio.h: No such file or directory
>
> Actually this one seems to be because I have a local .profile which
> exports PREFIX=$ws/inst and somehow the headers get installed to
> /opt/netsurf but the binaries are configured and installed in inst/
> instead...
>
> The top Makefile uses conditional PREFIX ?= but on the other hand it
> seems recipes/patches/mintlib/configvars.p forces /opt/netsurf/...
>
> In any case it should either use the passed $PREFIX or override it
> completely...
>
> I'll drop my export and see if it works.
Indeed, unsetting PREFIX makes it work.
François.
> On 24/01/2014 21:13, François Revol wrote:
>> It still fails later trying to build pml though:
>> ...
>> make -f Makefile.32 libpml32.a
>> make[2]: Entering directory
>> `/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
>> m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
>> -o cadd.o cadd.c
>> cadd.c:69:19: fatal error: stdio.h: No such file or directory
>
> Actually this one seems to be because I have a local .profile which
> exports PREFIX=$ws/inst and somehow the headers get installed to
> /opt/netsurf but the binaries are configured and installed in inst/
> instead...
>
> The top Makefile uses conditional PREFIX ?= but on the other hand it
> seems recipes/patches/mintlib/configvars.p forces /opt/netsurf/...
>
> In any case it should either use the passed $PREFIX or override it
> completely...
>
> I'll drop my export and see if it works.
Indeed, unsetting PREFIX makes it work.
François.
Re: [PATCH] Partial build fix for atari toolchains on debian unstable
On 24/01/2014 21:13, François Revol wrote:
> It still fails later trying to build pml though:
> ...
> make -f Makefile.32 libpml32.a
> make[2]: Entering directory
> `/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
> m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
> -o cadd.o cadd.c
> cadd.c:69:19: fatal error: stdio.h: No such file or directory
Actually this one seems to be because I have a local .profile which
exports PREFIX=$ws/inst and somehow the headers get installed to
/opt/netsurf but the binaries are configured and installed in inst/
instead...
The top Makefile uses conditional PREFIX ?= but on the other hand it
seems recipes/patches/mintlib/configvars.p forces /opt/netsurf/...
In any case it should either use the passed $PREFIX or override it
completely...
I'll drop my export and see if it works.
François.
> It still fails later trying to build pml though:
> ...
> make -f Makefile.32 libpml32.a
> make[2]: Entering directory
> `/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
> m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
> -o cadd.o cadd.c
> cadd.c:69:19: fatal error: stdio.h: No such file or directory
Actually this one seems to be because I have a local .profile which
exports PREFIX=$ws/inst and somehow the headers get installed to
/opt/netsurf but the binaries are configured and installed in inst/
instead...
The top Makefile uses conditional PREFIX ?= but on the other hand it
seems recipes/patches/mintlib/configvars.p forces /opt/netsurf/...
In any case it should either use the passed $PREFIX or override it
completely...
I'll drop my export and see if it works.
François.
[PATCH] Partial build fix for atari toolchains on debian unstable
>From c0cc44e14c8bda133d7d0a7e537027c72a182000 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= <revol@free.fr>
Date: Fri, 24 Jan 2014 20:47:59 +0100
Subject: [PATCH] atari-mint: Force automake/aclocal to 1.11
Since we force autoconf and friends to 2.64, on Debian unstable
at leastsome aclocal macros complain that they require at least 2.65.
Also add automake1.11 to the list of required debian packages.
---
README | 2 +-
m5475-atari-mint/Makefile | 10 ++++++----
m68k-atari-mint/Makefile | 10 ++++++----
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/README b/README
index 84c872c..a791bdc 100644
--- a/README
+++ b/README
@@ -5,7 +5,7 @@ Pre-requisites for Debian systems
$ apt-get install build-essential autoconf automake autogen flex bison
$ apt-get install libtool texinfo help2man subversion cvs git
- $ apt-get install lhasa unzip autoconf2.64
+ $ apt-get install lhasa unzip autoconf2.64 automake1.11
On multiarch-aware systems:
diff --git a/m5475-atari-mint/Makefile b/m5475-atari-mint/Makefile
index 43e6c56..e236cf7 100644
--- a/m5475-atari-mint/Makefile
+++ b/m5475-atari-mint/Makefile
@@ -49,6 +49,8 @@ GCC_AUTOCONF := autoconf2.64
GCC_AUTOHEADER := autoheader2.64
GCC_AUTORECONF := autoreconf2.64
GCC_AUTOM4TE := autom4te2.64
+GCC_AUTOMAKE := automake-1.11
+GCC_ACLOCAL := aclocal-1.11
TOP := $(CURDIR)
RECIPES := $(TOP)/recipes
@@ -131,7 +133,7 @@ $(BUILDSTEPS)/mintlib.d: $(BUILDSTEPS)/bootstrap-compiler.d $(SOURCESDIR)/$(UPST
# Rules to build and install the bootstrap compiler
###
-GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) PATH="$(PREFIX)/bin:$(PATH)"
+GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) ACLOCAL=$(GCC_ACLOCAL) AUTOMAKE=$(GCC_AUTOMAKE) PATH="$(PREFIX)/bin:$(PATH)"
$(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/binutils.d $(BUILDSTEPS)/mintbin.d
cd $(BUILDDIR) && $(GCC_ENV_PARAMS) $(GCC_SRCDIR)/configure \
@@ -154,9 +156,9 @@ $(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/b
$(BUILDSTEPS)/srcdir-step3.d: $(BUILDSTEPS)/srcdir-step2.d $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH)
bzcat $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH) | patch -d $(GCC_SRCDIR) -p1
cd $(GCC_SRCDIR) && ./contrib/gcc_update --touch
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
for p in `ls $(RECIPES)/patches/gcc/*.p` ; do patch -d $(GCC_SRCDIR) -p0 <$$p ; done
touch $@
diff --git a/m68k-atari-mint/Makefile b/m68k-atari-mint/Makefile
index c4584b0..9e22324 100644
--- a/m68k-atari-mint/Makefile
+++ b/m68k-atari-mint/Makefile
@@ -49,6 +49,8 @@ GCC_AUTOCONF := autoconf2.64
GCC_AUTOHEADER := autoheader2.64
GCC_AUTORECONF := autoreconf2.64
GCC_AUTOM4TE := autom4te2.64
+GCC_AUTOMAKE := automake-1.11
+GCC_ACLOCAL := aclocal-1.11
TOP := $(CURDIR)
RECIPES := $(TOP)/recipes
@@ -131,7 +133,7 @@ $(BUILDSTEPS)/mintlib.d: $(BUILDSTEPS)/bootstrap-compiler.d $(SOURCESDIR)/$(UPST
# Rules to build and install the bootstrap compiler
###
-GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) PATH="$(PREFIX)/bin:$(PATH)"
+GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) ACLOCAL=$(GCC_ACLOCAL) AUTOMAKE=$(GCC_AUTOMAKE) PATH="$(PREFIX)/bin:$(PATH)"
$(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/binutils.d $(BUILDSTEPS)/mintbin.d
cd $(BUILDDIR) && $(GCC_ENV_PARAMS) $(GCC_SRCDIR)/configure \
@@ -153,9 +155,9 @@ $(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/b
$(BUILDSTEPS)/srcdir-step3.d: $(BUILDSTEPS)/srcdir-step2.d $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH)
bzcat $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH) | patch -d $(GCC_SRCDIR) -p1
cd $(GCC_SRCDIR) && ./contrib/gcc_update --touch
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
for p in `ls $(RECIPES)/patches/gcc/*.p` ; do patch -d $(GCC_SRCDIR) -p0 <$$p ; done
touch $@
--
1.8.5.2
It seems automake on latest Debian is too recent for the autoconf we
want to use.
This patch forces using aclocal/automake 1.11 which seems to work correctly.
It still fails later trying to build pml though:
...
make -f Makefile.32 libpml32.a
make[2]: Entering directory
`/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
-o cadd.o cadd.c
cadd.c:69:19: fatal error: stdio.h: No such file or directory
Same for m5475-atari-mint.
François.
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= <revol@free.fr>
Date: Fri, 24 Jan 2014 20:47:59 +0100
Subject: [PATCH] atari-mint: Force automake/aclocal to 1.11
Since we force autoconf and friends to 2.64, on Debian unstable
at leastsome aclocal macros complain that they require at least 2.65.
Also add automake1.11 to the list of required debian packages.
---
README | 2 +-
m5475-atari-mint/Makefile | 10 ++++++----
m68k-atari-mint/Makefile | 10 ++++++----
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/README b/README
index 84c872c..a791bdc 100644
--- a/README
+++ b/README
@@ -5,7 +5,7 @@ Pre-requisites for Debian systems
$ apt-get install build-essential autoconf automake autogen flex bison
$ apt-get install libtool texinfo help2man subversion cvs git
- $ apt-get install lhasa unzip autoconf2.64
+ $ apt-get install lhasa unzip autoconf2.64 automake1.11
On multiarch-aware systems:
diff --git a/m5475-atari-mint/Makefile b/m5475-atari-mint/Makefile
index 43e6c56..e236cf7 100644
--- a/m5475-atari-mint/Makefile
+++ b/m5475-atari-mint/Makefile
@@ -49,6 +49,8 @@ GCC_AUTOCONF := autoconf2.64
GCC_AUTOHEADER := autoheader2.64
GCC_AUTORECONF := autoreconf2.64
GCC_AUTOM4TE := autom4te2.64
+GCC_AUTOMAKE := automake-1.11
+GCC_ACLOCAL := aclocal-1.11
TOP := $(CURDIR)
RECIPES := $(TOP)/recipes
@@ -131,7 +133,7 @@ $(BUILDSTEPS)/mintlib.d: $(BUILDSTEPS)/bootstrap-compiler.d $(SOURCESDIR)/$(UPST
# Rules to build and install the bootstrap compiler
###
-GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) PATH="$(PREFIX)/bin:$(PATH)"
+GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) ACLOCAL=$(GCC_ACLOCAL) AUTOMAKE=$(GCC_AUTOMAKE) PATH="$(PREFIX)/bin:$(PATH)"
$(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/binutils.d $(BUILDSTEPS)/mintbin.d
cd $(BUILDDIR) && $(GCC_ENV_PARAMS) $(GCC_SRCDIR)/configure \
@@ -154,9 +156,9 @@ $(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/b
$(BUILDSTEPS)/srcdir-step3.d: $(BUILDSTEPS)/srcdir-step2.d $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH)
bzcat $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH) | patch -d $(GCC_SRCDIR) -p1
cd $(GCC_SRCDIR) && ./contrib/gcc_update --touch
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
for p in `ls $(RECIPES)/patches/gcc/*.p` ; do patch -d $(GCC_SRCDIR) -p0 <$$p ; done
touch $@
diff --git a/m68k-atari-mint/Makefile b/m68k-atari-mint/Makefile
index c4584b0..9e22324 100644
--- a/m68k-atari-mint/Makefile
+++ b/m68k-atari-mint/Makefile
@@ -49,6 +49,8 @@ GCC_AUTOCONF := autoconf2.64
GCC_AUTOHEADER := autoheader2.64
GCC_AUTORECONF := autoreconf2.64
GCC_AUTOM4TE := autom4te2.64
+GCC_AUTOMAKE := automake-1.11
+GCC_ACLOCAL := aclocal-1.11
TOP := $(CURDIR)
RECIPES := $(TOP)/recipes
@@ -131,7 +133,7 @@ $(BUILDSTEPS)/mintlib.d: $(BUILDSTEPS)/bootstrap-compiler.d $(SOURCESDIR)/$(UPST
# Rules to build and install the bootstrap compiler
###
-GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) PATH="$(PREFIX)/bin:$(PATH)"
+GCC_ENV_PARAMS := AUTOCONF=$(GCC_AUTOCONF) AUTOHEADER=$(GCC_AUTOHEADER) AUTOM4TE=$(GCC_AUTOM4TE) ACLOCAL=$(GCC_ACLOCAL) AUTOMAKE=$(GCC_AUTOMAKE) PATH="$(PREFIX)/bin:$(PATH)"
$(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/binutils.d $(BUILDSTEPS)/mintbin.d
cd $(BUILDDIR) && $(GCC_ENV_PARAMS) $(GCC_SRCDIR)/configure \
@@ -153,9 +155,9 @@ $(BUILDSTEPS)/bootstrap-compiler.d: $(BUILDSTEPS)/srcdir-step3.d $(BUILDSTEPS)/b
$(BUILDSTEPS)/srcdir-step3.d: $(BUILDSTEPS)/srcdir-step2.d $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH)
bzcat $(SOURCESDIR)/$(UPSTREAM_GCC_PATCH) | patch -d $(GCC_SRCDIR) -p1
cd $(GCC_SRCDIR) && ./contrib/gcc_update --touch
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
- $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libmudflap
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libssp
+ $(GCC_ENV_PARAMS) $(GCC_AUTORECONF) -f $(GCC_SRCDIR)/libquadmath
for p in `ls $(RECIPES)/patches/gcc/*.p` ; do patch -d $(GCC_SRCDIR) -p0 <$$p ; done
touch $@
--
1.8.5.2
It seems automake on latest Debian is too recent for the autoconf we
want to use.
This patch forces using aclocal/automake 1.11 which seems to work correctly.
It still fails later trying to build pml though:
...
make -f Makefile.32 libpml32.a
make[2]: Entering directory
`/mnt/data/devel/netsurf/workspace/toolchains/m68k-atari-mint/builddir/pml/pmlsrc'
m68k-atari-mint-gcc -O2 -fomit-frame-pointer -DIEEE -DNO_DBUG -I. -c
-o cadd.o cadd.c
cadd.c:69:19: fatal error: stdio.h: No such file or directory
Same for m5475-atari-mint.
François.
Re: Output from forms different in Netsurf than other browsers.
In article <53ce673e55brian.jordan9@btinternet.com>,
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <53ce20aa62tlsa@netsurf-browser.org>,
> Michael Drake <tlsa@netsurf-browser.org> wrote:
> > In article <53cdf35ab4brian.jordan9@btinternet.com>,
> > Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > > A bit more checking show that 3.1 (Dev CI #1586) submits emails
> > > formatted the sames as other browsers whereas (Dev CI #1598) submits
> > > the different formatting. I don't have versions between these to
> > > enable me to narrow it down further.
> > Please report it on the bug tracker and include the HTML for the page
> > with the form.
> Reported.
And fixed in #1644. Excellent!
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <53ce20aa62tlsa@netsurf-browser.org>,
> Michael Drake <tlsa@netsurf-browser.org> wrote:
> > In article <53cdf35ab4brian.jordan9@btinternet.com>,
> > Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > > A bit more checking show that 3.1 (Dev CI #1586) submits emails
> > > formatted the sames as other browsers whereas (Dev CI #1598) submits
> > > the different formatting. I don't have versions between these to
> > > enable me to narrow it down further.
> > Please report it on the bug tracker and include the HTML for the page
> > with the form.
> Reported.
And fixed in #1644. Excellent!
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Thursday, 23 January 2014
[Rpcemu] Non booting with tip revision from Mercurial
Hi,
It looks like the change in revision 809 to 'iomd.c' has stopped RPCEmu
getting past POST (and hence booting) with RISC OS 5. The RISC OS 5 HAL
checks the version register and if zero assumes it's on RPCEmu (knowing that
none of the real IOMD-a-like chips had a version 0) and skips the POST tests.
Now the register reports the true version POST runs and fails. My bet would
be it's the Vsync timing test, so in my local copy I just set the id back to
zero to keep moving. It's worth noting I think that this test also fails on
normal ROMs (OS 3.70 et al) as there's a flash of red screen on startup.
Options I see
1. Improve the timing accuracy of the VIDC emulation so it passes POST.
I'm not sure I understand how the video thread runs well enough to say
how hard/possible that is on the various OS' you can run RPCEmu on.
It
2. Just change the version registers back to 0.
I assume the IOMD2 one would need to be right for Phoebe?
3. Add RISC OS 5 to the known OS images in 'romload.c' and patch it with NOPs
As the ROM is a moving target the patch might need to search for
instruction sequences rather than just poking known addresses.
4. Similar to (3) but only set version register to 0 if RISC OS 5 spotted
This is simpler than scanning the ROM, since the magic "OSIm" marker can
quickly identify what was loaded.
Or some other option I've not thought of,
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
It looks like the change in revision 809 to 'iomd.c' has stopped RPCEmu
getting past POST (and hence booting) with RISC OS 5. The RISC OS 5 HAL
checks the version register and if zero assumes it's on RPCEmu (knowing that
none of the real IOMD-a-like chips had a version 0) and skips the POST tests.
Now the register reports the true version POST runs and fails. My bet would
be it's the Vsync timing test, so in my local copy I just set the id back to
zero to keep moving. It's worth noting I think that this test also fails on
normal ROMs (OS 3.70 et al) as there's a flash of red screen on startup.
Options I see
1. Improve the timing accuracy of the VIDC emulation so it passes POST.
I'm not sure I understand how the video thread runs well enough to say
how hard/possible that is on the various OS' you can run RPCEmu on.
It
2. Just change the version registers back to 0.
I assume the IOMD2 one would need to be right for Phoebe?
3. Add RISC OS 5 to the known OS images in 'romload.c' and patch it with NOPs
As the ROM is a moving target the patch might need to search for
instruction sequences rather than just poking known addresses.
4. Similar to (3) but only set version register to 0 if RISC OS 5 spotted
This is simpler than scanning the ROM, since the magic "OSIm" marker can
quickly identify what was loaded.
Or some other option I've not thought of,
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 22 January 2014
[Rpcemu] Patch to mingw makefile
Hi,
Since the Windows bits are now in a subdirectory the mingw makefile fails
when running the windres tool as it can't find the icon. I've added the
'win' directory to its search path (see patch),
Sprow.
diff -r 8e9292da9ab1 src/Makefile.mingw
--- a/src/Makefile.mingw Mon Dec 09 17:47:07 2013 +0000
+++ b/src/Makefile.mingw Thu Jan 23 07:43:15 2014 +0000
@@ -67,7 +67,7 @@
$(LD) $(LDFLAGS) -o $@ $+ $(LIBS)
win\acorn.o: win\acorn.rc win\rpcemu.ico win\rpcemu.manifest
- windres -O COFF win\acorn.rc win\acorn.o
+ windres -O COFF -I win win\acorn.rc win\acorn.o
config.h: config.h.mingw
copy /B config.h.mingw config.h
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Since the Windows bits are now in a subdirectory the mingw makefile fails
when running the windres tool as it can't find the icon. I've added the
'win' directory to its search path (see patch),
Sprow.
diff -r 8e9292da9ab1 src/Makefile.mingw
--- a/src/Makefile.mingw Mon Dec 09 17:47:07 2013 +0000
+++ b/src/Makefile.mingw Thu Jan 23 07:43:15 2014 +0000
@@ -67,7 +67,7 @@
$(LD) $(LDFLAGS) -o $@ $+ $(LIBS)
win\acorn.o: win\acorn.rc win\rpcemu.ico win\rpcemu.manifest
- windres -O COFF win\acorn.rc win\acorn.o
+ windres -O COFF -I win win\acorn.rc win\acorn.o
config.h: config.h.mingw
copy /B config.h.mingw config.h
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Output from forms different in Netsurf than other browsers.
In article <53ce20aa62tlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> In article <53cdf35ab4brian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > A bit more checking show that 3.1 (Dev CI #1586) submits emails
> > formatted the sames as other browsers whereas (Dev CI #1598) submits
> > the different formatting. I don't have versions between these to
> > enable me to narrow it down further.
> Please report it on the bug tracker and include the HTML for the page
> with the form.
Reported.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Michael Drake <tlsa@netsurf-browser.org> wrote:
> In article <53cdf35ab4brian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > A bit more checking show that 3.1 (Dev CI #1586) submits emails
> > formatted the sames as other browsers whereas (Dev CI #1598) submits
> > the different formatting. I don't have versions between these to
> > enable me to narrow it down further.
> Please report it on the bug tracker and include the HTML for the page
> with the form.
Reported.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: Output from forms different in Netsurf than other browsers.
In article <53cdf35ab4brian.jordan9@btinternet.com>,
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> A bit more checking show that 3.1 (Dev CI #1586) submits emails formatted
> the sames as other browsers whereas (Dev CI #1598) submits the different
> formatting. I don't have versions between these to enable me to narrow it
> down further.
Please report it on the bug tracker and include the HTML for the page with
the form.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> A bit more checking show that 3.1 (Dev CI #1586) submits emails formatted
> the sames as other browsers whereas (Dev CI #1598) submits the different
> formatting. I don't have versions between these to enable me to narrow it
> down further.
Please report it on the bug tracker and include the HTML for the page with
the form.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Output from forms different in Netsurf than other browsers.
In article <53cdc3dd71brian.jordan9@btinternet.com>,
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <53cda29d93brian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
> [Snip]
> >There is a difference in the formatting of the emails submitted from
> > Netsurf than all browsers used by league members as shown below.
> [Snip]
> A bit of checking this evening shows that the emails are formatted the
> same as those submitted from other browsers when the form is submitted
> from Netsurf 3.0 (20th April 2013) but the different formatting is
> evident when using 3.1 (Dev CI #1635).
A bit more checking show that 3.1 (Dev CI #1586) submits emails formatted
the sames as other browsers whereas (Dev CI #1598) submits the different
formatting. I don't have versions between these to enable me to narrow it
down further.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <53cda29d93brian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
> [Snip]
> >There is a difference in the formatting of the emails submitted from
> > Netsurf than all browsers used by league members as shown below.
> [Snip]
> A bit of checking this evening shows that the emails are formatted the
> same as those submitted from other browsers when the form is submitted
> from Netsurf 3.0 (20th April 2013) but the different formatting is
> evident when using 3.1 (Dev CI #1635).
A bit more checking show that 3.1 (Dev CI #1586) submits emails formatted
the sames as other browsers whereas (Dev CI #1598) submits the different
formatting. I don't have versions between these to enable me to narrow it
down further.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Tuesday, 21 January 2014
Re: Paypal bank transfer
On 21 Jan 2014 as I do recall,
Michael Drake wrote:
> In article <31a32dcd53.harriet@blueyonder.co.uk>,
> Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> > I can't seem to withdraw money to my bank account from Paypal using
> > Netsurf any more (it just gives a page saying there may have been an
> > error) -- is it a temporary glitch or have they introduced a JavaScripty
> > dependency since I last withdrew money in October?
>
> You don't say which version of NetSurf you're testing.
>
> Anyway, try #1635, which has a SELECT element bug fix.
>
It was #1624, apparently. (At least, that was the last one I'd
downloaded....)
Tried again with #1635 - with JS off, I get
"Sorry, an error occurred after you clicked the last link
"If you were in the process of buying something, or sending money to
family or friends, we recommend you check both your PayPal account and
your email inbox for a transaction confirmation after 30 minutes."
(But I didn't get any transaction-related e-mail last time, and probably
won't this time.)
With JS on, I get completely blank pages, from
https://www.paypal.com/uk/cgi-bin/webscr?cmd=_account onwards.
--
Harriet Bazley == Loyaulte me lie ==
Money is the root of all evil - and man needs roots
Michael Drake wrote:
> In article <31a32dcd53.harriet@blueyonder.co.uk>,
> Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> > I can't seem to withdraw money to my bank account from Paypal using
> > Netsurf any more (it just gives a page saying there may have been an
> > error) -- is it a temporary glitch or have they introduced a JavaScripty
> > dependency since I last withdrew money in October?
>
> You don't say which version of NetSurf you're testing.
>
> Anyway, try #1635, which has a SELECT element bug fix.
>
It was #1624, apparently. (At least, that was the last one I'd
downloaded....)
Tried again with #1635 - with JS off, I get
"Sorry, an error occurred after you clicked the last link
"If you were in the process of buying something, or sending money to
family or friends, we recommend you check both your PayPal account and
your email inbox for a transaction confirmation after 30 minutes."
(But I didn't get any transaction-related e-mail last time, and probably
won't this time.)
With JS on, I get completely blank pages, from
https://www.paypal.com/uk/cgi-bin/webscr?cmd=_account onwards.
--
Harriet Bazley == Loyaulte me lie ==
Money is the root of all evil - and man needs roots
Re: Output from forms different in Netsurf than other browsers.
In article <53cda29d93brian.jordan9@btinternet.com>,
Brian Jordan <brian.jordan9@btinternet.com> wrote:
[Snip]
>There is a difference in the formatting of the emails submitted from
> Netsurf than all browsers used by league members as shown below.
[Snip]
A bit of checking this evening shows that the emails are formatted the
same as those submitted from other browsers when the form is submitted
from Netsurf 3.0 (20th April 2013) but the different formatting is
evident when using 3.1 (Dev CI #1635).
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Brian Jordan <brian.jordan9@btinternet.com> wrote:
[Snip]
>There is a difference in the formatting of the emails submitted from
> Netsurf than all browsers used by league members as shown below.
[Snip]
A bit of checking this evening shows that the emails are formatted the
same as those submitted from other browsers when the form is submitted
from Netsurf 3.0 (20th April 2013) but the different formatting is
evident when using 3.1 (Dev CI #1635).
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Streetmap.co.uk
I'm having great difficulty getting map pages from streetmap.co.uk.
Many of the aquares don't appear, and if I refresh the page I just get
a different random selection of squares. It is very difficult to get
all nine squares of a small map at once, and virtually impossible to
get all 25 of a large map. What's the problem?
--
Richard Porter http://www.minijem.plus.com/
Skype: minijem2 mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Many of the aquares don't appear, and if I refresh the page I just get
a different random selection of squares. It is very difficult to get
all nine squares of a small map at once, and virtually impossible to
get all 25 of a large map. What's the problem?
--
Richard Porter http://www.minijem.plus.com/
Skype: minijem2 mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Output from forms different in Netsurf than other browsers.
I run the web site for our local pub quiz league where one of the pages
has a form on which teams can submit their match scores, the information
gets to me via formmail.com and Pluto. There is a difference in the
formatting of the emails submitted from Netsurf than all browsers used by
league members as shown below.
Other browsers...
-------------------------------------------------------------------------
Date: 20 Jan 2014
Home Team: Red Lion
Home Score: 43
Away Team: White Hart, Overton
A Questions: on
Away Score: 54
Member of: White Hart, Overton
-------------------------------------------------------------------------
Netsurf...
-------------------------------------------------------------------------
Date:
27 Jan 2014
Home Team:
Bell
Home Score: 99
Away Team:
Greyhound
A Questions: on
Away Score: 99
Member of:
Bell
-------------------------------------------------------------------------
The formatting is different where the data field in the form uses a drop
down menu.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
has a form on which teams can submit their match scores, the information
gets to me via formmail.com and Pluto. There is a difference in the
formatting of the emails submitted from Netsurf than all browsers used by
league members as shown below.
Other browsers...
-------------------------------------------------------------------------
Date: 20 Jan 2014
Home Team: Red Lion
Home Score: 43
Away Team: White Hart, Overton
A Questions: on
Away Score: 54
Member of: White Hart, Overton
-------------------------------------------------------------------------
Netsurf...
-------------------------------------------------------------------------
Date:
27 Jan 2014
Home Team:
Bell
Home Score: 99
Away Team:
Greyhound
A Questions: on
Away Score: 99
Member of:
Bell
-------------------------------------------------------------------------
The formatting is different where the data field in the form uses a drop
down menu.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: Embeddable web view in apps
On 21/01/2014 16:56, Rob Kendrick wrote:
> On Sun, Dec 15, 2013 at 08:45:18AM -0800, Richard Gale wrote:
>> It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
>> Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
>
> The core is not currently "embeddable" as such, although we are working
> towards that.
>
> Additionally, the core is licenced under GPLv2. You'd be welcome to
> embed it in a paid-for app, as long as it was also licenced under the
> GPLv2.
Actually, there is one case of such use, in the BeOS frontend.
We actually expose the Replicant interface, that allows other
applications to embed a Netsurf view inside itself, either by
drag-n-drop, or programmatically.
It currently has some bugs but it works at least with the BeHappy help
browser:
https://github.com/HaikuArchives/BeHappy
As for the licence, since the applications are not compile-time linked
to NetSurf but instead rely on a standardized API, I'm not sure what the
constraints would be, but definitely different than with explicit
linking. BeHappy is MIT-licenced anyway, which is GPL compatible.
François.
> On Sun, Dec 15, 2013 at 08:45:18AM -0800, Richard Gale wrote:
>> It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
>> Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
>
> The core is not currently "embeddable" as such, although we are working
> towards that.
>
> Additionally, the core is licenced under GPLv2. You'd be welcome to
> embed it in a paid-for app, as long as it was also licenced under the
> GPLv2.
Actually, there is one case of such use, in the BeOS frontend.
We actually expose the Replicant interface, that allows other
applications to embed a Netsurf view inside itself, either by
drag-n-drop, or programmatically.
It currently has some bugs but it works at least with the BeHappy help
browser:
https://github.com/HaikuArchives/BeHappy
As for the licence, since the applications are not compile-time linked
to NetSurf but instead rely on a standardized API, I'm not sure what the
constraints would be, but definitely different than with explicit
linking. BeHappy is MIT-licenced anyway, which is GPL compatible.
François.
Re: Embeddable web view in apps
On Sun, Dec 15, 2013 at 08:45:18AM -0800, Richard Gale wrote:
> It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
> Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
The core is not currently "embeddable" as such, although we are working
towards that.
Additionally, the core is licenced under GPLv2. You'd be welcome to
embed it in a paid-for app, as long as it was also licenced under the
GPLv2.
B.
> It seems like netsurf is a great candidate for providing HTML based UI in apps. Is this something anyone has tried from a technical point of view?
> Does the current licensing support this for paid for apps or is netsurf licensable for such purposes?
The core is not currently "embeddable" as such, although we are working
towards that.
Additionally, the core is licenced under GPLv2. You'd be welcome to
embed it in a paid-for app, as long as it was also licenced under the
GPLv2.
B.
Re: [Rpcemu] Patch for floppy reading on ADFS 3.34 and later
On Mon, Jan 20, 2014 at 09:34:45PM +0000, Sprow wrote:
> The following patch implements that missing command. It's actually
> remarkably similar to the read sectors command, except there's no data
> transfer phase (in the real hardware the 37C665 swallows it all).
>
> I've tested this by grabbing the empty 800k floppy image from marutan.net
> (now it's back online) mounting it in RISC OS 5.21, and writing a 600k
> sprite image into it, rebooting, and reading it back.
Hi Sprow, thanks for this, I'll see about merging it in. I had another
patch in the same area for allowing floppy formatting, so I'll see about
getting them both in.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> The following patch implements that missing command. It's actually
> remarkably similar to the read sectors command, except there's no data
> transfer phase (in the real hardware the 37C665 swallows it all).
>
> I've tested this by grabbing the empty 800k floppy image from marutan.net
> (now it's back online) mounting it in RISC OS 5.21, and writing a 600k
> sprite image into it, rebooting, and reading it back.
Hi Sprow, thanks for this, I'll see about merging it in. I had another
patch in the same area for allowing floppy formatting, so I'll see about
getting them both in.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Paypal bank transfer
In article <31a32dcd53.harriet@blueyonder.co.uk>,
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> I can't seem to withdraw money to my bank account from Paypal using
> Netsurf any more (it just gives a page saying there may have been an
> error) -- is it a temporary glitch or have they introduced a JavaScripty
> dependency since I last withdrew money in October?
You don't say which version of NetSurf you're testing.
Anyway, try #1635, which has a SELECT element bug fix.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Harriet Bazley <lists@orange.wingsandbeaks.org.uk> wrote:
> I can't seem to withdraw money to my bank account from Paypal using
> Netsurf any more (it just gives a page saying there may have been an
> error) -- is it a temporary glitch or have they introduced a JavaScripty
> dependency since I last withdrew money in October?
You don't say which version of NetSurf you're testing.
Anyway, try #1635, which has a SELECT element bug fix.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Monday, 20 January 2014
Paypal bank transfer
I can't seem to withdraw money to my bank account from Paypal using
Netsurf any more (it just gives a page saying there may have been an
error) -- is it a temporary glitch or have they introduced a JavaScripty
dependency since I last withdrew money in October?
--
Harriet Bazley == Loyaulte me lie ==
He that would govern others, first should be master of himself.
Netsurf any more (it just gives a page saying there may have been an
error) -- is it a temporary glitch or have they introduced a JavaScripty
dependency since I last withdrew money in October?
--
Harriet Bazley == Loyaulte me lie ==
He that would govern others, first should be master of himself.
[Rpcemu] Patch for floppy reading on ADFS 3.34 and later
Hi,
Since the Iyonix era RISC OS 5's ADFS has made use of the verify sectors
command in order to speed up verifying a sector, which ADFS does just before
mounting a disc (and a few other situations).
As a result, ADFS in RISC OS 5 for the IOMD family also uses the verify
sectors command, but as RPCEmu doesn't emulate that clicking on the floppy
drive icon gives a "Bad FDC command" error and quits. Bad.
The following patch implements that missing command. It's actually
remarkably similar to the read sectors command, except there's no data
transfer phase (in the real hardware the 37C665 swallows it all).
I've tested this by grabbing the empty 800k floppy image from marutan.net
(now it's back online) mounting it in RISC OS 5.21, and writing a 600k
sprite image into it, rebooting, and reading it back.
Cheers,
Sprow.
--- fdc-0-8-11/c 2014-01-20 21:21:26.0 +0000
+++ fdc-verify/c 2014-01-20 21:21:26.0 +0000
@@ -25,6 +25,7 @@
FD_CMD_WRITE_DATA_MFM = 0x45,
FD_CMD_READ_DATA_MFM = 0x46,
FD_CMD_READ_ID_MFM = 0x4a,
+ FD_CMD_VERIFY_DATA_MFM = 0x56
};
static void fdcsend(uint8_t val);
@@ -223,6 +224,7 @@
break;
case FD_CMD_READ_DATA_MFM:
+ case FD_CMD_VERIFY_DATA_MFM:
fdc.commandpos=0;
fdccallback=1000;
fdc.st0=fdc.parameters[0]&7;
@@ -317,6 +319,7 @@
case FD_CMD_WRITE_DATA_MFM:
case FD_CMD_READ_DATA_MFM:
+ case FD_CMD_VERIFY_DATA_MFM:
fdc.params=8;
fdc.curparam=0;
fdc.status=0x90;
@@ -598,6 +601,27 @@
}
break;
+ case FD_CMD_VERIFY_DATA_MFM:
+// printf("Verify data callback %i\n",fdc.commandpos);
+ fdc.sector=fdc.parameters[5]; /* Verified OK (amazing!),
jump straight to the end */
+ switch (fdc.commandpos)
+ {
+ case 0: fdcsend(fdc.st0); break;
+ case 1: fdcsend2(fdc.st1); break;
+ case 2: fdcsend2(fdc.st2); break;
+ case 3: fdcsend2(fdc.track); break;
+ case 4: fdcsend2((fdc.parameters[0]&4)?1:0); break;
+ case 5: fdcsend2(fdc.sector); break;
+ case 6:
+ fdcsend2(3);
+ fdc.incommand=0;
+ fdc.params=fdc.curparam=0;
+ fdccallback=0;
+ break;
+ }
+ fdc.commandpos++;
+ break;
+
case FD_CMD_READ_ID_MFM:
if (fdc.sector >= drives[fdc.st0 & 1].discsectors) {
fdc.sector = 0;
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Since the Iyonix era RISC OS 5's ADFS has made use of the verify sectors
command in order to speed up verifying a sector, which ADFS does just before
mounting a disc (and a few other situations).
As a result, ADFS in RISC OS 5 for the IOMD family also uses the verify
sectors command, but as RPCEmu doesn't emulate that clicking on the floppy
drive icon gives a "Bad FDC command" error and quits. Bad.
The following patch implements that missing command. It's actually
remarkably similar to the read sectors command, except there's no data
transfer phase (in the real hardware the 37C665 swallows it all).
I've tested this by grabbing the empty 800k floppy image from marutan.net
(now it's back online) mounting it in RISC OS 5.21, and writing a 600k
sprite image into it, rebooting, and reading it back.
Cheers,
Sprow.
--- fdc-0-8-11/c 2014-01-20 21:21:26.0 +0000
+++ fdc-verify/c 2014-01-20 21:21:26.0 +0000
@@ -25,6 +25,7 @@
FD_CMD_WRITE_DATA_MFM = 0x45,
FD_CMD_READ_DATA_MFM = 0x46,
FD_CMD_READ_ID_MFM = 0x4a,
+ FD_CMD_VERIFY_DATA_MFM = 0x56
};
static void fdcsend(uint8_t val);
@@ -223,6 +224,7 @@
break;
case FD_CMD_READ_DATA_MFM:
+ case FD_CMD_VERIFY_DATA_MFM:
fdc.commandpos=0;
fdccallback=1000;
fdc.st0=fdc.parameters[0]&7;
@@ -317,6 +319,7 @@
case FD_CMD_WRITE_DATA_MFM:
case FD_CMD_READ_DATA_MFM:
+ case FD_CMD_VERIFY_DATA_MFM:
fdc.params=8;
fdc.curparam=0;
fdc.status=0x90;
@@ -598,6 +601,27 @@
}
break;
+ case FD_CMD_VERIFY_DATA_MFM:
+// printf("Verify data callback %i\n",fdc.commandpos);
+ fdc.sector=fdc.parameters[5]; /* Verified OK (amazing!),
jump straight to the end */
+ switch (fdc.commandpos)
+ {
+ case 0: fdcsend(fdc.st0); break;
+ case 1: fdcsend2(fdc.st1); break;
+ case 2: fdcsend2(fdc.st2); break;
+ case 3: fdcsend2(fdc.track); break;
+ case 4: fdcsend2((fdc.parameters[0]&4)?1:0); break;
+ case 5: fdcsend2(fdc.sector); break;
+ case 6:
+ fdcsend2(3);
+ fdc.incommand=0;
+ fdc.params=fdc.curparam=0;
+ fdccallback=0;
+ break;
+ }
+ fdc.commandpos++;
+ break;
+
case FD_CMD_READ_ID_MFM:
if (fdc.sector >= drives[fdc.st0 & 1].discsectors) {
fdc.sector = 0;
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] marutan.net down?
On Mon, Jan 20, 2014 at 11:06:08AM +0000, Peter Howkins wrote:
> On Sun, Jan 19, 2014 at 09:14:57PM +0000, Sprow wrote:
> > Says ICANN have suspended it - it looks like the domain owners need to
> > update some whois record. Hopefully that's in progress already?
>
> Yeah, aparently within 24-48 hours it'll be resolved.
DNS seems to be back up again, if anyone still can't connect after 24
hours (it can take time for various caching DNS servers to receive
updates) or finds any parts that are still down please contact me.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Sun, Jan 19, 2014 at 09:14:57PM +0000, Sprow wrote:
> > Says ICANN have suspended it - it looks like the domain owners need to
> > update some whois record. Hopefully that's in progress already?
>
> Yeah, aparently within 24-48 hours it'll be resolved.
DNS seems to be back up again, if anyone still can't connect after 24
hours (it can take time for various caching DNS servers to receive
updates) or finds any parts that are still down please contact me.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] marutan.net down?
On 20 Jan 2014, at 11:06, Peter Howkins wrote:
On Sun, Jan 19, 2014 at 09:14:57PM +0000, Sprow wrote:Says ICANN have suspended it - it looks like the domain owners need toupdate some whois record. Hopefully that's in progress already?
Yeah, aparently within 24-48 hours it'll be resolved.
And there was me thinking that the mails from my registrar were a phising
attempt ...
Though as I received this email maybe it will be faster.
It was!
--
David Pitt
Re: [Rpcemu] marutan.net down?
On Sun, Jan 19, 2014 at 09:14:57PM +0000, Sprow wrote:
> Says ICANN have suspended it - it looks like the domain owners need to
> update some whois record. Hopefully that's in progress already?
Yeah, aparently within 24-48 hours it'll be resolved.
And there was me thinking that the mails from my registrar were a phising
attempt ...
Though as I received this email maybe it will be faster.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Says ICANN have suspended it - it looks like the domain owners need to
> update some whois record. Hopefully that's in progress already?
Yeah, aparently within 24-48 hours it'll be resolved.
And there was me thinking that the mails from my registrar were a phising
attempt ...
Though as I received this email maybe it will be faster.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 19 January 2014
Re: document.write but not document.writeln
On Sat, Jan 18, 2014 at 11:18:35PM +0000, Dave Higton wrote:
> I'm completely new to JavaScript.
>
> I tried a small number of elementary JavaScript examples this evening
> with NS 1627, and it appears that document.write works, but
> document.writeln seems to output nothing. Is that what you would
> expect?
Almost certainly: I don't believe document.writeln is implemented.
> Is there any page where the implementation status of JavaScript
> features or functions within NS is tracked for users to see?
No there is not, and I don't expect there will be until there is
significantly more script support than there is at present. Right now,
if anything works at all, that's a bonus.
J.
> I'm completely new to JavaScript.
>
> I tried a small number of elementary JavaScript examples this evening
> with NS 1627, and it appears that document.write works, but
> document.writeln seems to output nothing. Is that what you would
> expect?
Almost certainly: I don't believe document.writeln is implemented.
> Is there any page where the implementation status of JavaScript
> features or functions within NS is tracked for users to see?
No there is not, and I don't expect there will be until there is
significantly more script support than there is at present. Right now,
if anything works at all, that's a bonus.
J.
[Rpcemu] marutan.net down?
Hi,
Says ICANN have suspended it - it looks like the domain owners need to
update some whois record. Hopefully that's in progress already?
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Says ICANN have suspended it - it looks like the domain owners need to
update some whois record. Hopefully that's in progress already?
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Page layout
This page doesn't render very well, it may be the JS.
http://help.crystalski.co.uk/crystalski
Also I did a search and when I tried to open the results it just
times out.
Peter
http://help.crystalski.co.uk/crystalski
Also I did a search and when I tried to open the results it just
times out.
Peter
Saturday, 18 January 2014
document.write but not document.writeln
I'm completely new to JavaScript.
I tried a small number of elementary JavaScript examples this evening
with NS 1627, and it appears that document.write works, but
document.writeln seems to output nothing. Is that what you would
expect?
Is there any page where the implementation status of JavaScript
features or functions within NS is tracked for users to see? It
seems to me that it would be useful for those of us who are hoping
to write pages or sites likely to be visited by NS users, and
maybe as a help for those of us who are learning JavaScript too.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
I tried a small number of elementary JavaScript examples this evening
with NS 1627, and it appears that document.write works, but
document.writeln seems to output nothing. Is that what you would
expect?
Is there any page where the implementation status of JavaScript
features or functions within NS is tracked for users to see? It
seems to me that it would be useful for those of us who are hoping
to write pages or sites likely to be visited by NS users, and
maybe as a help for those of us who are learning JavaScript too.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
[PATCH] gcc2 fix : whitespace before last comma in varargs macro
>From eeb696c4c12c0c6ccf967eb5666cb321f5ec8d0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= <revol@free.fr>
Date: Sat, 18 Jan 2014 10:31:21 +0100
Subject: [PATCH] gcc2 fix : whitespace before last comma in varargs macro
gcc2 doesn't seem to see the last comma before the ## args
unless it's separated from the previous arg by a whitespace.
---
src/options.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/options.h b/src/options.h
index 13c02be..9ccaa3a 100644
--- a/src/options.h
+++ b/src/options.h
@@ -36,7 +36,7 @@ enum opt_warnings {
#define WARN(flags, msg, args...) do { \
if ((options->warnings & flags) != 0) { \
- fprintf(stderr, "%s: warning:"msg"\n", __func__, ## args); \
+ fprintf(stderr, "%s: warning:"msg"\n", __func__ , ## args); \
} \
} while(0)
--
1.8.3.4
gcc2 doesn't seem to see the last comma before the ## args
unless it's separated from the previous arg by a whitespace.
François.
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= <revol@free.fr>
Date: Sat, 18 Jan 2014 10:31:21 +0100
Subject: [PATCH] gcc2 fix : whitespace before last comma in varargs macro
gcc2 doesn't seem to see the last comma before the ## args
unless it's separated from the previous arg by a whitespace.
---
src/options.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/options.h b/src/options.h
index 13c02be..9ccaa3a 100644
--- a/src/options.h
+++ b/src/options.h
@@ -36,7 +36,7 @@ enum opt_warnings {
#define WARN(flags, msg, args...) do { \
if ((options->warnings & flags) != 0) { \
- fprintf(stderr, "%s: warning:"msg"\n", __func__, ## args); \
+ fprintf(stderr, "%s: warning:"msg"\n", __func__ , ## args); \
} \
} while(0)
--
1.8.3.4
gcc2 doesn't seem to see the last comma before the ## args
unless it's separated from the previous arg by a whitespace.
François.
Thursday, 16 January 2014
Re: Atari daily build
>On Mon, 13 Jan 2014 12:01:13
>Date: Mon, 13 Jan 2014 09:03:44 +0100
>From: Ole
>Subject: Re: Atari daily build
>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Am Samstag, den 11.01.2014, 17:04 +0100 schrieb Peter Slegg :
>
>> Unfortunately I could only find 1555 on the daily build page and that
>> has the error also.
>>
>> So it appearred between 1541 and 1555 inclusive.
>
> Thanks for investigating this, I will see which changes were done
> during these Builds.
>
> Greets,
> Ole
I am pleased to report that Atari build No. 1623 is working normally again.
Thanks,
Peter
>Date: Mon, 13 Jan 2014 09:03:44 +0100
>From: Ole
>Subject: Re: Atari daily build
>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Am Samstag, den 11.01.2014, 17:04 +0100 schrieb Peter Slegg :
>
>> Unfortunately I could only find 1555 on the daily build page and that
>> has the error also.
>>
>> So it appearred between 1541 and 1555 inclusive.
>
> Thanks for investigating this, I will see which changes were done
> during these Builds.
>
> Greets,
> Ole
I am pleased to report that Atari build No. 1623 is working normally again.
Thanks,
Peter
Re: [Rpcemu] Check your systems please
Or someone just web-crawled the RPCemu archive on the web site and the
scammers get their target email addresses from the crawler's database?
Your email address is right there if you do a simple bit of parsing.
E.g. Google for
site:http://www.riscos.info/pipermail/rpcemu/ "Bruijn" "at"
Ta,
Steve
--
Steve @ ROOL
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
scammers get their target email addresses from the crawler's database?
Your email address is right there if you do a simple bit of parsing.
E.g. Google for
site:http://www.riscos.info/pipermail/rpcemu/ "Bruijn" "at"
Ta,
Steve
--
Steve @ ROOL
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Check your systems please
Earlier today I received a Nigerian 419-scam message on this e-mail
address, an address which I have only ever used on this list. My own
system is clean, so either the server itself has been compromised or
another subscriber has had his address book stolen. Please check.
I intend to unsubscribe from this list, blacklist the now useless e-mail
address and resubscribe with another address later.
Regards,
Frank
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
address, an address which I have only ever used on this list. My own
system is clean, so either the server itself has been compromised or
another subscriber has had his address book stolen. Please check.
I intend to unsubscribe from this list, blacklist the now useless e-mail
address and resubscribe with another address later.
Regards,
Frank
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 15 January 2014
[gccsdk] [Bug 248] New: Decor package is missing Decor binary
http://www.riscos.info/bugzilla3/show_bug.cgi?id=248
Summary: Decor package is missing Decor binary
Product: Ports
Version: unspecified
Platform: All
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: peter@chocky.org
ReportedBy: info@sprow.co.uk
Estimated Hours: 0.0
The ZIP file is missing the Décor binary, all the other files appear to be
present however.
http://www.riscos.info/index.php/Decor
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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] Autobuilder libxcb1
In article <DUB120-DS146FDD0AC50CBB98988D02F0BC0@phx.gbl>,
Alan Buckley <alan_baa@hotmail.com> wrote:
> Ron wrote on Monday, January 13, 2014 11:39 AM:
> [snip]
> > But I have run aground with libxcb1 during python running through the
> > xml files. (at sync.xml)
> > I'm showing Python version 2.7.4 and the config output shows a check for
> > version >=2.6
> I don't seem to be able to build libxcb1 at all. I get the following errors:
> rman: couldn't read in referenced file man3/xcb_alloc_color_cells.3.
> Try cd'ing into ancestor directory that makes relative path valid
> first.
> make[3]: *** [install-man3] Error 1
> make[3]: Leaving directory `/home/alanb/build/libxcb1/libxcb-1.10/src'
> Did you need to do anything else to get it to build?
> > I'm not holding my breath on building the X stuff, I haven't ever
> > before, and there is probably a lot more problems after this one.
> I used to be able to build most of this, but it's been a long time
> since I've tried to do it all from scratch.
I've got a load of fixes for quite a few libraries to check in, libxcb1
being one of them. I just need to do a bit more testing. I'll try and check
in the changes Friday.
Chris.
_______________________________________________
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
Alan Buckley <alan_baa@hotmail.com> wrote:
> Ron wrote on Monday, January 13, 2014 11:39 AM:
> [snip]
> > But I have run aground with libxcb1 during python running through the
> > xml files. (at sync.xml)
> > I'm showing Python version 2.7.4 and the config output shows a check for
> > version >=2.6
> I don't seem to be able to build libxcb1 at all. I get the following errors:
> rman: couldn't read in referenced file man3/xcb_alloc_color_cells.3.
> Try cd'ing into ancestor directory that makes relative path valid
> first.
> make[3]: *** [install-man3] Error 1
> make[3]: Leaving directory `/home/alanb/build/libxcb1/libxcb-1.10/src'
> Did you need to do anything else to get it to build?
> > I'm not holding my breath on building the X stuff, I haven't ever
> > before, and there is probably a lot more problems after this one.
> I used to be able to build most of this, but it's been a long time
> since I've tried to do it all from scratch.
I've got a load of fixes for quite a few libraries to check in, libxcb1
being one of them. I just need to do a bit more testing. I'll try and check
in the changes Friday.
Chris.
_______________________________________________
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
Tuesday, 14 January 2014
Re: [gccsdk] Autobuilder libxcb1
In message <10c89ac953.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> In message <b8ce8dc953.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> >
> > I also have a python folder 2.7 folder with site-packages there, maybe I
> > could compare them with what I built on my 64bit laptop native Linux
> > build, or even copy the python generated stuff that's failing, I dont
> > know exactly what it is doing yet.
> >
>
>
> The same error I get his being encountered and dealt with here.
> https://bugs.gentoo.org/show_bug.cgi?id=491496
> so maybe those patches will help.
>
The existing xcb-proto already has this patch, it turned out that the
libxcb1 being downloaded was un unmatched version. Once I set the AB_URL
to the one from debian jesse (testing I think) all was well.
The man install quitted with a path problem but the library is built.
This has happened on another library also. Same sort of thing as Alan's
error.
desklib and libX11 have both built.
I am having trouble with libglib2.0-0 and libfii.so at the moment.
linker could not read symbols file in wrong format.
I think the building of libfii may need looking at. It is confusing
how libfii and libfii5 both build libfii.a
Thasnks, 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
Ron <beeb@woosh.co.nz> wrote:
> In message <b8ce8dc953.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> >
> > I also have a python folder 2.7 folder with site-packages there, maybe I
> > could compare them with what I built on my 64bit laptop native Linux
> > build, or even copy the python generated stuff that's failing, I dont
> > know exactly what it is doing yet.
> >
>
>
> The same error I get his being encountered and dealt with here.
> https://bugs.gentoo.org/show_bug.cgi?id=491496
> so maybe those patches will help.
>
The existing xcb-proto already has this patch, it turned out that the
libxcb1 being downloaded was un unmatched version. Once I set the AB_URL
to the one from debian jesse (testing I think) all was well.
The man install quitted with a path problem but the library is built.
This has happened on another library also. Same sort of thing as Alan's
error.
desklib and libX11 have both built.
I am having trouble with libglib2.0-0 and libfii.so at the moment.
linker could not read symbols file in wrong format.
I think the building of libfii may need looking at. It is confusing
how libfii and libfii5 both build libfii.a
Thasnks, 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)