Aemulor.com

User interface changes

Aemulor UI now masks out the events that it doesn't need (in particular Null events which are now used and masked properly)
Interactive help added
Memory requirements reduced; ARM610 and SA engines, since they're mutually exclusive, now share workspace to roughly halve the memory requirements.
'Add' button and dialogue box added to the Applications window, allowing entry of wildcarded filenames such as *.!Schema2 so that the list doesn't need to be altered if Schema2 is moved to another location.
Whether Aemulor's user interface starts automatically upon booting is now determined by a setting in Aemulor's config window.

Compatibility improvements

Aemulor now translates error numbers returned by the Internet module (Socket SWIs) for compatibility with 26-bit apps that assume RO4 behaviour (&00-&7F rather than &20E00-&20E7F).
Aemulor now supports 26-bit environment handlers (eg. escape handler, exit handler, error handler) and vector claimants.
Aemulor now consults the Run$Path allowing users to manually start 26-bit applications in their Library directory, for example, without having to type the full pathname or change directory.
Aemulor no longer automatically runs any utility that isn't marked as 32OK; doing so was found to cause problems with some 32-bit software because RISC OS 5 doesn't enforce this rule and some programmers therefore haven't updated their software. This change effectively makes the 32OK marker useless.
The RISC OS 5 WindowManager does not pass Tab and Shift-Tab keypresses to an app for writable, indirected text icons that don't have a validation string. However it does for icons with empty validation strings. RO4 passes the keypresses to the app in both cases, and Aemulor now hides this change allowing the tables in Personal Accounts V4 to work properly.
Aemulor now includes the functionality of the AppPatcher module, allowing many pre-StrongARM applications to run with the StrongARM engine rather than the ARM610 engine, making them much more responsive. This includes Eureka, Squirrel, PinPoint, Chess and probably many others so it's worth re-testing apps with the SA engine if you currently have them set to use the ARM610 engine.
CLI handling improved so that FS special fields are rejected, as per the OS kernel, and corrected so that I/O redirection is performed /before/ temporary FS selection.
RMReInit (module reinitialising) is now supported for 26-bit modules because some applications do this in their !Run files! Aemulor used to report "I haven't written this yet!" even for attempts to re-init 32-bit modules. This has been fixed too.
ARM610 engine changed to store PC+12 as it should; previously it implemented the StrongARM behaviour (PC+8) because the code dated back to days when the SA engine didn't exist.
Now suppresses attempts to claim the processor vectors from within 26-bit code. In theory such code should be 32-bit safe anyway, but in practice further work will be necessary, eg. the DrawWorks support modules attempt to claim the SWI vector but assume that the caller is executing below 64MB.
Squeezing and patching of 26-bit AIF images is now performed in a service call handler allowing 26-bit code to invoke this code by calling XOS_ServiceCall; one application has been seen to do this.
Aemulor now displays errors as text if trying to startup during the boot sequence, eg. when a time-limited demo copy has expired. When running from PreDesk it has been found that a module returning an error from its initialisation code - stupidly - prevents the remaining PreDesk modules from starting up (correctly).

Bug fixes

Applications using the SA-engine whilst 26-bit modules with service call handlers are loaded were unstable... giving essentially random failures because service call handlers can be invoked at any time, and the foreground state of the emulated app wasn't being preserved. This problem did not occur with the ARM610 engine.
Aemulor was interfering with 32-bit GhostScript (ps2pdf) - * command was expanding (via macros) to exceed 256 char limit in Aemulor's handling of macros; behaviour should now be the same as RO5 OS_CLI, with 1KB buffers
Aemulor was interfering with 32-bit TaskUsage by introducing a space at the start of the command tail passed to a module when entered (via OS_Module 2)
Large config files (those with more than about 30 apps), caused Aemulor to data abort when the UI started up. Resizing of app/module window definitions incorrectly calculated the new size, thus corrupting the emulated RMA
Emulated apps issuing WimpTask would sometimes find the *command corrupted/truncated, typically giving a 'file not found' error.... oweing to the *command remaining on the SVC stack but not being used until later (*WimpTask).
Shutdown delay removed. Aemulor was trying to access the hard disk after the *Shutdown command had been processed, thus causing a 2 second delay whilst the hard disk silently spun up again!
Aemulor was unsqueezing 32-bit modules on behalf of the OS, but doing it incorrectly in specific cases; only known to give a problem with a pre-release version of 32-bit PhotoDesk. Aemulor now leaves unsqueezing 32-bit modules to RISC OS, for safety, and has its own corrected unsqueezing code for 26-bit modules.
Aemulor was loading the DigitalRenderer module even though it is marked as 32-bit compatible. Caused by the module SWI chunk having the X bit set which is very unusual but ignored by RISC OS and now ignored by Aemulor to ensure compatibility.
Whilst Aemulor is loaded, all applications, including 32-bit apps, are limited to a maximum of 28MB each. Applications requesting more than this amount could cause unpredictable failures whilst Aemulor is running, eg. creating a 4800x2400x16m sprite in !Paint demonstrates this problem. Aemulor now correctly prevents apps from claiming more than this 28MB limit, but we recommend loading Aemulor in PreDesk because problems will still occur if there are apps with more than 28MB already running when you start Aemulor manually.
Apps using the SA engine & running in a TaskWindow could result in unpredictable failures if task switching is performed on returning from an IRQ (callback) because the state info for the SA engine wasn't being preserved. It is now. This problem could also cause failures in 32-bit apps running alongside the TaskWindow.
Emulated SWI OS_ReadEscapeState didn't work correctly; it was returning with V set (but R0 unchanged), potentially causing apps with error-handling code to fail.
Code that is definitely 26-bit (eg. applications declared to Aemulor or not flagged as 32-bit OK can be called directly in TaskWindows without prefixing the command with *AemuExecute). With earlier versions of Aemulor such code did not acquire a post-filter which could result in failures if the task was pre-empted.
26-bit SharedCLibrary can now access its Messages file (eg. it does this when a 26-bit command line program returns a non-zero result code).... previously this failed with an aborted store to address &FF0 (where CLib stores the address of its MessageTrans file descriptor).
Killing 26-bit modules with old-style service call handlers (ie. no list of wanted service calls) caused spurious failures after the module was killed if Aemulor was still running, oweing to the dispatch chain becoming corrupted.

Return to Aemulor documentation