Why does the high-vector build of Basic allow you to fail to read zero page? Why doesn’t it just read zero.

It does, or at least High Vector RISC OS does, if you’re not running ZeroPain.

ZeroPain exists because reading from NULL is generally an indication that the developer has either made a mistake or is being “a bit too clever”, and when testing their code (most) developers like to know about it so that problems can be fixed before they get out into the wild.

When shifting the mouse over ‘Colours’ in the iconbar menu, MiniCal generates an Internal error 780: abort on datatransfer at &FC17A7C4.
*where reveals: &FC17A7CC is at offset &0001D608 in module 'WindowManager.

This is on a 4té2, RISC OS 5.31 (22-Jul-2024).
Clicking Continue shows the submenu.

Why does the high-vector build of Basic allow you to fail to read zero page? Why doesn’t it just read zero.

It does, or at least High Vector RISC OS does, if you’re not running ZeroPain.

Just for accuracy: most of the fake compatibility page returns 0, but not the very beginning, which has some non-zero words and a string “NULL POINTER DEREFERENCE” because peeking address zero on RISC OS 4 or 3 would have returned an LDR PC opcode from the vectors, because

freddy%=TRUE
myaddr%=0:REM Ooops
IF freddy% AND !myaddr% THEN PROCdo_something()

would behave differently if address &00000000 contained zero compared with RISC OS 4 or 3 otherwise.

But the main takeaway is probably: best to tidy up the source program to not dereference NULL pointers, whatever the language.

Because people don’t tend to like programs randomly bombing out – who knew?

Quite.

[voice over]

“No one would have believed in the last years of the twentieth century that this…” [enough]

ROOL get around to putting in place something that starts to enforce something that Acorn specified 20 years previously, and then over a decade after that, with many software bugs squashed as a result someone is grumbling that this is so?

Aussies called us whinging poms ‘cos we’re never happy…

It never gets fixed/updated, it sucks.
They fixed/updated it, now it sucks.

And so on. 😋

Paul reported

Internal error

Thank you. MiniCal was tested on 5.28 in RPCEmu, but there is extreme tricksyness required to make colour menus work with 24b colours as Acorn forgot to implement them in menus in 1994, and no one’s fixed it since.

I don’t have 5.31 but judging by 5.28 that address seems to be very near Wimp_ResizeIcon which that line calls. Has somebody changed anything in the Wimp regarding the implementation of menus or the behaviour of ResizeIcon?

Paul, would you be so kind as to try the MenuBadges demo program on your 5.31? That does great violence to menus so will eliminate some possibilities if it works as intended.

[Also I’ve just realised that MiniCal relies on the wimp sprite “⇒inverse” so I’ll have to theme it.]

Scrub that

Can’t be bothered with whatever’s happened to 5.31 so:

Update later today NOW

[I ought to work ought what’s happened to 5.31 as variable-length colour menus are still terrifically useful, but I don’t have time this year]

Thank you. MiniCal was tested on 5.28 in RPCEmu

Interesting. It works on 5.29 (26th March 2024) on a 3B+.

Update: I had to hack my boot to force Boot$OSVersion as I didn’t have 530 set up in !Boot ¹, I just grabbed a new ROM and…

RISC OS 5.31 15th December 2024, seems to work as expected on my 3B+ with no errors being reported. I have just set background blue, text white, highlight yellow.

It fails on startup (the IF(F%AND1)AND!E%=388 thing) if compatibility page is off. If it’s turned off after loading, then the menu appears okay, so it’s not that.

<shrug>

Day #15: StatusHelp

