Eureka

You cannot post here, but its included for searching historical issues

Moderators: aemulor, admin

Locked
tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Eureka

Post by tonystill » Sat Jun 14, 2003 6:32 pm

I have significant problems with Eureka that seem worse than those listed elsewhere, to the extent that it is not usable (which is a shame 'cos that's why I bought Aemulor :( ).

I have Eureka 3.05 running on Aemulor 2.10 and RO5.03.

I have cosmetic problems in that all the window controls are red/purple rather than grey. However, the big problems are with freezes of the machine (recoverable via ALT-Break) when I try to:
Show the Save as submenu
Show some other submenus (sometimes)
Show the Print dialogue box (sometimes)
Show the Palette dialogue box.

All these faults manifest themselves on a new blank sheet after starting Eureka so I've not tried to do anything real with it, the lost work is just going to be too frustrating. So it's back to the RPC...

Any ideas?

Tony

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Sat Jun 14, 2003 10:13 pm

It sounds as though you're using the StrongARM engine... Eureka only works properly with the ARM610 engine because it loads sections of its code from disk when needed (a technique called overlays). The previously-loaded code is still cached by Aemulor and gets executed instead.

If the problems still occur with the ARM610 engine then let me know.

Re. the funny colours, I don't think this is a problem in Aemulor itself, but rather a change in the toolsprites introduced with RISC SO 5.01 (if memory serves)... I'll see what I can find out, but it isn't top of the priority list, obviously.

Adrian

tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Post by tonystill » Sun Jun 15, 2003 8:39 pm

I was indeed using the StrongARM engine and the results are better under the 610 engine (though lots slower). Strange because Eureka works on a real StrongARM, overlays and all.

However, the tool colours issue persists (Eureka, for reasons best known to itself, contains a complete set of window sprites in each of three sets. This may be because of its clever window panes system?).

Also, having been disturbed and left Eureka idling, the screen saver cut in (ScrBounce), reduced the screen to 'bounce' size and then the machine froze. Froze as in reset button does not work, only recovery through the master switch on the back. That's a first for me :(

Tony

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Sun Jun 15, 2003 10:59 pm

OK... that's all as I expect, except for the screensaver problem... I assume it works without Eureka running?! I don't have a screensaver set up; where can I get/find ScrBounce?

The reason that some code happens to work on a real StrongARM and not under Aemulor, or vice-versa is that each has a /finite/ cache... so the old code (that's been replaced by the loaded code) can just 'fall out' of the cache even though Eureka hasn't specifically said "please throw away the old code from address A to address B". Aemulor doesn't exactly model the SA's cache, hence the differenct behaviour.

I may be able to speed up Eureka/handle the use of overlays with the SA engine somehow....but our first priority is obviously to get things working at all!

Adrian

tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Post by tonystill » Mon Jun 16, 2003 8:16 pm

Screensaver does work without Aemulor. It's standard (accessed via Configure->screen, arrived in RO5.02, I think, but used here in RO5.03).

I assumed that the StrongARM update interacted with the overlay control to flush the code cache when an overlay was paged in (isn't it all in CLib? Surely it would just crash on a real SA without a cache flush). Can you not use the cache flush SWI to also flush Aemulor's cache? (Or am I talking rubbish - perhaps I'll research overlays).

Tony

tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Post by tonystill » Tue Jun 17, 2003 9:43 pm

OK - I can shed some light on the overlay issue:

Overlays are controlled by the overlay manager which is *not* in CLib (though it is in ANSILib). A CLib-using application must be explicitly linked with it.

The current version of the Overlay manager does indeed contain a call to OS_SynchroniseCodeAreas. I haven't checked when it's used but I think we can guess :) .

However, Eureka was compiled before StrongARM so it can't have this SWI in it. So it can't work on SA, yet it does. And that's the problem! When StrongARM was introduced, RO3.7 included the AppPatcher (which is still there in RO4.02). The AppPatcher recognises a number of problem sequences and patches them on the fly.

One of the problems it recognises is the Overlay manager. And lo, when you load Eureka on a RO4.02 machine, *PatchStats reports that it's just patched the Overlay manager. But the AppPatcher is missing from RO5... (and goodness knows how it would interact with Aemulor). So Eureka never gets patched to flush the code cache, so (at a guess) Aemulor heads for the hills.

Any chance of adding the AppPatcher functionality to Aemulor; or running the RO3.7/4 module under Aemulor?

Interestingly, my Easiwriter v7.11 (that I believe is the latest 26-bit version) also gets patched for Overlays. So I predict that would fail too. I have the 32-bit upgrade so haven't actually tried it.

Hope all this helps.
Tony

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Wed Jun 18, 2003 12:42 am

Very interesting.... thank you so much for your investigations. Aemulor does already trap the OS_SynchroniseCodeAreas SWI as you suggested, but doesn't implement the AppPatcher functionality.

I confess I'd only analysed the executable image of Eureka after unsqueezing, and totally overlooked patching - I knew of AppPatcher's existence (and the service call etc), but I'd never actually seen anything reported by *PatchStats (obviously never issued it after running Eureka!) so what I was looking at is not what's actually been running on the RO4/StrongARM... ooops! :oops: Should have studied a memory dump.

Anyway, I'll find out exactly what AppPatcher does, and/or whether we can just run that module under Aemulor.... it won't work at present, sadly, because Aemulor doesn't issue the appropriate service call.... it's on the 'to be looked at' list!

Thanks,

Adrian

tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Post by tonystill » Wed Jun 18, 2003 9:24 pm

Thanks Adrian - I'll try to be patient.

Tony

Locked