One for the future: "Retina" screen modes

Hi all,

OK, I’ll be the first to admit that this isn’t top priority, and I’m wanting something that hasn’t really been done yet… Nevertheless, there’s a problem here that I’d like to see addressed.

I’m quite a heavy Mac user these days, and as an Apple fan I’m more than a little interested in the new “Mac Book Pro with Retina Display”. For the uninitiated, this is a 15" laptop with a display that has a resolution of 2880×1800 pixels. It can scale its display in a variety of useful ways, though the default setting is to give you the equivalent of a 1440×900 desktop but with double the usual detail in both directions. The “Retina” reference is Apple’s way of saying that the pixels are too small to see at a comfortable viewing distance (which is true, though you can see them if you look close-up).

Anyway, this is unquestionably the most desirable laptop available today. It’s also one of the most expensive, and I’m not actually intending to buy one! Nevertheless, this is very clearly just the first taste of things to come, and in a year or two most Macs, at least, will feature this kind of display resolution. (Doubtless Windows PCs will eventually catch up too, though I have no real interest in those.)

Now, I’ve actually had this kind of display technology in mind for ages; it’s something I’ve been hoping would happen for years. The point is that RISC OS can actually support these so-called Retina displays already (or the support is 95% there, and fully usable). All you need to do is to edit the mode definition string (via the Mode menu item in Display Manager’s icon bar menu) to include “EX0 EY0” instead of the usual values of 1. Click OK and (to quote Steve Jobs) “BOOM!” Your desktop is in the same mode as before, but now with half the previous usable desktop space but double the previous level of detail.

My Iyonix monitor is a 1600×1200 model, so the best I can do in ‘high definition/Retina’ mode is the equivalent of an 800×600 desktop, which is too small to be useful. But once machines like the Retina Mac Book Pro are available for use with emulators such as RPCEmu, well… it’s a whole new proposition. Imagine how fantastic RISC OS would be, displayed at 2880×1800 (or better) in high definition.

By the way, for anyone reading this who doesn’t know, I’m the person who designed the RISC OS 5 icon set. And this very possibility is something I had in mind when designing those icons, ten years ago (if only because the technology in RISC OS already made it theoretically possible). So the RISC OS 5 graphical resources already support this: there’s a full set of icon sprites and window tool gadgets designed for EX0, EY0 screen modes, and it’d be great to be able to use them seriously.

So, what’s the problem? Two things, mainly:

1. RISC OS can’t support such big screen modes, as far as I know (admittedly I’m a little out of touch in some areas), and if you do define larger modes, you have to sacrifice colours to keep within the 8MB VRAM limit. What’s really needed is a removal of the VRAM limit (for emulated versions of RISC OS, at least) so that we can have displays of 2880×1900 pixels (and larger) in 16M colours.

2. There seems to be a bug somewhere which is currently preventing EX0 EY0 modes from working properly even when they should do. My testing is very limited, I’m afraid, but I’ve tried using such modes on RPCEmu (0.8.8 and 0.8.9) on my Mac (with RISC OS 5.17), and it causes a couple of problems:

(a) If no previous screen-mode change has occurred, then the Pinboard only plots the bottom-left quarter of each tile, leaving the other three-quarters of the backdrop pattern unplotted. NB This only happens if you haven’t done a mode-change previously. If you first open Display Manager and simply click Change (to change to the current mode), Pinboard then works OK.

(b) Much more seriously, the mouse pointer isn’t scaled to match the window. In other words, its bounding rectangle is confined to the bottom corner of the emulator window, and clicks similarly occur scaled within that area. This makes the system very hard to use.

These high-definition screen modes work perfectly on my real Iyonix, so I imagine that problem 2(b) is probably an emulator bug (or understandable oversight!). However, my Iyonix is still on 5.07 (I know, I should update…), so maybe a bug has crept into a newer version? (I doubt it, but I can’t test to be certain.)

Anyway, I thought the topic deserved an airing here at least. Clearly this isn’t urgent stuff, but if anyone’s doing work on VRAM-related issues and/or RPCEmu, I think it’s worth bearing in mind the potential for use of really outrageously high resolutions in the not-too-distant future.

