Welcome to Aemulor Ultimate
===========================

The 26-bit emulator for 32-bit RISC OS.


Software version 2.53
Readme version 1.53


Introduction
============

Aemulor allows you to run old 26-bit applications and modules (written
before the days of 32-bit RISC OS) on the following machines:

 * Titanium, RapidO, TiMachine
 * Raspberry Pi 1/2/3/4/Zero
 * ARMX6, ARMiniX, ARMini
 * PandaBoard, BeagleBoard
 * IYONIX pc
 * A9home

26-bit code cannot be executed directly by the XScale, ARM9 and Cortex
processors used in these machines because they do not support the
old 26-bit addressing modes.


Installing Aemulor
==================

 1. Aemulor is a single RISC OS module. You can start Aemulor just
    by double-clicking on the module, and similarly you can stop
    Aemulor at any time. Whilst Aemulor is running all applications
    will be limited to at most 28MB of application memory, including
    native 32-bit applications, so it is best to use Aemulor only
    as and when required. The limitation on application memory is
    removed once you stop Aemulor.

    However, some 26-bit applications require that Aemulor starts
    up before the WindowManager, in which case you can install
    Aemulor into the boot sequence in the following directory:

       $.!Boot.Choices.Boot.PreDesk

    Installing the Aemulor module in the PreDesk directory also allows
    26-bit applications to be started automatically when the machine
    boots (using the desktop Boot file in the normal way).

 2. If you are using the demo version of Aemulor, check that the clock
    on the computer is set correctly. The demo version will run for
    at least 12 days from the time that you download it, but your
    clock must be set to the correct time.

 3. Restart your computer and Aemulor will start up automatically,
    appearing in the Apps directory alongside !Paint and !Edit.

 Note that the IYONIX pc and A9home versions of the Aemulor module are
 restricted to use on a particular machine, identified by its unique
 machine ID (on the IYONIX pc this is also the Ethernet MAC address).
 The release version is not time-limited.

 The ARMini/BeagleBoard/PandaBoard version will run only on the
 Cortex-A8/9 processors used in those machines and is being made
 available at no charge as a gesture of good will to the RISC OS
 community. Please do not distribute copies yourself.

 A few users have reported that they had to rename Aemulor
 in PreDesk so that it's called !!!Aemulor. This shouldn't be necessary
 but it may be worth trying if you find the machine and/or Aemulor is
 not starting properly.

Using Aemulor
=============

 As supplied, Aemulor will try to run all 26-bit applications automatically
 and you will be able to start some applications just by double-clicking
 them in the normal way.

 Other applications, and in particular complex applications that use lots
 of modules, will need to be dragged onto Aemulor's icon the first time you
 run them. (If you just double-click them you will usually get an error
 complaining that it needs 'version x.yz of module A.') When you do this
 Aemulor will ask you whether you want the application to be treated as
 26-bit code in the future; if you choose 'Yes' then it will be added into
 the "Applications" window and you will then be able to start it just by
 double-clicking on it.

 The !Aemulor application, accessible via Apps on the icon bar, provides an
 interface that allows you to configure the emulator and to see what code is
 being run under emulation. If you want to close the user interface without
 stopping the emulator, so that 26-bit code will continue to run, just choose
 Quit on the icon bar menu. Choosing 'Emulator too' on the Quit submenu will
 stop the emulator as well, thus also closing all 26-bit applications and
 modules.

 For further information on the !Aemulor application please see the on-line
 help available by pressing the menu button over the !Aemulor icon in Apps
 and choosing "App !Aemulor->Help."

Using Aemulor from a TaskWindow or the command line
===================================================

 If you need to run a 26-bit application from a command line and Aemulor isn't
 automatically detecting that the application needs to be emulated, you can
 either run it inside a 26-bit TaskWindow (by choosing TaskWindow on Aemulor's
 icon bar menu) or prefix the command with 'AemuExecute' to force it to be
 emulated.

 This is, in fact, how the 26-bit filetypes Obey26 and BASIC26 are implemented
 and it can be used to ensure that other files are executed under emulation.
 For normal desktop applications this isn't necessary because double-clicking
 a document file causes the application to be started and Aemulor already knows
 that the application is 26-bit code.

 'AemuExecute' should work for any *command, including module commands - eg. you
 can 'enter the 26-bit world' by typing "AemuExecute BASIC" within a TaskWindow,
 and then any commands/programs that you run using the BASIC interpreter are
 'emulated' by Aemulor so that they behave the same as they do on RISC OS 4.

 Be warned that if you use AemuExecute to run code that is already 32-bit
 compatible then it will also work under emulation because it's designed to
 run on 26-bit systems too. There will, however, be a performance hit so only
 run code under Aemulor when it won't work natively.


