Big Mode on ARMBook (aka ARMBok) - developers please check your software

We are in the process of prepping the ARMBook/ARMBok laptops for launch, and one of the features is “big mode” which finally takes advantage of Acorn’s 180dpi screen modes that appeared back when the RiscPC launched. Until now, they didn’t make much sense, but the laptop’s high res screen finally makes them useful.

Since RISC OS 5, the OS has shipped with 180dpi icon sprites (aka Sprites11), but not all applications do. Also, some applications may make assumptions based on 90dpi when plotting text or sprites.

We’d gently ask any current developers to please check their software in 180dpi screen modes, and (if necessary) make updates available. To check this, it is very easy as follows:

1) Press menu over the Display Manager in the bottom right hand corner of the screen.
2) Slide to the right off “Mode” and you’ll see the mode-string displayed for the current mode.
3) It may end in EX1 EY1 – if so, change this to EX0 EY0. Otherwise add " EX0 EY0" (no quotes) on the end.
4) Press return.

You’ll now be in the same resolution as you started, but at 180dpi. This will cause everything to look larger, but also much nicer (eg. text/font rendering).

You can now start your program, and check that it operates as normal. It is also worth switching to an EX0/EY0 mode whilst the program is running, to make sure it redraws correctly.

Things to watch out for are plotting sprites or text. In most cases this will work fine, but it is easy to assume that things like font handles are still valid over mode changes etc.

For example, we found that Messenger Pro created a font handle for text at “current mode” DPI when first opening a viewer window, and never performed any further look-ups. After switching to “big mode”, the font handle was still being used, resulting in 90dpi text on a 180dpi screen. The solution was simply to update the font handle before starting the redraw loop (as other parts of the software already did).

The vast majority of other programs that we have tried have been fine, but if developers could please just run their programs to make sure, that’d be really helpful. It is simply a case that this is the first time it has been sensible to use these modes as primary desktop UI.

Quick “morning after” followup comment – non-developers (users) can also run the above test with their programs, and let devs know if there are issues. You can also post success/failures to this thread so that we know.

VRPC-DL 5.25 14 Aug 2018) Ex 0 Ey 0

A quick look at StrongEd 4.70a12 seams to have drawing problems.
Zap rick-03 text drawing problems.
Sargasso 2.02 (5 July 2009) printing the text small!

As eyes get older with age :-(

As a note – from the Acorn News Group – is there anyway of increasing the size of the Caret – so it is easier to see?

A RISC OS Retina display!! Just needs hardware that could drive a 4k monitor!!

I have given “EX0 EY0” a try on the Titanium working at 1920×1200 and it looks very good indeed, but it is not really a practical proposition running a Desktop effectively at half those values.

There is no EX or EY configuration available by default so the PreDesk Choice has been manually edited. The Titanium booted without disaster.

There are a couple of instantly noticeable features.

StrongED 4.69f11 has problems when using its bitmap fonts!

The System Font needs updating.

Otherwise it’s brilliant, I can read the text in the Text filetype icon.

Raspberry Pi can drive a 4K monitor, albeit only at 25Hz or less.

Zap rick-03 text drawing problems.

By extension, this probably means anything using ZapRedraw…

Regarding ZapRedraw, I made a few fixes (see post) which Rick included in Zap rick-05 ( and ZapRedraw 0.50).

I think the 16×16 fonts in latest StrongEd were OK – Fred had a play at the eXperience last weekend.

Zap also seemed OK in a quick test, but may be font related also.

Dave/Clive, as you both (probably) know, ARMX6 quite happily supports 4k, so it is entirely possible to use EX0EY0 modes on the various 24" 4k screens out there. However, ARMX6 also offers a range of in-between modes better suited to 27/28" 4k displays too.

Zap also seemed OK in a quick test, but may be font related also.

Just to let you know – Zap has a variety of redraw methods. VDU font, Zap font (the default), and outline font. Bitmap or anti-aliased.
Of the bitmap styles, there are substyles – scaled, 1dpp, 2dpp. And of the anti-aliased, VDU or DSA.

It’s complicated. ;-)

However, ARMX6 also offers a range of in-between modes better suited to 27/28" 4k displays too.