this is a 15" laptop with a display that has a resolution of 2880×1800 pixels. It can scale its display in a variety of useful ways, though the default setting is to give you the equivalent of a 1440×900 desktop but with double the usual detail in both directions.

As display panels get better, the resolution increases. Apple’s “Retina” display is nothing particularly special. It’s just we’re used to lesser displays.

I’ll give you an example. My eeePC is 22.5cm diagonally, and 19.4cm across. This gives us a scaling factor of 1.15979.

The resolution, incidentally, is 1024×600. So if we divide 1024 by the 19.4cm width, my netbook’s display offers a horizontal resolution of 52.78px/cm.

Your Apple is 15". I assume this is diagonal. 15" is 38.1cm. If we apply the scaling factor above, this would make the largest edge (width?) be 32.85cm (assuming it is 16:9 factor). If this is correct, then your native resolution (2880) into the size, will give us a pretty neat 87.67px/cm. The effective resolution will be less than my netbook centimetre for centimetre as the display is doubled up from the 1440, but I bet it’s pretty fine to look at.

My older mobile phone, a Motorola Defy, has the resolution 854 pixels in its longest (horizontal) dimension (other way up as it is a phone!). This, I just measured, as being exactly 8cm. 854 pixels in 8cm gives a mind-numbing 106px/cm; twice that of my eeePC and storming ahead of Apple’s “Retina” technology too. And it was a damn fine display for reading manga. My current phone (Xperia Mini Pro) is roughly 480×320 in the same sort of size and, well, it doesn’t compare! Just a shame the Defy wasn’t up to HD video or it’d have stuck with it.

At any rate:

1. Apple is overhyped.
2. RISC OS needs to free itself from the shackles of VRAM limitations.
3. Screen modes will get stupidly large in the future, might as well plan for it now if it is convenient.
4. I think RISC OS possibly needs to be “taught” about 16:9 displays too.

Oh, and feel free to correct my maths if any of it, or the assumptions, proves to be incorrect. Meanwhile, everybody feel free to measure some of your kit to work out the px/cm and how it compares. (^_^)

RISC OS can’t support such big screen modes, as far as I know (admittedly I’m a little out of touch in some areas), and if you do define larger modes, you have to sacrifice colours to keep within the 8MB VRAM limit.

There’s no such limit in RISC OS 5, the Iyonix for example declares 32MB of VRAM. The particular ceiling with the emulator is that’s how much space is set aside in the (physical) memory map so the only way to increase it is to not emulate a Risc PC. Physical machines can only have 0MB/1MB/2MB of course because they’re further constrained by what’s wired up on the PCB.

(a) If no previous screen-mode change has occurred, then the Pinboard only plots the bottom-left quarter of each tile

An alternative way to provoke this is change to 1028×768 EX0 EY0, press F12 and type “WIMPMODE 28” at the command line, on return the tiling is wrong. I think I probably introduced that bug when cacheing the EX/EY settings (so OS_ReadVDUVariables isn’t thrashed when replotting the backdrop). I’ll take a look.

(b) Much more seriously, the mouse pointer isn’t scaled to match the window. In other words, its bounding rectangle is confined to the bottom corner of the emulator window, and clicks similarly occur scaled within that area. This makes the system very hard to use.

This seems to be an emulator bug. The mouse is properly clipped on a real machine. If you switch RPCEmu to “capture mouse” mode instead of “follow host mouse” then it is bound correctly. Perhaps you could feed this to the RPCEmu mailing list.

1. Apple is overhyped.

Yes, but still much nicer than Windows.

4. I think RISC OS possibly needs to be “taught” about 16:9 displays too.

No, but it think it could do with understanding non-square pixels. It does partially cope with 2:1 ratios (e.g TV modes for CRTs), but try turning it the other way round, e.g. 960 × 1080, and it goes haywire. (I tried defining such a mode because that should be able to be produced by a BB and work on my screen)

