PipeDream 4.50/34 32bit
David Pitt
http://downloads.abacusline.me.uk/
There is a minor snag on the Iyonix, it errors with :-
Error from (unknown): Filing system ADFS: must be given a filename
It does run OS4.39 VRPC. The catch seems to that
!PipeDream.Resource.ImageSlot escaped the update and remains 26bit.
This is probably a really wrong answer but these lines in !Run allow
the 32bit PD4 to run on the Iyonix :-
|
|Run PipeDream:ImageSlot <PipeDream$$ImageDir>.!RunImage 48K 32K
|
WimpSlot -min 784K -max 784K
Run <PipeDream$$ImageDir>.!RunImage %*0
PipeDream 4.50/34 should also be good for ARMv7 but though it makes it
to the iconbar it type=5's on loading a file.
Teething troubles to one side, a 32bit PipeDream is excellent news.
--
David Pitt
Stuart Swales
I had forgotten to update the ImageSlot used by PipeDream.
Your solution is just as good as using the util (till the app size changes!)
The one in Fireworkz is fully 32-bit. ;-)
Sad to hear that it doesn't load files on ARMv7... Hmm...
Cheers
Stuart
--
Stuart Swales
David Pitt
Stuart Swales <stuart.swale...@gmail.com> wrote:
> Thanks David,
> I had forgotten to update the ImageSlot used by PipeDream.
> Your solution is just as good as using the util (till the app size changes!)
> The one in Fireworkz is fully 32-bit. ;-)
Good thinking, that's that sorted.
> Sad to hear that it doesn't load files on ARMv7... Hmm...
Some diagnostics. This is what happens on opening !PipeDream's !Help
:-
23 Mar 12:40:49 000 00000001: Error from PipeDream: PipeDream has
suffered a serious internal error (type=5). Click OK to exit
immediately, losing data, CANCEL to attempt to resume execution.
*where
Address 000643DC is not in any module
*showregs
Register dump (stored at &2000ADD0) is:
R0 = 00001CF8 R1 = BC160C00 R2 = 00000000 R3 = 00000000
R4 = 000BBCDC R5 = 00000160 R6 = 000C7CEC R7 = 000BBCDC
R8 = 00000000 R9 = 000BBCDC R10 = 000C341C R11 = 000C7CE8
R12 = 000C16BC R13 = 000C7CDC R14 = 00000001 R15 = 000643DC
Mode USR32 flags set: nzcvqjgGGgEAift PSR = 00060310
*
It is the same with Alignment Exceptions On or Off.
Hmm...
--
David Pitt
Chris Johnson
That must be in PipeDream itself.
The offending instruction (at PC - 8) is once again a register load.
643D4 LDR R1, [R1, #4]
--
Chris Johnson
Stuart Swales
Can confirm that it's a bug - value that was loaded is wrong-endian so
stared at the code - there was a couple of residual PC^ that would stuff
up on new ARMs. New release being baked...
Stuart
--
Stuart Swales
Chris Johnson
Stuart Swales <stuart.swale...@gmail.com> wrote:
> stared at the code - there was a couple of residual PC^ that would
> stuff up on new ARMs
Does that imply the source is in assembler?
--
Chris Johnson
Colin Ferris
In version 4.50/35 there are a few residual mov*s pc,r14
&000A5490 MOVS PC,R14
&000A54B8 MOVS PC,R14
&000A5570 MOVVSS PC,R14
&000A5580 MOVVSS PC,R14
--
Colin Ferris Cornwall UK
Stuart Swales
RISC_OSLib (yuk!) that isn't 32-bit... Have just recompiled that
RISC_OSLib from its source and merged the offending objects with my own
(heavily butchered) partial RISC_OSLib.
Changed mu build process so that as a side effect it leaves behind an
AOF that I can DecAOF and spot the offending items more easily!
Expect more progress soon...
Stuart
> In version 4.50/35 there are a few residual mov*s pc,r14
>
> &000A5490 MOVS PC,R14
>
> &000A54B8 MOVS PC,R14
>
> &000A5570 MOVVSS PC,R14
>
> &000A5580 MOVVSS PC,R14
--
Stuart Swales
M Harding
> Expect more progress soon...
> Stuart
As the saying goes - for the uninitiated non-technical bod - "Wait
until SP3 comes out!"
Thanks for your work on my favourite all-purpose program, Stuart.
Michael Harding
Rev. Preb. M.D. Harding ris...@mdharding.org.uk