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.

Thanks for that. What does “2xcurrent_size-new_size” mean?

Regardless, I feel completely unencumbered by the necessity to cater for 30 year old devices or modules (I hope old programs will still work). There’s a reasonable chance that it might be possible to work backwards, but I’ll leave it to people who are interested in such things (it’s not like RO3.11 stopped working exactly the way it used to).

I’m still developing for a Pi 3, which is already two generations old, but aiming for something that might continue to work in the future.

What does “2xcurrent_size-new_size” mean?

My take is that it will require you to double the current size, then subtract the desired size from it (working from left to right, as in two times current-minus-new, results in negative numbers). I have no idea why you can’t just give it the new size (smaller or larger) and it either works or errors. It is quite a peculiar API.

Edit a little later:

Actually, FontManager says this:

; In    R1 = new font cache size (-1 ==> don't change size)
;       actually, there's a bug: if R1 > current size, then R1 must be altered to currentsize - | R1-currentsize |

Assume current is 20, you want it to be thirty…

2 * (20 - 30) = -20  ; can't be right
(2 * 20) - 30 = 10   ; weird, but okay
20 - (30 - 20)       ; gets the same result

The “two times old minus new” is easier to work with than the “old minus new-minus-old” given in FontManager.

Well, the alternative is that you let the FontManager module create and manage the DA and simply try to change its size through normal DA SWIs. Then nothing calls Font_ChangeArea.

The alternative makes more sense than having something else fettle around with memory allocations that it has no business with.
FM should deal with its memory requirements, the end.

Simon suggested

I feel completely unencumbered by the necessity to cater for 30 year old devices or modules

Well hang on, we’re talking about what the interfaces are. You don’t get to move the OS_Byte reason code into R6 and claim anything using R0 is “30 years old”. All the interfaces are 30 years old!

This is what the API is, and hence anything written by anyone at any time adheres to these APIs. Even when it’s inconvenient for you.

Sorry if that’s overly harsh but the APIs are not negotiable. I may have misunderstood you.

Rick ruminated

It is quite a peculiar API.

I’d have started with “bas*ard” and then lost my famous composure.

It’s a stupid bug which instead of being deprecated when it was noticed, was instead adopted. Fortunately it’s only relevant to FontManagers that wish to leave Font Cache sizing to the Kernel. FMs are entitled to simply delete the existing DA#4 and create their own in those Kernels that do have a built-in. And as I say, that’s only really ancient Kernels like RO3… and RO5. <shade – but it’s true>.

and hence anything written by anyone at any time adheres to these APIs

Let’s hope the documentation is never ever wrong then. ;)

it’s only relevant to FontManagers

You say that as if there are several…?

You say that as if there are several…?

In Nemo’s world, there are!

<enigmatic>There are several<\>

It’s an undocumented API (except for one StrongHelp page), and it’s not even used by the standard FontManager.

Of course APIs have to be conformed to, but having the kernel be aware of certain user modules is very bad practice. Especially when the module is quite capable of managing its own DA.

It’s an undocumented API

You mean publicly undocumented. It’s quite possible those writing font managers (all those others I’ve never heard of ¹) may have had access to such documents and/or access to the font manager sources to see what was actually going on.

it’s not even used by the standard FontManager.

Perhaps it was a leftover from the RISC OS 2 era bitmap FontManager?

is very bad practice

Remind me, how many times did Gerph use the word “collusion” when talking about all the sucky parts of the OS?

¹ While there are various font handlers, such as the one that was in Oregano to use TrueType or whatever it was, I’m only aware of the two Acorn system-wide FontManagers – the ancient bitmap one and the outline replacement. And no, nemo’s one that can do Arabic and Mongolian and Akkadian correctly doesn’t count as it’s only wide on his system. 😋

And no, nemo’s one that can do Arabic and Mongolian and Akkadian correctly…

It’s presumably also under maintenance. As in, he could change a dozen lines or so to make it not rely on a kernel knowing about font managers at all.

Simon said

it’s not even used by the standard FontManager.

O_o

We must be talking at cross purposes. We can’t be talking about Font_ChangeArea, which is a required FontManager SWI in all versions of NCOS and RISC OS except RO4.3+ and RO6.

I haven’t checked RO5.30, but I have checked all other versions, and I’ve just made a version of 5.28 that beeps whenever that SWI is called and guess what?!

Forgive my confusion, Simon.

Any FontManager that is designed to be RISC OS compatible must either implement Font_ChangeArea or delete the Kernel’s DynamicArea #4 and create its own. Now you may have decided to do that, but please don’t state things that are demonstrably false in the 23 versions of the OS I’ve reversed, and the 47 intermediate versions that I’m aware of that are clearly the same.

Even if you limit yourself to RO5 because “modern!”, all versions of that have the FontCache Dynamic Area Handler in the Kernel – so Font_ChangeArea is required.

If you are making an RO5-flavour Kernel, that reports itself to be 5.xx, or returns &AA from OS_Byte,129, then you SHOULD provide a Kernel FontCache because that’s part of the RO5 API… so far… unless 5.30 lost it, I dunno (I haven’t the heart to check).

Rick remarked

I’m only aware of the two Acorn system-wide FontManagers

There have been countless revisions of three (four if you’re generous) architectures:

FM1

Arthur’s bitmap-only FontManager, that used pre-rendered antialiased glyphs generated by a pen-nib & path system

FM2

The RISC OS 2 (sometimes “Acorn Desktop Publisher”) FontManager. Introduced outline fonts.

FM3

I often refer to this as Dizzy’s FontManager – the most significant FontManager architectural change to date. Introduced Language fonts, Alphabet fonts, new bitmap format, Encodings, Root Directory Messages, and other stuff I’ve forgotten.

FM3.5

RO5’s mess. Not sure whether the hackery was done at Pace (likely) or at Acorn in the STB era, but a rather desultory bit of butchery that badly implemented sort-of-Unicode character set support (only) while completely breaking many things including totally destroying Alphabet fonts, replacing Dizzy’s carefully constructed font file disambiguation mechanism by an effective random number generator, and becoming incompatible with all existing font installations except by coincidence/luck.

You may believe there are other architectures in existence, but I couldn’t possibly comment…

he could change a dozen lines

If I were stupid enough to write a new FontManager I imagine I would check whether the Kernel manages the FontCache and implement ChangeArea accordingly, and if not, create the DA and have my own handler. I just want everyone to understand that I am not claiming that this is exactly what I’ve already done or suggesting that this might be why I know about this stuff.

OTF, TTC, TTF … Yes Please!

Please

LOL