I think the mouse issue may be as a result of the ‘mouse hack’, that intercepts the OS_Mouse SWI going through the SWI vector and patches up the results (and maybe OS_Word/etc too). I wouldn’t be surprised if it assumes one output pixel=one mouse unit, or something.

I think I probably introduced that bug when cacheing the EX/EY settings (so OS_ReadVDUVariables isn’t thrashed when replotting the backdrop). I’ll take a look.

Having looked, it’s not (directly) my fault! The pinboard module caches the backdrop tile but only bothers to rescale it if it spots the mode changing. That’s all fine, but its discriminator is using OS_Byte 135 to see if the mode number changed. When mode specifiers are in use this is the address of a (static) buffer in the kernel.

Now, the kernel is helpful in that it dithers this buffer by 4 each time, so every second mode change you get back the original (eg. 0×12340000 then 0×12340004 then 0×12340000 then 0×12340004).

In my example sequence above if you go via a numbered mode you can end up back in a different eigen factor mode but with the same kernel buffer address. At which point Pinboard decides the mode hasn’t changed and doesn’t get the step right (leading to non redrawn chequerboard patterns).

There’s also a small bug in calculating the iconbar height, it reads the Y eigen factor but never uses the result! Fortunately typical mode dimensions versus the tile size mean this doesn’t actually show up. I think I’ll create a test tile to prove it is possible to get a gap above the iconbar with no tiling.

[me → ] 1. Apple is overhyped.

Yes, but still much nicer than Windows.

So is… <insert anything (Rule 34 included!)>…

Point still stands, though. Unless my maths is utter rubbish, I make it that my phone’s display kicks ass over Apple’s Retina display almost as much as Retina kicks ass over my bog-standard netbook’s display.
In other words, Apple is overhyped. Perhaps the only reason these sorts of displays are not more common is because people would rather look at 1440×900 in 19". It’s cool for watching animé to get a whole sort-of-cinema effect (I’m used to an 8.9" screen, remember!), but if we scale up from my phone, that sort of display size would be like a hundred thousand pixels!

One thing I noticed from my Zen (media player) is that pixel placement is important as well. I had an old media player (long forgotten, it was rubbish) with square pixels and a rather unfortunate obvious space between them. The Zen wasn’t high res, 320×240. It did, however, offer pixels not only close together, but I think arranged in a sort of triangle pattern so it looked nicer than its resolution would have suggested…

As display panels get better, the resolution increases. Apple’s “Retina” display is nothing particularly special. It’s just we’re used to lesser displays.

Are you trolling? Last year I splashed out on a 30" display. Below very specialist imaging devices usually with 5 figure our greater price tags, this is the highest resolution monitor money can buy – 2560×1600 pixels. Now you can get a laptop with 2880×1800 pixels – that’s more than more 30" monitor. It was the highest resolution laptop screen in the world and remains so several months after launch. It’s also considerably higher resolution than the overwhelming majority of monitors and HDTVs on all computers worldwide.

Even the new 13" Retina MBP has a 2560×1600 display – matching the resolution of my 30" desktop monitor. At £1449, the “entry level” model of that computer is cheaper than NEC 2560×1600 monitors even at Amazon prices and you get a 2.5=>3.1GHz / 8GB / 128GB laptop thrown in for free! Surely a bargain…?

http://www.amazon.co.uk/nec-Monitors-2560×1600-Computers-Accessories/s?ie=UTF8&keywords=NEC&page=1&rh=n%3A428652031%2Ck%3ANEC%2Cp_n_feature_keywords_browse-bin%3A1628696031

Even better, Apple have stuck with 16:10 aspect ratio screens in these laptops, rather than devolving to the stupid 16:9 resolution seen in many other vendors (and in Apple’s own now-rather-disappointing “cinema display” monitors).

The retina laptops absolutely are very special. And they’re exactly what we were talking about back in Acorn with EX0/EY0 settings back in the late 90s – how depressing it took so long for them to become a reality, and how depressing that people might describe them, after all these years of waiting, as “nothing particularly special”.

The thing that everyone’s forgetting about is that high density displays are exponentially hard to produce.

