I give up!

I wrote a bug into my kernel somewhere. That’s perfectly normal and common, I do it all the time.

What gets me is the symptom. It was crashing part way through displaying the Wimp start up screen, where it says “RISC OS Developments Ltd.”, “RISC OS 5”.

There’s a memory fault accessing zero page after printing the second I.

It turns out that even without the Wimp, painting “RISC OS” with that font (Homerton.Bold, 24 point) demonstrates the same problem.

That’s not all, though. It gets worse!

Painting “R SC OS” works! Editing the template in Desktop to “R SC OS” works!

How am I supposed to track that down?

Apologies for the rant, I’m a tad frustrated. I don’t suppose anyone has seen anything similar in the past?

Turn on/off the font cache? Try the character with a transform to change its, say, width.

Might be OS_Heap? Log the exact size of the heap increase due to that character in that size font.

I’m assuming that’s how the cache is managed. I haven’t checked.

Even “RiSC OS” works! It’s very confusing. I expect I’ve made a mistake in the service calls from expanding DAs. It can wait.

A lower case letter, at that size, will be a different bitmap size.

Yes, of course. Also a different number of curves. The thing is that I haven’t changed the FontManager code, so it must be something I’ve done.

Edit: “RUSC OS” also fails.

Just display it as RiSC os, can’t be any worse than JaGUar :)

I think I’ll try to track the bug down instead, tyvm!

OK. So. Turns out there are two different DynAreaHandler_FontArea routines, one in Kernel/s/ChangeDyn, the other in Video/Render/Fonts/FontManager/s/Fonts01.

The former consists of the kernel having knowledge of the FontManager (it calls the publically undocumented Font_ChangeArea SWI) and makes assumptions that aren’t valid with my kernel.

The latter, unused except by me because the legacy kernel initialises the dynamic area in InitHostedDAs, does not seem to work.

Oh, joy!

it calls the publically undocumented

🤦

Undocumented stuff “for internal use only” is naff and lazy.

Oh, joy!

Put the kettle on, you’ll need tea for this. Lots and lots of tea.

I think this patch fixes the DA handling in the module, at least on startup and probably on expanding the DA size. I didn’t look at shrinking.

diff -Naur orig/Fonts01 fixed/Fonts01
--- orig/Fonts01	2018-02-04 18:59:10.000000000 +0100
+++ fixed/Fonts01	1987-02-12 10:59:04.540000000 +0100
@@ -3433,9 +3433,16 @@
         SWI     XOS_DynamicArea         ; create font cache
 
         STRVCB  R1,owncache             ; flag that we own the cache (r1 = 4)
+        BVS     exitinit                ; Failed -> bail
+
+        ; Re-read the minimum size
+        MOV     R0,#ReadCMOS            ; set cache size to configured amount
+        MOV     R1,#FontCMOS
+        SWI     XOS_Byte                ; read font cache size setting
+        BVS     exitinit
+
         MOVVC   R0,R3
         MOVVC   R1,#0                   ; Match initial size
-        BVS     exitinit                ; Failed -> bail
 
         ; R0 -> start of cache
         ; R1 = cache size
@@ -3453,6 +3460,9 @@
         MOV     R0,#4
         SWI     XOS_ChangeDynamicArea   ; ignore errors (eg. "Unable to move memory")
 
+        ; The DynAreaHandler_FontArea PostGrow routine has initialised the
+        ; cache by this point.
+
         MOV     R0,#4                   ; Font Manager uses dynamic area 4
         SWI     XOS_ReadDynamicArea     ; R0 --> memory, R1 = size
         STRVC   R0,fontcache
@@ -3468,8 +3478,6 @@
         rcmos   FontMax5,threshold5
         BVS     exitinit
 
-        BL      initcache               ; initialises workspace
-
 ; read territory-specific information (re-read on Service_TerritoryStarted)
 
         MOV     R14,#-1
@@ -8223,11 +8231,32 @@
         Pull    "pc"
 
 PostGrow_FontArea Entry "r0-r2"
+        ; We don't care what the minimum cache size is, it must be
+        ; less than the existing cache size.
+        ; If we're starting from zero size, initialise the cache, otherwise
+        ; expand the existing one.
+
+        ; in -
+        ; r3 = size change (+ve),
+        ; r4 = new size,
+        ; r5 = page size
+
+        MOV     R0,#4                   ; Font Manager uses dynamic area 4
+                                        ; out: r0 = start, r1 = size
+        SWI     XOS_ReadDynamicArea     ; R0 --> memory, R1 = size
+        BVS     UnknownHandlerError     ; For want of a better option FIXME
+                                        ; We don't get here if the area
+                                        ; doesn't exist
+
+        CMP     r3, r4                  ; Was zero sized?
+
+        STREQ   R0,fontcache            ; It doesn't move
+        STR     R4,fontcachesize        ; update size pointer
+        ADD     R0,R0,R1
+        STR     R0,fontcacheend         ; useful for later
 
-; in - r3 = size change (+ve), r4 = new size, r5 = page size
+        BLEQ    initcache
 
-        MOV   r1, r4                  ; there are, so inform font manager of size change
-        BL   SWIFont_ChangeArea
         CLRV
         EXIT
 
@@ -8236,6 +8265,8 @@
         CLRV                            ; don't need to do anything here
         MOV     pc, lr                  ; so just exit
 
+        ; FIXME - this may work, it may not. Who knows?
+        ; To be fair, it probably does.
 PreShrink_FontArea Entry "r0-r2"
         MOV     r1, #-1                 ; ask font manager for minimum size of font area
         MOV     r2, #0                  ; default value if no font manager

Sorry I didn’t see this earlier. Font_ChangeArea is disappointing, but here we are:

The latter, unused except by me

In fact the Kernel Font Cache Handler was removed from RO4.3 in 2002 so the Font_ChangeArea SWI became obsolete then but has persisted in RO5 for the usual hysterical raisins.

FontManagers therefore have to adapt to whether the Kernel is managing the FontCache DA (via Font_ChangeArea) or has to do it itself. And they do:

i.e. FM’s built-in DA Handler has been used for 22 years.

Bear in mind that “FontManager” may not be the module you are expecting. You can only rely on the API.