Adrian's website has a link to http://www.aemulor.com/, which is recently registered.

I wonder how things are coming on with this.

I'd be a paying customer, especially if it'd allow playing old Acorn games on the Pandora.

I wouldn't get your hopes up; to me it looks like the domain has simply expired and been snapped up by a squatter.

I'd say that a polished/optimised version of ArcEm is a much better thing to pin your hopes on.

"[...] Aemulor in due course."

Fantastic news. This is the missing thing that keeps me and some others to move to the BeagleBoard or some other new hardware.
Herbert

The ARM core in the Rasberry Pi I think uses a different ARM core.

I think it is best not to speculate too much either way on this at this stage. Any comments *must* come from Adrian, and he (understandbly) keeps a low profile.

I hate to sound negative but I feel that Aemulor has done more harm than good for the 32 bit market. The fact that it exists means that developers haven't bothered to produce 32bit compatible apps.

I don't want to make any further comments/commitments just yet, but I should correct one point....Aemulor can be made to work on both processors (the screenshot at the top of this thread shows that, and it in fact started life on a StrongARM RiscPC), but it uses features of the XScale hardware to gain a substantial speed increase.

Both the Cortex-A8 (ARMini/BeagleBoard) and the ARM1136 (RaspberryPi) have comparable but different debug hardware. It's worth noting that the A9home version of Aemulor only offers the slower 'ARM610 mode' because there is no suitable debug hardware for it to exploit.

... It's worth noting that the A9home version of Aemulor only offers the slower 'ARM610 mode' because...

Does that mean Aemulor on the A9home will run software not StrongARM compatible?
Or am I reading too much into 'ARM610 mode'?

If it makes heavy use of code modification, however, it's less likely to work, and may require use of the 'ARM3 mode' which is slower still but more capable of coping with such nastiness

If it makes heavy use of code modification, however, it's less likely to work, and may require use of the 'ARM3 mode' which is slower still but more capable of coping with such nastiness

To be fair, the ARM3 processor wasn't exactly known for its speed. If Aemulor runs faster than an ARM3 does (bearing in mind this is on an ARM9, never mind an XScale or OMAP), technically it's already more than fast enough!

Martin I don't understand. You seem to say ARM3 is slow "ARM3 wasn't known for its speed."

Martin I don't understand. You seem to say ARM3 is slow "ARM3 wasn't known for its speed."

As I'm sure you're aware, the ARM3 came out 20 years ago. It was clocked at 25MHz. The OMAP3530, on which a future version of Aemulor will likely be running, is clocked at 720MHz. That's a heck of a lot of spare cycles to get lost in the emulation overhead.

If the aim is to run software written for the ARM3, then it is safe to assume that software was written for a much slower processor than the one it finds itself running on, and (particularly in the case of games) will likely be unusably fast. Your Mandelbrot program was also written 20 years ago, and no matter how fast it may have seemed running on the technology of the day, chips these days are much, much faster. If Aemulor achieves an emulated clock rate of greater than 25MHz, it's already more than fast enough. Clear?