Question for Adrian Lees
David Feugey (2125) 2709 posts |
I saw this a long time ago: http://support.spellings.net/viewtopic.php?t=492
But there are two problems: it seems to be impossible to register to the forum and your mail is not present anymore on your website. Aemulor is a cool product, but sometimes a bit experimental with software made ‘the bad way’. Could I suggest a less integrated emulator for things like games or complex software (or even, whole OS 4 emulation)? A complete emulator, or a pluggable JIT engine (but separate, for licenses issues) for RPCEmu (needs a port of RPCEmu). Of course, it could be possible to make people pay for the fastest engine. Thanks. |
Chris Evans (457) 1614 posts |
When I spoke to Adrian at the London show last year he was planning on taking some time out from work and Computers (mainly on health grounds). Six months was mentioned. When he talked of returning he doubted he would be doing anything RISC OS related. |
David Feugey (2125) 2709 posts |
I hope the code will not be lost… |
Bryan Hogan (339) 592 posts |
Sounds like you either want the full emulation of ArcEm, or the ARM emulation stuff in ADFFS. |
Chris Evans (457) 1614 posts |
I doubt that will happen. Declining to commit to new RISC OS software is rather different to leaving the scene and slashing and burning behind you. |
David Feugey (2125) 2709 posts |
Cool…
Perhaps both :) |
Adrian Lees (1349) 122 posts |
HI, Aemulor Pro includes a lot of support for even ‘bad’ (I’d rather call them ‘short-cut’ or ‘direct’) programming techniques, at least on the IYONIX pc, for which it was written. For later hardware, it does not cope so well, relying upon the native hardware to provide the same level of backwards compatibility as the IYONIX pc did. Recent releases of RISC OS have reduced Aemulor Pro’s level of compatibility, because – AIUI – changes for dual-screen support on new hardware were not backwards compatible with ‘documented’ APIs, although this has been discussed briefly, and compatibility (and thus Aemulor(Pro)’s ability to provide lower-depth screen modes) restored in latest, unreleased builds. Aemulor’s engine could certainly be used to build an ARM-on-ARM machine-level emulator that outruns the current offerings by a good margin, which has been apparent for a long time, but it is sadly not a small amount of work, nor would it be easy for another developer to take the core and drop it into their machine-level emulator, should I – bizarrely? – choose to open source what is my proudest creation….and I include there all of the work that I have ever done, commercial and not. A PS. The preceding post on the dev forums gives my current email address, although I am naturally reticent about publishing it since it is my personal email address, and not directly related to development, RISC OS-related or otherwise. |
Chris Evans (457) 1614 posts |
Hi, Adrian. n.b. Adrian wrote up details about how Aemulor works, some years ago, copies are at: |
David Feugey (2125) 2709 posts |
Hi Adrian. Glad to see your message. Now that I have an iyonix, I’ll soon register for aemulor pro. I hope that releases will continue to follow the development of RISC OS. I plan to make a big list of all software that runs on the different versions of aemulor (Pi, iyonix, Panda, Beagle). Nota: I’m also an active user of Geminus. With a dual screen config. I noticed redraw bugs with the latest beta version of StrongED (when you resize a window). Not sure it’s really related to Geminus. Last point; Is there a way to ask Geminus to cache some elements (a sort of framebuffer dedicated to an application)? It could be very usefull to speed up some complex wimp applications (games, emulators, etc.). Thanks again. Bye. |
Fred Graute (114) 645 posts |
Try turning off Geminus’ redraw caching for StrongED, I remember this causing some problems in the past. What version of StrongED are you using? There is no beta release at present, only 4.69f6 (stable) and 4.70a4 (alpha). |
Adrian Lees (1349) 122 posts |
I can check it out, but StrongED’s redraw is so fast that it’s just a waste to use the limited cache memory upon it. As Fred says, disable it, using the per-application settings in the Geminus configuration. It was always intended – perhaps I’ll get to it ;) – that Geminus should measure the redraw speed and prioritise cache usage accordingly, with disabling of cacheing being required only for compatibility, since it sits between the application and the OS without ‘declaring its existence.’ |
David Feugey (2125) 2709 posts |
Damn. It was a redraw bug in StrongED. I have much less problems with the alpha version… On the Geminus front, RISC OS is now able to manage 1920×1080 screen, but not geminus (I use 2048 × 1080). No solution for this problem? |
Adrian Lees (1349) 122 posts |
Not with current code, I’m afraid. It’s theoretically possible, if the NVidia module behaves, but I’ve never managed to make it work. Sorry |
David Feugey (2125) 2709 posts |
No problem: that’s not a big problem :) |
David Feugey (2125) 2709 posts |
I fixed almost all my problems (not the StrongED one). I remember you were asking for suggestions some time ago for possible evolutions of aemulor. I have one: iemulor. Compatibility for old 32bits applications with new hardware (iyonix > rpi, beagle, panda). It would be very usefull. Nota: I have some problems with games that use specific modes under aemulor. Two screens for some, even four for Syndicate. The game works but is not usable. That is sad since good game emulation (with an official list) would be great for sales of aemulor :) Heroes of Might and Magic II works great! Dune worked only one time for me. |