GitLab

Use SMP_Special SWI to suspend & resume the callback-based thread
scheduler during sensitive bits

Detail:
  Escape being pressed whilst in an OS_Byte 129 call (MyByteV) was not being
  handled on return to MyRdChV before the TaskWindow suspended itself via a
  Wimp_Poll.
  Added check for Escape on entry to MyRdChV.
Admin:
  Remove redundant RestPSR just before OS_ReadEscapeState.
  Extended reach of title string ADR when CMDHELP=None.

Version 0.85. Tagged as 'TaskWindow-0_85'

* Check TaskWindow$Server exists first to avoid misleading error trying to run it
* Delete leftover Help (see CmdHelp)
* Add safety range check to SWI handler

Version 0.84. Tagged as 'TaskWindow-0_84'

Detail:
s.TaskMan: Alter initial value of PassOnVectors in inittask

This fixes a bug, that if an editor is not currently running then
starting a task window with "%TaskWindow -display -ctrl" from
the new task option in the task manager causes a branch through
zero.

Whilst I have not worked out the exact detail of the crash,
the cause appears to be that PassOnVectors is set to false before
GetParentTask is called. In GetParentTask, Wimp_StartTask is
called, which emits control characters. This causes
GetParentTask to be re-entered (this time via MyWrchV rather
than the start-up -display code). It gets hazy what happens
after to branch through zero, but changing it to set
PassOnVectors=true before the initial GetParentTask fixes the
issue.

If an editor is already running then the crash doesn't occur
because it responds to the Message_TW_NewTask, so Wimp_StartTask
is never called. If the -ctrl switch is absent then the control
characters from Wimp_StartTask are ignored by MyWrchV. If
-display is absent then it never calls GetParentTask during
the start-up code.

Admin:
Tested standalone on RPCEmu and RPi3B+

Version 0.83. Tagged as 'TaskWindow-0_83'

Was calling OS_Exit immediately upon TaskWindow_Morite being
received, even if in a SWI call.

Instead flag for later attention like Message_Quit.

This results in error being returned from sleeping SWI calls, and
OS_Exit being called in a callback after supervisor mode code has
had a chance to clean up.

Version 0.82. Tagged as 'TaskWindow-0_82'

Detail:
  Was checking EscPending (which had been set to 0 by RestoreEscape) rather than EscWasSet, and so the return results (R2=27 and C=1) of an Escape during OS_Byte 129 were lost, R2=0 and C=0 were instead returned.
Admin:
  Fixes https://www.riscosopen.org/tracker/tickets/467

Version 0.81. Tagged as 'TaskWindow-0_81'

Detail:
  ADR->ADRL for standalone builds, such as Disc or CTools environment.

Detail:
  11 local definitions of OsBytes replaced with those from the central headers.
Admin:
  Built as binary identical.

Detail:
  s/Taskman - Add comments for the different build switches, so it's more obvious what they do. Remove a couple of unreferenced switches.
Admin:
  Resulting binary unchanged


Version 0.80. Not tagged

Detail:
  s/Taskman - When TaskWindow was converted to use TickerV instead of VSync events for implementing the INKEY timer, one line of code was left in the wrong place, causing all INKEY delays to be 1cs longer than they should
Admin:
  Tested on PandaBoard
  100 * OS_Byte 129,0,0 now completes instantly (was 1s), 100 * OS_Byte 129,1,0 now completes in 1s (was 2s), both now matching single-tasking behaviour
  Should fix issue reported on forums with OS_Byte 129,0,0 -heavy programs running unreasonably slow:
  https://www.riscosopen.org/forum/forums/4/topics/9317


Version 0.80. Tagged as 'TaskWindow-0_80'

Detail:
  s/Taskman - As described in the ARM ARM, the local exclusive monitor is allowed to be a bit dumb when it comes to comparing addresses, and so a manual CLREX is required whenever we return to code that has been unwillingly pre-empted
Admin:
  Tested on Raspberry Pi


Version 0.79. Tagged as 'TaskWindow-0_79'

Detail:
  s/Taskman - Remove all NOPs from after PSR manipulation macros; the macros now take care of these for us. Change some RestPSR instances to the "f" variant, so that the macro won't insert ARM2 NOPs.
Admin:
  Tested PlingSystem build on (ARM3) RISC OS 3.1
  Requires HdrSrc-2_63 to be ARM2 safe


Version 0.78. Tagged as 'TaskWindow-0_78'