Points of interest
==================

 Impression Style/Publisher

   Installation from floppy disks has not been properly tested by the
   Aemulor team yet, though someone has reported that it worked with
   an earlier version of Aemulor.

   You may have to tinker with your !System directory in order to
   get all of CC's applications running properly, oweing to differing
   versions of the ABI module etc. This is no more than you sometimes
   have to do on earlier versions of RISC OS. If you do have a working
   installation of these applications on another machine, it would be
   worthwhile to compare the two !System directories when resolving
   such problems.


Aemulor Pro
===========

 The following features are supported only in Aemulor Pro and not
 in the standard version of Aemulor:

  * 26-bit filing systems (eg. CFS, LanMan98FS, WebFS, Win95FS)

  * Sound support (voice generators, linear handlers,
    channel handlers and schedulers)

  * IRQ handlers, as required by podule drivers

  * Emulation of low-bpp modes (2-,4- and 16-colour screen modes)
    as required by some old software, including games and also,
    notably, Sibelius.

  * Simple emulation of the Archimedes hardware (VIDC/IOC) or
    RiscPC hardware (VIDC20/IOMD) which is directly accessed by
    some games.

  * Altered memory map and hardware configuration is presented
    to 26-bit code that expects certain addresses and controllers.

  * Filter routines (typically used in desktop utilities)

 Aemulor Pro also includes a Tasks display window that provides
 a graphical display of the applications which are being emulated
 and the amount of memory each is using. The window also allows
 applications and dynamic areas to be killed.


Hints and Tips
--------------

If you find that a game doesn't work under Aemulor Pro, especially an older
game, try the following:

 * Change the processor type (StrongARM/ARM610/ARM3) for that game.
   Some games will only work on certain processors; as a rough guide the
   game's age should be a clue:

   1987-1994 = ARM3      Archimedes
   1994-1996 = ARM610    RiscPC
   1996-     = StrongARM RiscPC

   It can also be helpful to use an older processor type if you find that
   a game is too fast under Aemulor.

 * Many games require specific screen modes which are not normally provided
   on more recent machines. Often one or more screen mode definitions
   (called 'MDF' or 'Modes') can be found inside the application itself
   and these should be copied into the Monitor Definition File (MDF) that
   you use for your monitor. (Inside $.!Boot.Resources.Configure.Monitors..)

   It's worth checking the game's !Help file, if it has one, for further
   instructions.

 * A related problem is that often the frame rate of the native screen mode is
   much higher than the game expects, causing the music and/or game itself to
   play too quickly. This problem is compounded by the fact tha RISC OS will
   normally choose the highest frame rate available for a given resolution.

   You may find that you have to comment out/remove high frame rate,
   low-resolution modes. A future release of Aemulor Pro will aim to make the
   use of non-native screen resolutions and frame rates a lot simpler.

 * Spheres Of Chaos performs a lot better if the Vision option 'Draw to buffer'
   is used rather than 'Draw directly to screen.' Other games may benefit from
   similar settings where available.


Limitations
===========

 Aemulor provides an emulated RMA and system heap (appearing as two
 dynamic areas in TaskManager) for use by 26-bit code.
 The emulated RMA and system heap must be visible at all times, so
 that Aemulor can dispatch service calls etc. to 26-bit modules, even
 whilst 32-bit applications are running. This means that all applications
 are, unfortunately, restricted to a maximum application slot of 28MB
 (as per RISC OS 4) whilst Aemulor is running. It is hoped that this
 limitation can be removed in a future version but doing so is
 technically very difficult.

 Remember that whilst Aemulor Pro emulates some of the hardware present in
 older machines, it is not a full machine emulation and will therefore be
 some games and applications that do not work as expected.

 Aemulor Pro's Task Display window cannot be used to resize memory
 areas at the moment.


A9home Notes
============

 The A9home version of Aemulor does not provide an emulated RMA
 because the OS's Module area is currently still at an address suitable
 for running 26-bit code.

 Aemulor therefore uses that too, reducing memory requirements and - more
 importantly - allowing the maximum application size to be 24MB when
 Aemulor is running, versus 28MB without Aemulor.


