RO 5.20 upgrade for Iyonix
Chris Dewhurst (1709) 167 posts |
Hi ROOL, great news about the 5.20 release. Sorry to sound so thick but I’m assuming a 5.20 is available for the Iyonix too? ATM the download page is showing “5.18 Stable (flash prog) 2012-02-24 16:05:22” under the “Iyonix/Xscale” section thanks Chris. |
Chris Dewhurst (1709) 167 posts |
(Also Posted in Forums > General*) Just seen Chris Hall’s post under “RISC OS 5.20” ROM who asks the same question I have in Forums > Community Support. *Never been sure of the difference between the two forums (Community Support and General) Thanks. |
Chris Hall (132) 3558 posts |
I am getting a problem with 5.20 on the Iyonix. When I start !Publisher I am getting an abort on data transfer at &20207080 (which is in the module Aemulor (at 20207080-201fdf14=+916C) from AemulorPro 2.32 so it’s back to 5.16 again until this bug is resolved. |
Steve Revill (20) 1361 posts |
I think the best way to get that resolved is to contact Adrian Lees and see if he’s able to determine what’s going on in your setup. |
Colin Ferris (399) 1818 posts |
When that error occurs – what is the output – in a Taskwindow – of *showregs ? |
Chris Hall (132) 3558 posts |
The output in a taskwindow, the same whether I run !Publisher or !Publisher+ or !Style, is: (title bar Run ADFS::FastHard4.$.Impress+.!Publisher.!Run )
|
Chris Hall (132) 3558 posts |
I think the best way to get that resolved is to contact Adrian Lees and see if he’s able to determine what’s going on in your setup. Unfortunately the e-mail address for Adrian Lees and for Neil Spellings both bounce. |
Chris Johnson (125) 825 posts |
The problem with Aemulor on Iyonix (on 5.19 before 5.21) has been known for several months. I started a topic on Nov 27th 2012 in this forum. http://www.riscosopen.org/forum/forums/11/topics/1536 There have also been a number of persons posting on usenet about this problem. For my infrequent uses of Aemulor, I now use the ARMini, which I think still works. |
Colin Ferris (399) 1818 posts |
Have you tried Adrian Lees (Apr 22 2013) suggestion and try ‘ARM610’ mode instead of |
Chris Johnson (125) 825 posts |
Yes, and it still crashes – I have just tried again. Edit: I have also now tried ARM3 mode (most compatible) and the crash is the same. |
Colin Ferris (399) 1818 posts |
Has anyone a collection of the first/older versions of RO 5.19 – for the Iyonix? To try and see when the problem came about with Aemulor. |
Steve Pampling (1551) 8172 posts |
TungstenDev.5.19-2012-10-08.zip to TungstenDev.5.19-2013-07-01.zip1 2 but I don’t have the Iyonix in a useable state or a copy of Aemulor for Iyonix. I think the first time anyone complained about Aemulor problems was around the time the page zero protection work happened – co-incidence? If that date can be identified it gives a narrow set of ROMS to test against. 1 Squirrel genetics or just sad |
Chris Johnson (125) 825 posts |
I am quite happy to try a few tests. It obviously occurred prior to Nov 27th 2012, which was when I first noticed it. I only randomly keep about five or so versions I actually used without problem so my earliest is March this year. I could initially try 2012-10-08 and if that works, some intermediate ones later. My email is chris at chrisjohnson dot plus dot com. |
Fred Graute (114) 645 posts |
The change that stops Aemulor from working seems to have occured between 20-02-2012 and 29-04-2012. If anyone still has a copy of 5.19 from that period then we may be able to narrow it down further. |
Jeffrey Lee (213) 6048 posts |
Listings from *ROMModules would be useful, so that we know what changes to look for in CVS. |
Kevin Corney (454) 41 posts |
Unfortunately, this may not be the case, since Aemulor has also stopped working on my Iyonix with 5.18. Could it therefore be something to do with a change in the boot structure, rather than the ROM? |
Chris Evans (457) 1614 posts |
First version of my posting deleted as posts today which I hadn’t seen negate it!
In what way has Aemulor stopped working? Are you using a 5.18 disc Image? Something must have changed to cause it to stop working I doubt being a later time/date is it. |
Chris Johnson (125) 825 posts |
No, that isn’t true. All the 26-bit apps I have tried, including Impression, Publisher+, Eureka all fail. I never got a single 26-bit app to run once the problem occurred. |
Kevin Corney (454) 41 posts |
Same here – Style, Publisher+, Eureka, Tablemate, DiagramIt, 26-bit Pipedream all fail. |
Kevin Corney (454) 41 posts |
Keeps giving error messages to say that Such-and-Such program needs Such-and-Such module (Can’t be more specific at the mo – can’t get to the Iyonix). Using Aemulor Pro 232 with 5.18 in flash ROM – same as I always have since 5.18 was produced. Hence my questioning the Boot changes. |
Chris Hall (132) 3558 posts |
Aemulor Pro 2.32 works for me under 5.18 on Iyonix. Aemulor Pro 2.32 fails under 5.20 on Iyonix at the samepoint in the code each time (where all the registers are zero) with an abort on data transfer at 916C and the instruction (at +916C) is: 9160 MOVEQ PC,#0 Perhaps someone can make sense of this? Does pipelining mean that the abort is actually at 916C-8 where it tries to load R4 from address 4 (as R2=0 at this point)? Zero page protection (added after 5.18) might therefore be causing this to abort. |
Fred Graute (114) 645 posts |
Here’s the output of *ROMModules for the 20-02-2012 and 29-04-2012 versions of 5.19. The module list is exactly the same apart from the addition of UnSqueezeAIF in the later version. I’ve marked the modules that have different version numbers with an asterisk.
|
Fred Graute (114) 645 posts |
Did you use *ShowRegs to get the registers? Normally when an abort occurs the registers are written to the exception area and can be read using *ShowRegs but this doesn’t always happen. To test this I invoked the abort, reloaded Aemulor then changed the instruction at the abort offset (+&4494 in my case) to &FFFFFFFF (an undefined instruction). Then I tried to run something under Aemulor again, now it hits the undefined instruction and takes the Undefined trap. Doing a *ShowRegs after this shows the registers are not all 0 – they did show as zero after the actual abort. This suggests that the actual abort doesn’t cause the registers to be written to the exception area. |
Chris Hall (132) 3558 posts |
Did you use *ShowRegs to get the registers? Yes. On my Iyonix, with Aemulor Pro 2.32 and RISC OS 5.20 (10-Jun-2013) I get an abort at +916C as the !Run file for Impression is being executed. Every time without fail, same address. On my ARMini (BBXM) with Aemulor Pro 2.33 and RISC OS 5.20 (10-Jun-2013) it all works fine. On my Pi with RC11, Aemulor Pro 2.34 and RISC OS 5.21 (15-Jul-2013) it all works fine. These are all the latest versions for the various platforms. It’s the one I paid most for (£80) that is the one that isn’t working. |
Colin Ferris (399) 1818 posts |
I suppose one option is to start loading the later modules on the earlier version of RO 5.19 – and then run Aemulor – and see if any of the modules causes the problem. Another option is to make a branch to end of module – instead of ldr r4,[r2],#4 - Looking at the previous instruction – moveq pc,#0 – perhaps this is some kind of error code. Would the author be prepared for someone else to look at his code – if he is not able – for whatever reason? |