A 326 ppi 3.5" cell phone display isn’t hard nowadays, whereas a 220 ppi 15.4" laptop display very much is. Why? Yields.

So, the higher density you make a display, the more likely you are to have dead pixels – an 0.01 mm diameter defect might not cause a problem at the ~100 ppi of most current computer displays, but it’s more likely to cause a problem at the 220 ppi of the MacBook Pro Retina 15"’s display.

Now, consider that you’re going to get a certain number of defects in a certain area of mother glass. If you’re making smaller displays, you can get some displays out of the glass even with the defects, whereas if you’re making big displays, and have a defect, you have to throw away a lot more.

Compounding matters is the fact that there has historically not been much demand for panels of this density, due to a lack of OS support (and most people don’t want to use panels like this with everything tiny). So, panels with density even close to this have been relegated to, as Andrew said, 5 figure or greater price tag medical displays. (The sole exceptions are the IBM T221 and related clones), which fell to $9000 within a year of release, and older configurations fell to $4000 by the time they were discontinued (and were marketed towards medical, satellite imaging, CAD, and oil and gas applications), and the IDTech IAQX10 family of 2048×1536 15" panels, which were actually intended to be used in an EX0 EY0-like approach for displaying Japanese text (but that never happened), as well as laptop-based medical imaging applications, and you could get a whole laptop with one for about $4500 in Japan at launch.)

So, yes, Apple does have something really special here, it’s not just hype. They managed to put out a display surpassing most medical-grade displays in density, with quite good quality for a laptop display, and build a market for the thing. For that matter, the MacBook Pro “Retina” displays are the highest density laptop displays that are larger than 9" in current production, as far as I know. (Yes, I know, the iPad 3 and 4 have higher density panels, but that’s still Apple.)

So, has anyone tried RISC OS in an emulator at EX0,EY0 on one of these retina displays? How does it look? You’d probably want one of the latest HardDisc4 and ROM build so you’ve got all the Sprites11 files in there…

The trick is that it’ll look exactly like EX0,EY0 at any other mode, just more of it.

Let me grab a copy of the HardDisc4 and ROM, and RPCEmu for Mac, and I’ll post a shot.

The annoying thing here is that there seems to be some check preventing me from getting at any modes above 1920×1080 (and I can’t get at 1600×1200, either, which is a mode a real RiscPC can do (granted, I burned out my VIDC doing it, but it can do it)). Pixel rate limit or something?

(I did manually set rpc.cfg to vram_size = 8, for what it’s worth. System is showing as having 136 MiB RAM, and X1920 Y1080 C16M is a valid mode using 8100 kiB VRAM, which indicates to me that it’s seeing all the VRAM.)

Annoyingly, the Mac version of RPCEmu doesn’t seem to respect the mouse settings, so I always get fail there at EX0 EY0.

http://bhtooefr.org/images/temp/ro5retina.png (HUGE IMAGE served over slow DOCSIS warning)

You’ll notice that my desktop doesn’t look like you’d expect a Retina Mac to behave – that’s because I’ve disabled HiDPI support (or, in RISC OS parlance, gone to EX1 EY1).

Edit: It’s pixel rate. So, 2560×1440 image incoming.

Edit 2: 2560×1440 image in place.

So, you guys need to work on icons, that’s for sure. Otherwise, though, ignoring some RPCEmu limitations, it’s not bad.

The thing that everyone’s forgetting about is that high density displays are exponentially hard to produce.

It is not all negative: with higher density displays if they are physically smaller then the probability of a flaw is proportionally reduced, on the other hand yes smaller flaws will cause an exponential rise.
Also I wonder with such displays how visible dead or set pixels are? Dead pixels if stand alone could be very difficult to see. Set pixels will I’d have thought still be ‘obvious’.

I’ve had a couple IBM T221s with a few stuck subpixels, and you had to actively look for them. IBM actually relaxed their stuck/dead pixel policy for the T221 to 20 subpixels defective (which would be 6 and 2/3 pixels defective if whole pixels are defective). Although, their policy already was quite lax: http://web.archive.org/web/20040910042818/http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4U9P53