I have a huge range of modes on my 43" 4K screen on my Pi. Had to write the MDF for them myself, but it wasn’t hard. RISC OS does the scaling, and the results are excellent. The screen sees 4K all the time, but from the apps pov it’s whatever you choose.

I tried this with SDL, and while it’s usable, the window size isn’t consistent when using different resolutions. This patch should fix that.

(As an aside, it would be good if someone more experienced than me could take a look at the other patches I’ve submitted, to ensure I haven’t done anything wrong. They can all be found here. )

Thanks Cameron :)

As an aside, it would be good if someone more experienced than me could take a look at the other patches I’ve submitted, to ensure I haven’t done anything wrong.

I’ve had a quick read of them (without looking at the wider context!) and couldn’t spot anything obviously wrong.

What is the actual resolution of the ARMBook? One of my apps has relatively tall windows so I’ll need to make sure that it fits :)

It’s a 1080p (1920×1080) screen, so yes, long windows could be a problem.

The vast majority of RISC OS software is designed to be OK at 640×480 (MODE 27/28), so it shouldn’t be a problem. However, some targets 800×600 (MODE 31/32) minimum, and that could be a problem vertically. When writing software that might have long windows (eg. Choices windows), I’ve tended to arrange the sections sideways when the windows gets full, as monitors are wider than they are tall.

Note that “Big Mode” is optional, but a lot of RISC OS users don’t have 20/20 vision, so this seemed like an opportunity to use a feature that Acorn added back in the day, but has never really had the love it deserves. The improvement to picture quality is also a nice bonus, if you can live with the reduced real estate.

Off-topic. Anytimes “EX2(3) EY2” are also usable. ;-)

I did a very quick check of Organizer … and all seems ok except when plotting the iconbar clock, which I will investigate.

Thanks Martin – that sounds like a “re-using font handle” issue like in Mpro. Unless anyone has a better suggestion, I simply did a font_findfont SWI (with 0,0 for dpi – use current) just before my redraw-rectangle loop in the redraw function.

What is the actual resolution of the ARMBook? One of my apps has relatively tall windows so I’ll need to make sure that it fits :)

One approach is to check if your window would fit in the current mode and add a vertical scrollbar if necessary. The Filer configure plug-in (amongst others) does this.

I think it already does; I just need to make sure (my RISC OS machine is currently packed away as I’ve had a guest here for a week and needed the desk). To be honest, I think the most major issue I’m going to have is lack of 68×68 icons :)

The tricky part (I find) isn’t just 68×68 icons, but rather making sure the sprites are created as 180dpi not 90dpi. I wonder if you could convert from 90dpi via ChangeFSI with 50% scale and “use current mode” – would the detail be preserved, or would it scale first then “pixel double” to 180dpi?

Edit: I can confirm that this seems to work. I took a 90dpi image (a photo) and used an old 2003 version of !ChangeFSI I had lying around (VRPC). I selected the built-in 1:2 scaling options for x/y in !ChangeFSI and changed the current mode to EX0/EY0.

Loading the sprite in resulted in an on-screen image half the size of the original (to be expected). However, zooming in (x2) retained the original image quality (compared side by side). This means that all the original pixel data must have been retained in the half-size 180dpi version, as intended. This means that you can create double-sized images (or, perhaps more importantly, convert pre-existing images) in EX1/EY1 90dpi modes, then convert them to 180dpi with full detail.

That just leaves the problem of masking/alpha channels… For that, I suspect we need a “change DPI” option in !Paint. Isn’t someone working on !Paint right now?

DPScan will also change a sprite (or any image that supports dpi) from 90×90 to 180×180. You also have the various image transformations available, of course.

Just tried this on my ARMX6 and noticed Sargasso gets its fonts messed up. they become ultra small.
Oragizer digital clock is also messed up. Just for info.

ChrisJ – can it preserve sprite masks (and alpha… dreaming!)? That’s currently my big bugbear with ChangeFSI?

can it preserve sprite masks (and alpha… dreaming!)?

Ordinary masks should be ok. I have just taken an application masked sprite (34×34), scaled it to 200%, and resaved it. The now 68×68 sprite has its mask retained. You could also set it to 180 dpi before saving. I am not sure how it would behave for some of the possible transformations (eg colour depth).

Alpha masks are another thing. The internal data structures could be adapted for 8-bit masks, but there is an awful lot of code that would need modifying, including the display code.