Detail:
  s/Taskman - Generation of TaskWindow_Dying error within ByteV handler wasn't balancing the stack correctly, causing it to try branching to the PSR. Fix this, and tighten up the code a bit (can use R0 as temp as it'll always be set to something sensible on exit)
Admin:
  Tested on iMx6
  Fixes reported issue with machine stiffing when killing task windows containing running programs
  Issue was only observed on pre-PMP kernel version, where the code would have branched into the free pool (loaded PSR appeared to be &80000193), corrupted some memory, and then got stuck in a loop
  Presumably this has never been spotted on other systems because there would have rarely been any memory at that location, generating an immediate abort, but the error message gets swallowed because the task is exiting? (or there was memory there, but the user got lucky and the code aborts before fatally corrupting anything)


Version 0.77. Tagged as 'TaskWindow-0_77'

Detail:
  s/Taskman - Escape some dollars contained in strings to avoid warnings from objasm
Admin:
  Resulting binary unchanged


Version 0.76. Retagged as 'TaskWindow-0_76'

Move Hdr:Services up above Hdr:Wimp
Built, but not tested.

Version 0.76. Tagged as 'TaskWindow-0_76'

Detail:
  s/Taskman - Search-and-replace error when getting rid of $ModuleName left one instance of it behind, with the result that in 0.74 the *TaskWindow command would attempt to start the task '$ModuleName' instead of 'TaskWindow'
Admin:
  Tested on BB-xM


Version 0.75. Tagged as 'TaskWindow-0_75'

Make decision to use internationalised help based on predefines passed in from outside not a bitfield definition in Hdr:ModHand.

Shifted crusty changelogs out of the sources.
Reencoded the command table using the 'Command' macro rather than by hand, required renaming a few function labels to use the ones it generates.
Add support for the standalone version to register its messages with ResourceFS.
Update the help to detail the "-nice" switch which has been present for some time.
Change some Wimp and OS_Args reason codes to use those from the respective header files.
Tested on RISC OS 3.10, now at least opens a task window.

Version 0.74. Tagged as 'TaskWindow-0_74'

Detail:
  s/Taskman - Attempt to get DomainId pointer from OS_ReadSysInfo 6 before falling back on legacy address. Fix NiceNess code to not pass null pointers to OS_ReadUnsigned.
Admin:
  Tested on rev A2 BB-xM


Version 0.73. Tagged as 'TaskWindow-0_73'

Previous changes were untagged, but incrementing the version number gives
us a tag we can associate with the official RISC OS 5.16 release.

Version 0.72. Tagged as 'TaskWindow-0_72'

Detail:
  Uses suffixed file extensions for compatiblity with both objasm and asasm.
Admin:
  Supplied by Peter Naulls, tested at ROOL

Version 0.71. Not tagged

Detail:
  The bottom four words of the SVC stack were being preserved across calls
  to Wimp_Poll. This is a curious choice, since the bottom seven words are
  reserved to hold run-time data, and C libraries to date have only used
  two words (the library and client relocation offsets). Changed to save
  all seven reserved words across Wimp_Poll.
Admin:
  Tested briefly on an Iyonix, with no visible ill effects.

Version 0.71. Tagged as 'TaskWindow-0_71'

No longer assumes flag preservation across Wimp_Poll.

Version 0.70. Tagged as 'TaskWindow-0_70'

If in 32-bit mode, now required to expect and requires the application space size change in Service_Memory issued by the Wimp to be 02 GB, not

-64 MB.

Version 0.69. Tagged as 'TaskWindow-0_69'

Details:
>
> I was just fiddling with Taskwindow, and realising one of the big things
> slowing it down is that it polls everytime its internal buffer gets filled.
> If it just lets the Wimp do the queueing it goes quite a lot faster!
>
> It only polls the wimp once every 10 buffer fulls of data, so is pretty
> nippy, but doesn't stall when doing a lot of text output in SVC mode.
>
> It also assembles to use TickerV instead of VSync (unless you unset the
> flag).
>
Admin:
  Tested on Ursula RiscPC and STB without any problems.

Version 0.68. Tagged as 'TaskWindow-0_68'

  Reintroduced buffer enlargements.

Detail:
  A new flag has been added, '-nice <n>' which if specified allows
modification of the default number of VSyncs before task switching.  This
works a bit like UNIX nice, hence the name.  A nice value of 1 will make
multitasking very smooth.  It also allows relative priority to be specified
between taskwindows.  So the default is 10, and a nice 1 taskwindow will get
10 times less CPU time than a default window.  A nice 100 taskwindow would
get 10 times as much CPU time as a default one.

  The buffer enlargements were inadvertantly checked over in a previous
