I give up!
Pages: 1 2
Simon Willcocks (1499) 532 posts |
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? |
Piers (3264) 45 posts |
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. |
Simon Willcocks (1499) 532 posts |
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. |
Piers (3264) 45 posts |
A lower case letter, at that size, will be a different bitmap size. |
Simon Willcocks (1499) 532 posts |
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. |
David J. Ruck (33) 1637 posts |
Just display it as RiSC os, can’t be any worse than JaGUar :) |
Simon Willcocks (1499) 532 posts |
I think I’ll try to track the bug down instead, tyvm! |
Simon Willcocks (1499) 532 posts |
OK. So. Turns out there are two different The former consists of the kernel having knowledge of the FontManager (it calls the publically undocumented The latter, unused except by me because the legacy kernel initialises the dynamic area in Oh, joy! |
Rick Murray (539) 13862 posts |
🤦 Undocumented stuff “for internal use only” is naff and lazy.
Put the kettle on, you’ll need tea for this. Lots and lots of tea. |
Simon Willcocks (1499) 532 posts |
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.
|
nemo (145) 2571 posts |
Sorry I didn’t see this earlier. Font_ChangeArea is disappointing, but here we are:
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. |
Simon Willcocks (1499) 532 posts |
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. |
Rick Murray (539) 13862 posts |
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. |
Simon Willcocks (1499) 532 posts |
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. |
Rick Murray (539) 13862 posts |
The alternative makes more sense than having something else fettle around with memory allocations that it has no business with. |
nemo (145) 2571 posts |
Simon suggested
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
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>. |
Rick Murray (539) 13862 posts |
Let’s hope the documentation is never ever wrong then. ;)
You say that as if there are several…? |
Gavin Crawford (560) 36 posts |
In Nemo’s world, there are! |
nemo (145) 2571 posts |
<enigmatic>There are several<\> |
Simon Willcocks (1499) 532 posts |
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. |
Rick Murray (539) 13862 posts |
You mean publicly undocumented. It’s quite possible those writing font managers (all those others I’ve never heard of 1) may have had access to such documents and/or access to the font manager sources to see what was actually going on.
Perhaps it was a leftover from the RISC OS 2 era bitmap FontManager?
Remind me, how many times did Gerph use the word “collusion” when talking about all the sucky parts of the OS? 1 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. 😋 |
Simon Willcocks (1499) 532 posts |
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. |
nemo (145) 2571 posts |
Simon said
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
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…
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. |
Gavin Crawford (560) 36 posts |
OTF, TTC, TTF … Yes Please! |
nemo (145) 2571 posts |
LOL |
Pages: 1 2