| |
Aemulor |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Adrian Lees |
Message #124146, posted by adrianl at 17:16, 5/9/2017 |
Member
Posts: 1637
|
Hi all, a quick note to say that we are no longer selling Aemulor as a commercial product because I want, in time, to make it available as a free download with more frequent - albeit less well-tested - updates in response to OS changes and the backwards-compatibility issues that result. On account of the day job, I have not always been the most responsive in releasing updates to accommodate OS and platform changes, and I don't want users refraining from upgrading and updating for fear of being of being unable to run their old software (you know who you are, Impression!)
So, in the near future I shall make available the latest stable, released builds for all platforms, accompanied by the latest beta with any compatibility fixes and improvements that are not yet proven. I shall post a URL at that point.
Thanks to Spellings for publishing and supporting Aemulor for all these years, it remains my proudest creation, and to TIB and the RISC OS community for being around for so long.
Best wishes to all,
A |
| |
 [ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #124147, posted by arawnsley at 20:50, 5/9/2017, in reply to message #124146 |
R-Comp chap
Posts: 600
|
Thanks Adrian - that sounds brilliant. The software has been instrumental in allowing people to enjoy modern hardware without fear of losing the older software, which still accounts for the bulk volume of RISC OS applications.
Whilst we may champion and recommend actively developed, modern software, the fact remains that there were many, excellent applications released in the 26bit era that do specific jobs and have never been replaced/reproduced/surplanted in what they do. For all those, there's Aemulor, THANK GOODNESS 
Thanks again for all you do, as I know it has helped hundreds, maybe thousands of RISC OS users over the years. I can safely say that without Aemulor, there'd be a LOT of current users who would have left the scene because their favourite applications were no longer viable.
[Edited by arawnsley at 21:51, 5/9/2017] |
| |
[ Log in to reply ] |
| |
|
David Feugey |
Message #124148, posted by dfeugey at 15:44, 9/9/2017, in reply to message #124147 |
Member
Posts: 40
|
That's a fantastic news. I plan to do a page about software that can be used under RISC OS with the help of Aemulor. A good way to get more software for our platform. |
| |
[ Log in to reply ] |
| |
|
David Feugey |
Message #124150, posted by dfeugey at 11:22, 11/9/2017, in reply to message #124148 |
Member
Posts: 40
|
Can I suggest a 32bit mode? More and more software made for the Iyonix simply do not work any more on ARMv7 or ARMv8 hardware. A lot will work under Aemulor. Perhaps Aemulor could treat them a different (and more efficient) way ? |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124160, posted by adrianl at 12:37, 18/9/2017, in reply to message #124150 |
Member
Posts: 1637
|
Can I suggest a 32bit mode? More and more software made for the Iyonix simply do not work any more on ARMv7 or ARMv8 hardware. A lot will work under Aemulor. Perhaps Aemulor could treat them a different (and more efficient) way ? With Aemulor on post-ARMv5 hardware there really isn't much more that can be done to increase the speed of 32-bit applications running under Aemulor without perhaps all of the work involved in building a new emulation engine, which I'm afraid just isn't feasible for free software being maintained whilst I have a day job. I have some experimental code for that alternative approach, but it frankly just doesn't work right now, so please don't expect it to materialise.
Energies would probably be better expended badgering the application authors to update their software. |
| |
[ Log in to reply ] |
| |
|
David Feugey |
Message #124161, posted by dfeugey at 06:27, 19/9/2017, in reply to message #124160 |
Member
Posts: 40
|
It's OK for me Anyway, I plan also to test Aemulor compatibility for 32bit software not compatible with post ARMv5 hardware. Since I have a Pi3, speed is here, but I miss Aemulor. A lot. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124162, posted by adrianl at 22:11, 19/9/2017, in reply to message #124161 |
Member
Posts: 1637
|
It's OK for me Anyway, I plan also to test Aemulor compatibility for 32bit software not compatible with post ARMv5 hardware. Since I have a Pi3, speed is here, but I miss Aemulor. A lot. I have a Pi3 too, although sadly it has only been used for the day job thus far, although ARMv8 compatibility is obviously high on my ToDo list for Aemulor. |
| |
[ Log in to reply ] |
| |
|
Tomasz Konojacki |
Message #124174, posted by xenu at 07:24, 3/10/2017, in reply to message #124146 |
Member
Posts: 2
|
Thank you a lot for all your work!
Will the next release be Zero Pain compatible?
[Edited by xenu at 11:48, 3/10/2017] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124184, posted by adrianl at 09:52, 13/10/2017, in reply to message #124174 |
Member
Posts: 1637
|
Will the next release be Zero Pain compatible? The latest development builds of Aemulor are fine with the zero page protection, and - necessarily - provide alternative mechanisms for 26-bit application code still to act as if it were not present. First I need to round up the latest released versions and make those available; it will then be up to individuals to decide whether the ZPP-aware dev builds are preferable for them when I upload those.
There are other OS changes on at least some platforms that are not backwards-compatible at the level at which Aemulor must, in places, operate, so there may be yet other issues. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124206, posted by adrianl at 12:06, 14/11/2017, in reply to message #124184 |
Member
Posts: 1637
|
Right, They should all be here.
Latest version of Aemulor for all RISC OS machines, and it should work on either 'ZPP' or 'non-ZPP' OS builds, although do please note that even if I had all machines and all OS builds (which I don't!) it would not really be practical for me to test all combinations.
If you find any problems let me know, or try the older releases (for Cortex-A8/9/15 machines) also available via that page. |
| |
[ Log in to reply ] |
| |
|
Steffen Huber |
Message #124207, posted by hubersn at 23:36, 14/11/2017, in reply to message #124206 |
Member
Posts: 91
|
Right, They should all be here.
Latest version of Aemulor for all RISC OS machines, and it should work on either 'ZPP' or 'non-ZPP' OS builds, although do please note that even if I had all machines and all OS builds (which I don't!) it would not really be practical for me to test all combinations.
If you find any problems let me know, or try the older releases (for Cortex-A8/9/15 machines) also available via that page. Many thanks for your efforts!
What is the platform you are referring to that you don't have yourself? I could start with testing on that platform.
I also note the absence of the A9home version. Not that I know of anyone who would need it... |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124208, posted by adrianl at 00:15, 15/11/2017, in reply to message #124207 |
Member
Posts: 1637
|
What is the platform you are referring to that you don't have yourself? I could start with testing on that platform. I don't personally have a Cortex-A15 machine (Titanium, RapidO, TiMachine, IGEPv5) just yet, and tend to rely upon Andrew@R-Comp and Chris@CJE for testing that build.
I also note the absence of the A9home version. Not that I know of anyone who would need it... Yes, theoretically the code still supports it, and I do have an A9home, but I haven't built/tested the code for that code in years and I decided to omit it for simplicity. I'll add a note to the website to that effect, should anyone really want a copy. It was never feature-complete on the A9home due to the rather immature nature of the OS port.
Although, you have just reminded me that Aemulor can be built for RPCEmu too, and used on that to run 26-bit applications on emulated 32-bit machines, so I need to get that uploaded too...
I rather fancy producing a version for the MicroDigital Omega.... 
[Edited by adrianl at 00:16, 15/11/2017] |
| |
[ Log in to reply ] |
| |
|
Steffen Huber |
Message #124209, posted by hubersn at 23:37, 15/11/2017, in reply to message #124208 |
Member
Posts: 91
|
Although, you have just reminded me that Aemulor can be built for RPCEmu too, and used on that to run 26-bit applications on emulated 32-bit machines, so I need to get that uploaded too...
Good idea! You once had a rough port of RPCEmu running on RISC OS 5, did you ever get around "polishing" it for release?
I rather fancy producing a version for the MicroDigital Omega....
Does RISC OS 5 even run on it? In theory, it faithfully emulated an IOMD machine, but ISTR that back then RISC OS 4 needed quite a few changes to run properly...and then there is the "bootstrap" problem having 26bit filing system modules that won't run on RISC OS 5... |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124211, posted by adrianl at 14:18, 18/11/2017, in reply to message #124209 |
Member
Posts: 1637
|
Good idea! You once had a rough port of RPCEmu running on RISC OS 5, did you ever get around "polishing" it for release? That was a curiosity really. It'd be useful as a development tool to have a machine emulator, because developing and debugging system/low-level code on RISC OS is very hard.
I rather fancy producing a version for the MicroDigital Omega....
Does RISC OS 5 even run on it?...
I doubt it. I still don't see how it was ever supposed to run 26-bit software, that's all.
[Edited by adrianl at 14:18, 18/11/2017] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124212, posted by Phlamethrower at 18:45, 18/11/2017, in reply to message #124211 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Good idea! You once had a rough port of RPCEmu running on RISC OS 5, did you ever get around "polishing" it for release? That was a curiosity really. It'd be useful as a development tool to have a machine emulator, because developing and debugging system/low-level code on RISC OS is very hard.
FWIW, there's a new port of RPCEmu to RISC OS, mostly thanks to RPCEmu migrating from Allegro to Qt (and there being a pre-existing RISC OS port of Qt). Lots of polish & optimisation required, but the sources are available.
https://www.riscosopen.org/forum/forums/10/topics/9593 |
| |
[ Log in to reply ] |
| |
|
David Boddie |
Message #124213, posted by davidb at 23:06, 18/11/2017, in reply to message #124212 |
Member
Posts: 147
|
FWIW, there's a new port of RPCEmu to RISC OS, mostly thanks to RPCEmu migrating from Allegro to Qt (and there being a pre-existing RISC OS port of Qt). Lots of polish & optimisation required, but the sources are available.
https://www.riscosopen.org/forum/forums/10/topics/9593 I hadn't seen that they'd migrated to Qt - interesting. And the sources are now in a Mercurial repository so it's good news all round. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124506, posted by adrianl at 01:56, 9/7/2019, in reply to message #124208 |
Member
Posts: 1637
|
I don't personally have a Cortex-A15 machine (Titanium, RapidO, TiMachine, IGEPv5) just yet... Tick tock, tick tock, time passes....and many users are still dependent upon emulation/compatibility layer for running their favourite applications sadly.
Anyway, I do now have a Titanium, as well as RPi4 for when RISC OS becomes available on that. I'm currently engaged in ensuring that Aemulor works on the ARMbook laptop. It's up and running desktop applications such as Publisher, but only with some hardware emulation in Aemulor disabled; functionality that is not required for well-behaved desktop applications anyway.
Which set me thinking; Aemulor was originally written with the aim of maximum compatibility with RISC OS 4 systems, games and very low-level software included. These days it's more appropriate to use a full-machine emulation for anything that requires that level of fidelity, and most Aemulor usage is desktop only - correct me if I'm wrong - so.... I can drop some I/O emulation, reduce the footprint of some 26-bit dynamic areas and shuffle the addresses up, giving a 52MiB slot limit rather than 28MiB slot whilst Aemulor is running.
I presume that'd be helpful to people? My intention is to make it a configuration option that you'll have to set before (re)starting Aemulor. Thoughts? |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #124507, posted by arawnsley at 09:20, 9/7/2019, in reply to message #124506 |
R-Comp chap
Posts: 600
|
It'd definitely help, not least because a 4k desktop wallpaper in a 16M colour mode can exceed 28MB (probably needs 32).
I'd be tempted to even make it the default behaviour, with more rigorous emulation available as an option (much like you presently offer older system emulation as an option.
The less of an impact it can make to a system in terms of "downsides", the better
That being said, it'd be helpful to know more about what aspects of emulation are being disabled, and what's affected.
The only non-desktop thing I use with Aemulor is Heroes of Might and Magic 2 - 640x480 SA/RPC game However, others may use it for other games etc, so we don't want to completly bork them.
Conversely, most of the games-related stuff seems to happen via !ADFFS which seems mostly Pi-targetted, esp with AnyMode.
PS, whilst anymode is cool, I'd still love to see RISC OS gain a general module which does scaling and colour depth emulation to allow any lower-res things to run in the current resolution/colour-depth without forcing mode change. Would be very convenient for the OS to gain something like that, even with a modest performance hit.
[Edited by arawnsley at 10:22, 9/7/2019] |
| |
[ Log in to reply ] |
| |
|
RISCOS Bits |
Message #124511, posted by riscosbits at 18:37, 9/7/2019, in reply to message #124506 |
Member
Posts: 31
|
Anyway, I do now have a Titanium, as well as RPi4 for when RISC OS becomes available on that. I wonder if both of these, with their dual screen capabilities, give rise to a resurrection of the screen configuration options from one of your other apps, Geminus? |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124512, posted by adrianl at 20:32, 9/7/2019, in reply to message #124511 |
Member
Posts: 1637
|
Anyway, I do now have a Titanium, as well as RPi4 for when RISC OS becomes available on that. I wonder if both of these, with their dual screen capabilities, give rise to a resurrection of the screen configuration options from one of your other apps, Geminus?
It hasn't escaped my attention. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124513, posted by adrianl at 20:54, 9/7/2019, in reply to message #124507 |
Member
Posts: 1637
|
I'd be tempted to even make it the default behaviour, with more rigorous emulation available as an option (much like you presently offer older system emulation as an option. It does have to be an option that affects the entire system from Aemulor startup to Aemulor shutdown. To be clear, it can't be per-application sadly. The reason is that Aemulor doesn't emulate applications, it emulates all 26-bit code which includes modules etc and they need to run and be informed of things (mostly via service calls) whether it's a 32-bit or a 26-bit application that happens to be mapped in.
That being said, it'd be helpful to know more about what aspects of emulation are being disabled, and what's affected. Compatibility with some old software may be impacted just by changing the address map. Further, removing the emulation of IOMD/VIDC20 could break games that directly access it. Removing the OS image (I currently map the real ROM image at &3800000 also to keep old software happy) may break other stuff, although I only know of DeskEdit depending upon this.
The only non-desktop thing I use with Aemulor is Heroes of Might and Magic 2 - 640x480 SA/RPC game However, others may use it for other games etc, so we don't want to completly bork them. Well, I have no intention of removing the existing functionality. I have a prototype build that uses the higher addresses and allows 52MiB for applications (wouldn't have posted if I didn't know it can work ). I guess we can refine over time what the modified behaviour shall be when configured; Andrew, I'll send you a beta to play with soon.
PS, whilst anymode is cool, I'd still love to see RISC OS gain a general module which does scaling and colour depth emulation to allow any lower-res things to run in the current resolution/colour-depth without forcing mode change. Would be very convenient for the OS to gain something like that, even with a modest performance hit. It'd certainly be handy. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #124515, posted by arawnsley at 10:08, 11/7/2019, in reply to message #124513 |
R-Comp chap
Posts: 600
|
Yes, I understand that'd have to be a global setting. I was just contemplating on whether it might be a better default, as the lower system impact (ie. more available wimpslot) would definitely be a desireable default for me personally. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124518, posted by adrianl at 02:23, 7/8/2019, in reply to message #124515 |
Member
Posts: 1637
|
If anybody would like to help beta test Aemulor with 52MiB WimpSlot changes and/or on ARMbook, to check whether I've broken their favourite app(s), please get in touch (see bottom of ReadMe from 2.40 archive).
The new version seems to be fine, but it isn't practical for me to test everything on all targets. I can test Impression and a few common apps myself, but if you rely upon something more obscure it'd be helpful to find out if there are problems before I upload a new build for all targets, which should be by mid-August.
Thanks. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124557, posted by adrianl at 03:46, 8/9/2019, in reply to message #124518 |
Member
Posts: 1637
|
Aemulor site updated to offer version 2.51 builds with the configurable switch between 28MiB and 52MiB limits for all targets. Previous builds are still available on the site because I cannot feasibly test all builds. Cheers. |
| |
[ Log in to reply ] |
| |
|
Fred Bambrough |
Message #124558, posted by freder at 15:57, 8/9/2019, in reply to message #124557 |
Member
Posts: 11
|
Both AemulorAx and AemulorA8_9 generate an 'Overlapping areas' error on my BeagleBoard -xM with latest (31 Aug 19) ROM. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124559, posted by adrianl at 19:02, 9/9/2019, in reply to message #124558 |
Member
Posts: 1637
|
Both AemulorAx and AemulorA8_9 generate an 'Overlapping areas' error on my BeagleBoard -xM with latest (31 Aug 19) ROM. Did you have a copy of Aemulor running when you tried to load the new one? The "Overlapping areas" error can mean that it's unable to create dynamic areas which it needs at the addresses below 64MiB. To do that it needs to patch the ROM image in memory.
Have you any version of Aemulor which works on your machine, because that code hasn't changed? |
| |
[ Log in to reply ] |
| |
|
Fred Bambrough |
Message #124560, posted by freder at 21:07, 9/9/2019, in reply to message #124559 |
Member
Posts: 11
|
Did you have a copy of Aemulor running when you tried to load the new one? No. I don't normally have Aemulor running at all. Just trying it on seeing your announcement. So fresh. Clicking on !Aemulor in Apps also generates the error.
Have you any version of Aemulor which works on your machine, because that code hasn't changed? No. AemulorAx used to work many moons and ROMs ago when I last tried it. |
| |
[ Log in to reply ] |
| |
|
David Pitt |
Message #124561, posted by pittdj at 10:02, 10/9/2019, in reply to message #124558 |
Member
Posts: 5
|
I see the same on the Titanium. The last ROM that Aemulor 2.51 works with is 11-Aug-19.
It might be worth asking on the ROOL forum to get a clue as to what might be the cause.
https://www.riscosopen.org/forum/forums/11/topics/14734
[Edited by pittdj at 11:20, 10/9/2019]
HTH.
[Edited by pittdj at 11:21, 10/9/2019] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124563, posted by adrianl at 01:07, 11/9/2019, in reply to message #124561 |
Member
Posts: 1637
|
Technical explanation posted to that page; to be confirmed and resolved shortly. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124575, posted by adrianl at 03:54, 26/9/2019, in reply to message #124561 |
Member
Posts: 1637
|
Version 2.52 is on the site. This should resolve the immediate patching problem and use the new OS_DynamicArea reason code (26, satisfyingly) that should prevent a recurrence of this issue in future versions.
Also, if for some reason Aemulor still cannot patch the ROM image as required, it will explicitly report that fact along with a number rather than "Overlapping areas."
There's also an important compatibility fix for people using 26-bit Impression on Titanium or ARMbook targets especially, but for anyone using 32-bit support modules GDraw, FontDraw, DitherExtend and GSpriteExtend.
[Edited by adrianl at 04:56, 26/9/2019] |
| |
[ Log in to reply ] |
| |
| Pages (2): 1
> >|
|