Known bugs
==========

 * Changing back to a native mode after being in a low-bpp mode will not
   work if the native screen size exceeds 4MB with current code. As a
   workaround for now, change into a low resolution native mode so that
   the screensize is less than 4MB. You can then change into any screen
   mode.

 * Trying to run a file located on "share::machine.$..." by passing just
   its pathname to OS_CLI when the current filing system is ADFS, for example,
   results in a "Please insert disc 'machine' error." In practice OS_CLI
   is rarely used in this way so the fault is unlikely to be seen, but it
   should be fixed as part of some work planned for a future version.

 * Aemulor is unable to shutdown some 26-bit modules if Aemulor itself
   is being reloaded


History
=======

2.00	21 Feb 2003

	Demo version

2.10	25 Mar 2003

	First release version

2.20	04 Aug 2003

	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 attempt's 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 - unfortunately - 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.

2.21	07 Aug 2003

	Bug fix: With Aemulor set to run all 26-bit code automatically,
	it was interfering with 32-bit applications that RMRun a module
	which has a 'start' entry and isn't being passed any command
	parameters. The module was being initialised but not entered.

	This was breaking 32-bit versions of StrongHelp, Director and
	Reporter, and probably a handful of other applications.

2.29b	21 Apr 2004	Pro Beta release

	User interface changes

	* Added a TaskWindow option to the icon bar menu which opens a
	  26-bit TaskWindow for running command-line utilities etc under
	  Aemulor.

	* Applications window now accepts normal directories, so that - for
	  example - you can add the directory in which you keep all 26-bit
	  applications, rather than adding each application individually.

	* Module window now provides help info on 26-bit modules.
	  Also available via the *Help command.

	* Added sprites to the Applications window, making it easier to
	  locate applications. Double-clicking Select on an application
	  opens the options window for editing, double-clicking Adjust runs
	  the application.

	* Improved handling of application and module panes over mode changes
	  and esp. low-resolution modes. Now uses the nested WindowManager.

	* Keyboard control of Applications window. By entering the first
	  few characters of an application's name (eg. Eure for ...!Eureka)
	  you can select that application.

	Compatibility improvements

	* Provides the Bfont alphabet and the Master and Compact countries
	  which have been removed from the RISC OS 5 International module.

	* SharedCLibrary updated to version 5.46

	* Aemulor's unsqueezing code modified to also cope with older squeezed
	  executables allowing more applications to benefit from the
	  StrongARM engine.

	* Use of OS_InstallKeyHandler supported

	* Interception of OS_SynchroniseCodeAreas SWI for 26-bit apps,
	  giving better compatibility when using 32-bit modules that
	  modify/generate code.

	* Added support for user-drawn objects (26-bit routines can be
	  passed to Wimp_DragBox and DragAnObject_Start).

	* Emulated RMA & System Heap now fully support resizing
	  (often performed by old games and demos to release memory)
	  and may be resized manually using the TaskManager.

	* ARM3 engine added to improve compatibility with self-modifying code.
	  Uses the same basic emulation as the ARM610 engine but with code
	  buffering optimisations disabled because they can break some self-
	  modifying code. Use this engine only as a last resort because it's
	  much slower.

	* Patched BASIC to remove support for 'sp' register in assembler code
	  because this breaks programs which use register names starting with
	  'sp', eg. 'speed'.

	* Implemented *RMFaster command for use by older programs.

	* Added support for dynamic areas with 26-bit handler code.

	* Included emulation of ARMvID register (CP15 C0)

	* Support for tokenised help/syntax text in 26-bit modules.

	Bug fixes

	* Data abort logging reports correct address of failure (instead of
	  &12345678!) and can handle multiple aborts in quick succession,
	  as can occur if an application tries to recover itself but incurs
	  a further abort. Undefined instructions errors reported by the
	  ARM3/610 engine now contain the address.

	* Emulated DAs were sometimes mistakenly allocated below 64MB,
	  possibly conflicting with the emulated ROM image at &3800000.
	  Also corrected fault in error recovery code when resizing.

	* Applications trying to use wimpslots >= 56MB would cause the
	  machine to lock up if Aemulor had been run (and quit) beforehand,
	  oweing to Aemulor restoring the memory map incorrectly after
	  unmapping the ROM image at &03800000. DeskEdit would also abort
	  loading some files because only the first 1MB of the ROM was
	  being mapped.

	* Use of Choices$Path and Choices$Write corrected

	* OS_SWINumberToString was omitting the X prefix on
	  error-returning OS SWIs

	* Taskswitching between 26-bit and 32-bit apps could cause
	  occasional freezes/instability with Browse running.

	* Aemulor now requires the 'messages filename' field of 32-bit modules
	  to be word-aligned if used, as per the RISC OS kernel.

	* Applications written in BASIC were using the 'Other applications'
	  config settings instead of their own.

	* Auto-run checks now only performed on executable files. In earlier
	  double-clicking (=> running) a file inside a 26-bit application would
	  cause the editing application to be emulated even if it's 32-bit OK.

	* Errors returned by 26-bit utilities were being ignored.

	* Corrected read operations on emulated system heap.

	* Applications no longer loaded at their load address to check for
	  32-bit compatibility because this can overwrite environment handlers
	  and data that will be needed before the new application starts
	  (especially BASIC's UpCall handler). This was the cause of the
	  conflict with Font Directory Pro.

	Aemulor Pro
	-----------

	Features

	* Added Tasks window that shows the applications that Aemulor is
	  running and any dynamic areas that are being emulated at low
	  addresses for those apps. It also shows the emulation mode for
	  each task, and the amount of memory being used by the emulation.

	* Includes support for 26-bit sound
	  (8-bit voice generators and 16-bit linear handlers).

	* Supports 26-bit filing systems.

	* Support for low-bpp screen modes (2,4 and 16 colours) and
	  provides screen resolutions that are unavailable natively to
	  allow older games to work.

	* Emulation of IOMD/VIDC20 and IOC/VIDC for those programs,
	  especially games and demoes, that directly access hardware.

	* Includes support for IRQ/device handlers (OS_ClaimDeviceVector)

2.29e	01 May 2004	Pro beta update

	Compatibility improvements

	* OS_ReadSysInfo returns correct hardware features for the emulated
	  machine for those games which check VIDC20 availability, for example.

	* Improved emulation of hardware and implemented IOC/IOMD timers 0 and 1.

	* StrongARM engine now always stores PC+8 in STR/STM instructions rather
	  than PC+12 as per earlier processors (the assumption that no code
	  would be written to work exclusively on the SA proved false with the
	  arrival of SA-specific patches for old games).

	* OS_Byte 129 now returns C flag though this behaviour isn't documented
	  in the PRMs.

	* Included emulation of CP15 register C2 reads (ARM3 cache state)

	* Implemented the *GO command which is used by quite a few older games.

	* OS_ClaimScreenMemory implemented for emulated screen modes

	Bug fixes

	* Matching of pathnames against the applications list was using
	  the canonical form but without Run$Path so some programs invoked
	  at the command line could be ignored by Aemulor and run natively
	  instead.

	* 'Add application' applied its settings to the most recently edited
	  application instead of the newly-added one.

	* Corrected reporting of 'invalid number of parameters' errors for
	  *commands provided by 26-bit modules.

	* OS_SynchroniseCodeAreas implementation was causing intermittent
	  crashes when running Spheres of Chaos (and probably other games too).

2.30	05 May 2004	Pro first release

	User interface changes

	* Select-clicking on Aemulor's iconbar icon with shift held down opens
	  the Task display. Shift-adjust-clicking opens the Config window.

	Compatibility improvements

	* Detection (and hiding) of negative validation string pointers which
	  were previously treated the same as -1 (now only -1 is accepted by
	  the RO5 Wimp).

	* SharedCLibrary 5.47 introduced to resolve PipeDream hanging fault
	  (and possibly other C apps too).

	* Improved Aemulor's shutdown code to better handle processor vectors
	  being claimed by other modules such as SpecialFX. Claimants must
	  still be shutdown in reverse order though.

	* Emulation of OS_Memory 9 for reading VIDC/VIDC20 controller presence
	  and base address.

	* Provision of memory from &1F02000 to &1FFFFFF which is directly
	  accessed by some old Archimedes games, including USR-writable
	  memory from &1FEC000 upwards.

	Bug fixes

	* Applications started via the 'Run' button in the Apps window were
	  used the 'Other applications' settings for loading their modules
	  and, in the case of games started with *GO, for running the application
	  code too.

	* Aemulor Screen base address was being written to address 0 upon
	  entry to an emulated screen mode.

	* Corrected support for 26-bit sound schedulers

2.31	15 Sep 2004	Update to bring Aemulor and Aemulor Pro into line

	User interface changes

	* Small tweaks to saving of module help text to improve conformance.

	* Scroll wheel support

	* Shift-dragging something onto Aemulor adds it to the Applications window.

	Compatibility improvements

	* Implemented undocumented passing of command tail, load address and
	  exec address to executable code because some errant code relies upon it.

	* Using the StrongARM engine CP15, C2 now returns bits[13:0] which is the
	  undocumented behaviour seen on a real SA. (Some old code assumes this
	  register is the ARM3 cache control register.)

	* SharedSound support in Pro.

	* ABCLibrary updated to 4.15

	* Eureka ToolSprites issues resolved (application code assumed 16 colour,
	  fully-opaque toolsprites and 16 colour filetype sprites. This is no longer true).

	Bug fixes

	* RMEnsure failed to return error message if the module was absent/too old
	  and there was no trailing command.

	* When loaded, Aemulor now reports an error and refuses to start if any
	  running task is already using more than 28MB of memory. Thanks to
	  Rob Davison for this solution.

	* Corrected running of application directories (the altered behaviour of 2.30
	  caused Obey files and desktop launchers to start 26-bit applications natively
	  instead of emulated)

	* Fixed detection of unaligned (image) filing systems entry points. This fault
	  sometimes rendered Win95FS unusable.

2.32	03 Nov 2005	Compatibility improvements and bug fixes
			First A9home release

	Important changes since version 2.31

	* This release and future releases of Aemulor will not automatically treat
	  all programs invoked by a 26-bit program as 26-bit programs, ie. if they
	  must be emulated then they too must be added to the Applications list in
	  Aemulor.

	  The reason for this change is that it allows 26-bit programs to now use
	  the 32-bit !ARMovie supplied with the IYONIX pc. It also means that
	  double-clicking a URL within a 26-bit application will no longer cause
	  your web browser to start up under Aemulor.

	* Previous versions mistakenly treated filetypes in the range &000-&EFF
	  as code and performed a cache synchronisation when loaded with OS_File
	  from a 26-bit program. This was never the intended behaviour, and in
	  fact it would only have worked properly with the ARM610 engine.

	  The code has been corrected to only synchronise for known types requiring
	  it, including Impression Publisher's 'IModule' filetype that previously
	  gave intermittent startup failures with the StrongARM engine.

	  This change does, however, have the potential to break compatibility
	  with some applications that worked previously.

	Features

	* Greatly increased the speed of the emulated low-colour screen modes,
	  making Sibelius, and the desktop, much more usable.

	* Added a Find window with search-as-you-type for locating programs in the
	  Applications window. (F4)

	* Shift-dragging an application into the Applications window adds an entry
	  of the form '*.!<app>' rather than the full pathname.

	* Dragging an application into the Applications window now scrolls to the
	  existing entry if there is one.

	Compatibility improvements

	* Added support for multiply-instantiated modules

	* Wimp_SetPointerShape nowhandles shape pointers in the same way as RO4

	* Implemented OS_SetEnv and OS_Control

	* Added support for 26-bit filter handlers in Pro (typically used by
	  desktop enhancement applications/utilities).

	* Implemented IOC/IOMD Timer 1 using the RO5 HAL routines, allowing use
	  of 26-bit Replay and low-level game/emulator code.

	* Support for calling of 26-bit SWIs via Sound_QSchedule (employed by
	  Iota's TouchType application)

	* Eureka ToolSprites patch modified to cope with absence of Tools3D file.

	* Support for 26-bit BASIC passing workspace parameters in R0-R5 to
	  module *command handlers such as Reporter's *Report command.

	Bug fixes

	* Improved the checking of valid SWI decoding table/code in modules.

	* Corrected matching of command lines against the app config which could
	  cause data aborts with long commands, eg. !Browse invoking !ChangeFSI on
	  a scrapfile.

	* Limit the kernel to a 28MB application slot also whilst Aemulor is running
	  because otherwise it will map memory over the emulated RMA and other DAs
	  when the desktop shuts down ('Exit desktop' or 'Shutdown' in TaskManager)
	  potentially causing crashes.

	  In order to achieve this safely, Aemulor now creates a number of
	  'Aemulor DA space' dynamic areas of zero purely to consume address space
	  and thus prevent the kernel allocating DAs within that region whilst
	  Aemulor is running. (Doing so would cause crashes with large applications
	  after Aemulor is terminated.)

	* Circumvented the hang when 'resizing RAM disc and Aemulor is set to auto-run
	  26-bit apps' which appears to be an OS bug.

	* 26-bit utilities were inadvertently being emulated in SVC26 mode, causing
	  crashes in Utility files that use OS_EnterOS before then switching back to
	  USR26 mode.

	* Under some circumstances Aemulor's post filter could be installed twice
	  on 26-bit tasks in TaskWindows leading to crashes when/after the TaskWindow
	  is closed or Aemulor is stopped.

	* Emulated IRQ handlers were being passed an incorrect IO base address in R3.

2.33	25 Aug 2012	First Cortex-A8/9 release (ARMini/BeagleBoard/PandaBoard)

	* A9home build now checks that the OS is a 32-bit variant; pre-release versions
	  of the A9home OS did not claim to be 32-bit platforms.

	* Ported ARM3/610 engines to Cortex-A8/9 series processors and implementedd
	  alignment fixups on load/store operations.

	Bug fixes

	* Aborted reads from address -1 (could only happen as a result of programming
	  error in practice) within other code, caused a machine hang with Pro running.

2.34	16 Apr 2013	First RaspberryPi release

	Bug fixes

	* Accommodate absence of VProtect module (symptom: 'obey2' not found when
	  trying to start applications by using Obey26 files)

2.35	11 Jul 2015	IGEPv5 release

	Features

	* Support for Cortex-A15 (IGEPv5 target)

	* Performance optimisations to the ARM3/ARM610 engine

	* New builds targeting the IGEPv5 (Cortex-A15) board, and (Emulated) RiscPC

	Bug fixes

	* Prevent the error 'Overlapping areas' occurring after Aemulor has been
	  stopped, either in a subsequent attempt to start Aemulor or in other
	  software that uses dynamic areas.

2.36	11 Oct 2015	Software pointer support

	Bug fixes

	* Support the use of software pointers in wide (>= 2048) screen modes on
	  post-IYONIX pc hardware

2.40	15 Oct 2017	First free development release

	Aemulor has moved to a rolling updates model rather than publishing more
	well-tested, formal releases. This is an effort to ensure that fixes for
	compatibility issues resulting from OS changes are more available to users
	sooner.

	The requirement to run legacy software should not retard OS development,
	and there should come a point at which even something like Aemulor is not a
	viable approach to sustaining it. At that point a sandbox/virtual machine-like
	approach will be necessary going forwards.

2.50	16 Aug 2019	High-memory model and ARMbook support

	New features

	* Introduces a new memory model as a configuration option, which increases the
	  maximum per-memory application to 52MiB from the original 28MiB. The choice
	  is presented in a dialog upon first use. Thereafter it may be modified
	  within the Config window of the Aemulor UI but will only take effect upon
	  restarting Aemulor.

	* Support for ARMbook laptop from R-Comp

	Miscellaneous

	* Renamed some of the builds according to CPU rather than target device
	  to accommodate newer RISC OS targets

2.51	08 Sep 2019	Release for all machines

	Rebuild and release for all machines such that hopefully all are now in step.
	RPi4 build to follow; currently have hardware but not a suitable image.

2.52	25 Sep 2019	Compatibility update

	* Improved compatibility with builds RISC OS 5.27 to accommodate changes
	  in the way that the application space limit is handled.

	* Support 26-bit versions of Impression using updated 32-bit versions of
	  the support modules (GDraw, DitherExtend, FontDraw and GSpriteExtend) which
	  are required on targets such as Titanium and ARMbook with R/B transposed.

	  Modules which are 32-bit but are 'added' (OS_Module 10) by 26-bit Impression
	  end up on the OS module chain but still in the RMA because Aemulor cannot
	  relocate them. When this happens a warning will be issued by the UI when
	  attempting to stop Aemulor; if confirmed or outside of the UI those 32-bit
	  modules will be killed before Aemulor stops.

2.53	28 Feb 2020	Raspberry Pi 4 and UI tweaks

	New features

	* Additional keyboard shortcuts in user interface, including modules window
	* Access to online help information
	* Module size reduction
	* First Raspberry Pi 4 build

	Miscellaneous

	* Improved reporting of startup issues on RPCEmu (patched or unpatched ROMs)


Thank you to Neil Spellings for publishing and supporting Aemulor since its inception
in 2002.

Please report any problems relating to numbered releases to the email address below.
If the version number has a letter as a suffix then it should be considered an unproven
development build, in which case feel free to report problems to aid its development,
but please do not expect a personal reply.

Best wishes,

Adrian Lees
https://sendiri.co.uk/aemulor
a.lees@sendiri.co.uk