As you guys don’t deserve expect working code, how about a module containing absolutely no code whatsoever?! StatusHelp supplies the *Help for the Kernel’s *Status/*Configure keywords that have been missing since 1987.

There’s also a new version of MiniCal, plus I’ve made SaveToPath even more powerful.

Rick ruminated:

seems to work as expected

cookie-monster-shrug.gif

Thanks Rick. The new version has no colour menu. I do want to make sure they can work correctly, as a colour dialog (as above) doesn’t work well when there’s a variable set of colours, viz:

This kind of thing needs to be a menu

I’ve long that (much like MenuState and MenuBadges) it would be helpful to create a module that automates the creation of 24b colour menus. A project for the new year.

missing since 1987

To be fair, we didn’t have the largest ROMs to play with. Inexcusable from then on!

With MiniCal 1.02 (30 Jan 2024) on Titanium RO5.31 (07 Nov 2024) with WindowManager 5.87 (22 Apr 2024), moving the mouse over the Colours menu, and even changing the colours, works fine here. Perhaps the Abort problem is something more subtle than just by a RO5 update?

We’d now need the OP to try it with a freshly booted machine, and if that fails – since it is just BASIC, to try it on a machine with Esc hammered during boot (to skip the boot sequence).

That way it ought to be possible to determine if it’s the 4té ROM or something loaded at boot or…

Paul, you game? ;)

Day #16: !SprTypes

aka Not what you’d want !Paint’s “Create” window to look like

The UI is complicated because Sprite Types are complicated

I’ve also removed the pain from half-a-dozen Basic programs, if you care about that Shrödinger-problem – 5Launcher, LangTest, MenuBadges demo, SaveState, FilerCloser, and Bowdler.

Not shown: The several billion 16bit formats possible when a Type 5, 10 or 16 has a 256-entry VIDC20 palette.

!PalEd is not being released this Christmas

The UI is complicated because Sprite Types are complicated.

Hmm, how many of those can SpriteOp actually cope with, I wonder?

The UI is complicated because Sprite Types are complicated

I tried to understand most of them in my Java lib to read sprites, but…I don’t believe all of them work properly. And some of those listed I don’t remember, probably some of them you have invented and not documented properly and supplied enough examples :-)

Steffen suggested

some of them you have invented

Only one: I’m the author of VVS, which was created in the mid 90s.

Types 1-6 were RiscPC. Types 7 & 8 (CMYK & Packed) were originally coined by Computer Concepts IIRC. Type 9 (Compressed) was Acorn’s (whose implementation was badly botched and was removed by ROOL, erroneously IMHO). Types 10 (64K) and 16+ are “RO5” but I’m not sure where and when they were introduced – 64K and 4K are VIDC20 after all so may date back to 1994’s RiscPC internally at Acorn.

RO4.3 supports types 1-7 & 9. RO5 supports 1-6, 10 and 16. The YCbCr are ROOL I think, but I don’t think they’re supported at the API level (I may be wrong about that).

A redesigned SpriteExtend is long overdue, but it is possible to render types 1-8, 10 and 16+ using SpriteExtend if you know what you’re doing: (and some arrangements of VVS)

Type 16 (4K) being displayed in RO4.39 using its standard SpriteExtend

VVS: Since it supports up to 8,160 bits per pixel, it’s rather difficult to support at the ColourTrans/SetColour/GCOL API level.

SpriteExtend: I’m unconvinced by SX’s blit “compiler” – it produces inefficient and (for the majority of its life) buggy code. The ColourMap interface is particularly inefficient and fragile. But the fact that the ‘compressed’ scanline buffer API wasn’t exposed (and was then excised by ROOL) is a particular failing that should be addressed – marvellous things are possible when SX delegates to a scanline buffer provider, and I particularly look forward to implementing the PostScript-ImageDictionary/VVS-Associated-Mask capability of having differing resolutions for image and mask pixels (which Vantage supported from 1994).

Since it supports up to 8,160 bits per pixel

543,338,496,000 cookies? ¹
Is that not just slightly overkill?

¹ I swiped “colours”, my phone thought otherwise…

Rick regarded

slightly overkill

Your maths is off: Half of those bits are non-colour bits, so only 4,080 bits can be colour. So that’s a mere 15,936,109,640,703,621,012,752,574,321,237,554,665,831,974,015,005,245,672,366,843,922,179,472,472,710,532,483,655,194,273,910,485,204,176,179,606,848,743,634,612,847,495,089,504,907,337,390,687,375,661,701,628,814,040,779,780,731,175,847,802,583,837,642,186,194,275,970,639,891,757,604,619,122,915,614,513,331,181,864,690,316,568,260,144,163,646,023,616,089,954,895,763,246,438,737,708,556,789,910,858,596,903,792,403,822,048,763,823,652,734,835,666,823,434,441,825,156,140,494,831,894,328,253,830,856,704,955,633,542,903,354,118,983,365,410,764,851,249,486,057,097,083,045,909,638,791,074,716,789,191,819,766,068,135,818,609,879,481,126,307,195,035,561,386,611,512,577,355,205,840,814,458,761,778,763,049,526,929,105,181,703,061,426,647,204,915,138,135,473,146,446,994,415,257,269,475,475,843,240,290,443,301,309,463,864,235,014,545,373,700,343,808,523,255,731,332,734,723,423,312,342,807,042,132,095,606,659,037,402,274,857,786,890,204,152,988,973,619,457,763,899,340,196,769,103,741,310,324,090,752,438,267,076,215,074,677,895,878,187,321,163,811,566,921,736,973,930,885,575,336,048,417,074,507,232,478,225,740,401,663,142,208,601,058,173,227,172,964,675,074,385,373,276,528,497,961,077,191,411,153,879,257,902,571,352,186,992,009,626,105,357,825,437,926,817,348,960,354,056,903,440,098,072,098,692,318,664,491,131,583,697,536,844,250,758,643,339,041,986,988,070,348,038,795,061,026,507,042,706,414,310,025,735,042,516,682,386,549,573,051,762,656,509,436,659,646,864,484,773,992,692,236,510,159,370,773,038,594,649,927,491,807,954,191,635,151,709,189,868,007,303,973,640,312,364,678,999,645,717,438,254,334,873,104,930,242,010,546,176 shades (1.5e1228).

The explanation: VVS can have 0-255 colour channels and 0-255 non-colour channels per pixel, whose components are 8 bit or 16 bit. I can’t think of a use for 255+255×16b, but it can do it.

However, I absolutely can think of a use for 6+1×8b which is 56bpp. I needed a format that could encode any possible TIFF as a Sprite. DeviceN is scary. Vantage supported the tiled variant too, which turned out to be 5% faster for arbitrary affine transformations due to cache coherence but was otherwise bloody inconvenient, so I’ve deprecated that feature. Too hard.

I could think of uses for more than three colour channels. CYMK is four. Add alpha we’re up to five.

More advanced cameras might be able to record non-visible wavelengths like UV and IR and may wish to include this separate to visible rather than mashed into it, and so on.

But [BIGNUM++] shades? Definitely overkill!

Rick remarked

uses for more than three

Yes, VVS is generally useful as a representation format, but RISC OS doesn’t have an abstracted pixel writer (except for hline which despite being part of the VDU code, its abstraction isn’t used by VDU, so can’t abstract). As such, the only composite rendering component that can be easily accommodated in >32bpp is Draw, hilariously.

VVS 3+0 additive with palette is equivalent to Type8 (Packed) without, 3+1 additive is Type6, and 4+0 subtractive with a suitable palette is equivalent to CMYK. 6+ subtractive can be Hexachrome. Colour channels can be invisible (by having an entirely black additive or entirely white subtractive palette for that channel) but yes, non-colour channels can encode other stuff like low-precision depth. I’ve a flag reserved for 32b components, but that seemed insane in 1995.

Mind you, I now do RGBe HDR Sprites using MetaSprite, so that doesn’t need its own type, and although it only has 8bits of precision per component, the exponent is vastly larger than you’d need to encode all luminances known to science:

an HDR sprite whose pixels can encode luminances that would not fit into 32b

BTW: RGBe HDR can also apply to paletted sprites… which means you can have a 16 colour icon, some of whose pixels are hotter than the surface of the sun.

Should you need that kind of thing.

Continuing my mission to desemminate apostasy among the RO faithful by patiently explaining how complicated the API ACTUALLY is…

Day #17: !ScaleFac

• Calibrate your monitor so that “100%” means “actual real size”!
• Introduce great uncertainty into what a SpriteType that claims “90dpi” actually means!
• Expose how many authors didn’t read the PRMs! (spoiler: almost every man-Jack of them)

This allows you to set a custom DPI or calibrate the size of your monitor such that the OS knows how big your pixels actually are (or how big you want it to think they are) in the real world.

If your believe that MODE27 is “90DPI” or that there are 46,080 Draw Units to an inch, or 1,814 Draw Units to a millimetre, you are wrong (in general, though you’re probably right by coincidence in your case).

About !MiniCal version 1.03 (sorry, I was away for a few days): I’m happy to report that it now works very nicely on my setup. Thanks!

Expose how many authors didn’t read the PRMs! (spoiler: almost every man-Jack of them)

I think I recall someone saying that the PRMs aren’t totally accurate and that what the API did is the real answer.
Personal opinion – two answers? Pick one that everyone agrees and bend the other end to fit the one you chose.

Steffen suggested

some of them you have invented

Only one: I’m the author of VVS, which was created in the mid 90s.

It was 2018 when I digged deep into the Sprite formats both for the first and the last time, so I have forgotten most of the details now. What threw me off-track was “Compressed” that I didn’t remember at all, as well as “RGB packed” – is the wording from somewere half-way official? Because both ROOL Wiki and RISC OS Six doc disagrees.

Steve suggested

Pick one that everyone agrees

As James O’Brien is fond of saying:

This isn’t an opinion, it’s just counting

Let me walk you through it:

• It is defined that there are 256 Draw Units to an OS unit [PRM 3-525] (this makes 32b DU values ±23·8 fixed point OS units, in fact)

• It is defined that there is a small-integer power of two OS units to a pixel [PRM 1-710] (the Eigenfactors)

But how big is a pixel? Contrary to what “everyone agrees”, there isn’t a temperature-controlled platinum bar in a Parisian vault bearing the legend “4608KDU”. There isn’t even a “1m” bar any more:

• It is defined that a metre is the distance travelled by light in a vacuum during 1/299792458s definition

• It is defined that there are 25.4 millimetres to an inch [British Standards Institution, 1930]

• It is defined that there are 72 PostScript Points to an inch [Adobe “Red Book” p183]

• FontManager uses hexadecipoints for font sizes [PRM 3-419] and millipoints for coordinates [PRM 3-404]

• Therefore there are 72000 millipoints to an inch, or 2834.645669291339pt to 1m [counting]

But for FontManager to position those SI-derived font sizes at those SI-derived coordinates on your screen, it needs to know how big your pixels are. This is the ScaleFactor that FontManager maintains.

• ScaleFactor defaults to 400 [PRM 3-448]

• Therefore there are by default 400 millipoints to an OS unit, and so there are 72,000/400 OS units to an inch – this is the “notional” 180 DPI [PRM 3-525]

As should now be obvious, Font_SetScaleFactor changes the real-world size of OS units on your machine – it does not change the fundamental definition of the unit of length in the Système International d’Unités, even if they are French and you are British.

But if you believe it does, you probably voted for Brexit.