checkin.  They have now been re-introduced.

Admin:
  Tested on a RiscPC.



Version 0.67. Tagged as 'TaskWindow-0_67'

Detail:
  Taskwindow sits of BYTEV and waits for n*2 Vsyncs when INKEY(n) is called.
This isn't quite correct as VSyncs aren't a reliable timing source, however,
leaving that aside for the moment, what Taskwindow was doing was sitting on
Null events until it read that enough Vsyncs had passed, thus eating up CPU
time.

  The new behaviour is to call Wimp_PollIdle instead, which should also
correct the amount of time waited for.  This behaviour can be toggled with
the build switch PollIdleHandling.

Admin:
  Lightly tested on a RPC.  Using AppStat, no call were made to the
taskwindow during and INKEY, whereas they were previously.


Version 0.66. Tagged as 'TaskWindow-0_66'

Detail:
  UpCall 6 is documented as accepting a pollword which can be scanned for
being non zero to return control to the process requesting to sleep.  This
was not being used within the taskwindow module, there being a comment where
it would have been used suggesting that this would give the taskwindow too
high a priority.  What this means is that if given a pollword that is already
nonzero, the task would receive so many polls as to really make the desktop
juddery.  The solution is that if the pollword is non-zero on entry,
Wimp_Null is unmasked rather than passing the pollword.

  This means that UpCall 6 can be used either as a yield, to say 'let other
tasks have some CPU now' (by passing a pollword known to contain nonzero) or
as sleep to say 'wake me up when the pollword becomes non zero, and don't
consume any CPU time until then' (by passing a pollword that will only become
nonzero upon the occurance of a specific event).

Admin:
  Tested on RPC.

Version 0.65. Tagged as 'TaskWindow-0_65'

Detail:
  The UpCall wasn't being claimed because the common error creating return
was being used which returns to lr rather than popping the stack.  Now the
error routine is BLed to and then the stack popped so as to claim the UpCall.

Admin:
  Tested on RPC.

Version 0.64. Tagged as 'TaskWindow-0_64'

Detail:
  If output is occurring quickly, then fewer longer Wimp messages are
    transmitted rather than a stream of small messages.
  RAM Transfer buffer size increased too.
Admin:
  Tested in softloaded OS.


Version 0.63. Tagged as 'TaskWindow-0_63'

  Updated to build using objasm instead of aasm.
  Sources changed to be objasm-compatible.
Admin:
  Requires Library 0.71 or later.
  Requires BuildSys 3.06 or later.
  Requires Env 0.65 or later.

Version 0.62. Tagged as 'TaskWindow-0_62'

  ... switched to using objasm.
Detail:
  Increased parameter buffer size to 1024.
Admin:
  Requires BuildSys 3.01 or later.
  Fixes Bugzilla bug #280

Version 0.61. Tagged as 'TaskWindow-0_61'

Detail:
  TaskWindow used to enable VSync events for each new task that was
    started.  However, it failed to disable the VSync events again
    when the task exited unless the task was the last one running.
    This meant that VSyncs would be going off for no reason at all
    slowing the machine down if you had ever started a taskwindow.
    Events are now only ever enabled when the first task is created,
    and disabled when the last task is killed.
Admin:
  Tested in desktop build.

Version 0.60. Tagged as 'TaskWindow-0_60'

Detail:
  Fixed the spurious character problem.  It was due to me believing some
    misleading comments in the source code.  When the comment said "pass
    it on" (at the end of a vector handler), it actually meant "claim it".
    WrchV is now claimed correctly, and no output is "leaked" any more.
Admin:
  Module may well no longer function on RISC OS 2.00
  Tested on Ursula build.

Version 0.59. Tagged as 'TaskWindow-0_59'

Detail:
  Removed obsolete file.
  Made rest of the module 32-bit safe.
  A bug remains: when a taskwindow is started the first few characters of
    output are not being intercepted correctly (although they are sent to
    the parent task).  Looks as if something isn't initialised correctly?
    Perhaps a failure to intercept WrchV in these cases?
Admin:
  Tested in Ursula softload.


Version 0.58. Not tagged

Detail:
  Moved to srccommit, merged changes from Ursula branch.
Admin:
  Built.

Version 0.58. Tagged as 'TaskWindow-0_58'