!Help and Task Manager

The original icon bar menu for the task manager was as follows:

By the 13 Sep 2012 ROM image this had been rationalised but the Help messages over the icon bar menu selection items were not quite right (although this went unnoticed, I think), see below:

Sometime between the 1 Oct 2012 ROM image (still as above) and the 11Oct2012 ROM image (problems) a further change was made such that a help request over any of the task manager iconbar menu selection items now produces an ‘abort on data transfer’ error and kills the task manager, requiring a power off and on.

The PRM is rather reticent about how to provide help text over menu selection items and so although I have admired other applications that manage it I have never tried to include such help in my own applications.

Just tried this on the Iyonix (5.19, 19 Oct 2012) and it causes the TaskManager to crash with an abort on data transfer.

A quick check suggests the bug is in the code following on from the gothelpindex label.

11
        LDRB    userblk, [userblk, #icb_icon1]
01
        Pull    "r1"

; now work out the second letter of the help token

        ADR     r14, toklettertab
        CMP     userblk, #tokletterend-toklettertab
        LDRLTB  r14, [r14, userblk]
        MOVGE   r14, #"."
        TEQ     r5, #0                  ; if no memory bar,
        ORREQ   r14, r14, #&20          ; make letter lower-case
        STRB    r14, [r1], #1

        MOV     r2, #3
        SWI     XOS_ConvertHex2

The bug is located at the LDRLTB instruction. R11 (=userblk) is &FD90CA2E which can’t be right. Further up the code there’s a branch to 01 thus missing LDRB userblk, [userblk, #icb_icon1].

So either the branch is wrong or this bit of code shouldn’t be using signed comparisons.

menu selection items now produces an ‘abort on data transfer’ error and kills the task manager

I think Ben Avison spotted that, but the code was frozen for RPi purposes so the fix got deferred.

menu selection items now produces an ‘abort on data transfer’ error and kills the task manager

I think Ben Avison spotted that, but the code was frozen for RPi purposes so the fix got deferred.

Erm... shouldn't that have been fixed before the code freeze, rather than, y'know, after?

Kinda tricky to fix it before discovering it.

Erm… shouldn’t that have been fixed before the code freeze, rather than, y’know, after?

Erm… thanks for the misplaced sarcasm. That’s not how a code freeze works. The idea is you freeze all further changes and test, find bugs and then implement changes ready for the next freeze. But the changes aren’t just shoved into the test process ad hoc – you keep testing the frozen image until you’re finished testing. At that point, you have to make an assessment as to whether any of the bugs/fixes should be allowed into the next freeze, or whether (perhaps because of external factors such as deadlines) you ship as-is with a known set of issues.

For your information, we went through the freeze and test cycle five times for this RPi official release. That represents a lot of time and effort. If we kept repeating for every bug (and new bugs turn up every time you do this – it’s the nature of things) we’d never make the bleedin’ release.

Don’t worry – there’s always one more bug…. It will be good to see the official release being announced. Any bug fix will, after all, be easy to accommodate – after all there will have to be further ‘releases’ as the firmware (‘start.elf’ etc.) seems to keep changing day by day.

The Linux downloads went through lots of tweaks after release.

If there’s a version that needs testing, shouldn’t that warrant an announcement with links for downloads? (presumably even testing the IOMD or Iyonix versions would help.)

I know this might be a kludge but how about changing the line in ‘BCM2835.castle.RiscOS.Sources.Apps.Help2.c.main’ that reads

   /* Don't bother sendig requests to ourself */
    if ( (gpi->window_handle == help_box_wimp) || (gpi->window_handle == shadow_wimp) ) return;

In the file ‘BCM2835Dev.castle.RiscOS.Sources.Desktop.Switcher.s.Switcher’ the task manager appears to assume that there is a single menu structure when working out the help to provide rather than offer different help depending which menu (RISCOS from the icon bar icon or Task from the task window) is active. These menus used to be the same.

; try menu item

        CMP     r3, #0                  ; no help if not on an item
        BLT     %FT99

        Push    "r1, r2-r4"
        ADD     r1, sp, #4              ; r1 -> buffer for result
        MOV     r0, #1
        SWI     XWimp_GetMenuState
        Pull    "r1, r2-r4"             ; r2, r3 = menu selections
        BVS     %FT99

        ADDS    r0, r2, #1              ; NB: item -1 is translated into 0
        ADDGTS  r14, r3, #1
        ADDGT   r0, r0, r14, LSL #4     ; r0 = first entry + 16*second entry

        LDR     userblk, menu_userblk   ; userblk for this menu

; userblk -> object this thing relates to (possibly via the menu)
; r0 = menu index pair (&FF => not in a menu)
; r6 -> token which will be used for %2 (window title)

gothelpindex

So a single byte patch for the ROM image (which would have the effect of turning off help over the task manager window menu and the switcher menu and thus avoid the abort on the latter) is possible. Simply take the second line above and change ‘BLT %FT99’ to ‘B %FT99’. Obviously a temporary solution but invisible to the user.

Obviously a temporary solution but invisible to the user.

I can confirm that this fix (changing the byte in the ROM at &FC19E223 from &BA to &EA) is effective. The other work around is to open the taskwindow before the iconbar menu if !Help is running or switch off ‘!Help’.