Using Tiny Displays with RISC OS

I have been using the Pi2 with an older 17 inch LCD monitor. While that works well enough, my intent always was to use RISC OS and the Pi2 in a homebrew tablet configuration. So, I have a very small 1024×600, 7 inch LCD. I really didn’t hold much faith that it would work, and at first it didn’t. After some digging, I put the following stuff in config.txt, in addition to what was already there:

max_usb_current=1
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
hdmi_drive=1
hdmi_ignore_edid=0xa5000080
hdmi_group=2
hdmi_mode=87
hdmi_cvt=1024 600 60 3 0 0 0

With the new config.txt, RISC OS was displayed on the tiny display in 1920×1080 resolution. I guess I get that the GPU is shrinking/growing stuff, but it really looks pretty good! I downgraded to 1280×720 though – so I could take my nose away from the screen! So the screen is taken care of, and now I need to find a little box that will accommodate both the 7 inch screen and the Pi2, and maybe some batteries. I’ve got a tiny 2.4 GHz keyboard that is working well with it, and has built-in thumbpad, but it would be nice to get the touchscreen going. WhAT’S the chance of that?

This small display is one of those little monitors meant for car TV, real cheap at about 50 clams.

There is a chance if your touchscreen is a HID-Mouse…
https://www.riscosopen.org/forum/forums/5/topics/3186?page=1

There is a chance if your
touchscreen is a HID-Mouse …

@Raik: Thanks for the link. These little touch-screens are capacitive and use a multi-touch protocol. They are USB connected (and powered thru the USB, so there are only HDMI and USB connectors). The touch screen works great with Rasbian, so maybe I’ll put the other uSD for Rasbian into the slot, and get some USB dev info. Online specs seem sparse for these things, but a short search indicates maybe an ILI-9481 controller IC.

RiscOS looks good on it, but my eyes aren’t what they used to be. I find myself middle-click scaling a lot!

Have you try USBDescriptors from https://www.riscosopen.org/forum/forums/5/topics/3186?page=2#posts-41897 ?
Maybe the output helps to find a solution.
Not sure if I understand you right. I have a comparable display and use a MDF with 1024×600...
Maybe the Touchbook one is working (I use a other one but I’m not at home.):

#1024 × 600 (98Hz)
startmode
mode_name:TouchBook
x_res:1024
y_res:600
pixel_rate:64000
h_timings:3,39,0,1024,0,3
v_timings:1,7,0,600,0,2
sync_pol:3
endmode

Not sure if I understand you right. I have
a comparable display and use a MDF with 
1024×600 ...

The back of the LCD is clearly imprinted (on the PCB) with “1024×600 LCD” – yet it displays RISC OS in 1920×1080 mode quite nicely. I’m not sure I’m wrapping my head around that one either. GPU magic, I guess …

Yes!
On a Pi the monitor output is not controlled by RISC OS.
The Pi will output what is set it config.txt or when no setting there (the default) it uses EDID and the GPU outputs that, scaling whatever screen mode RISC OS generates (RISC OS defaults to 1920×1080).
i.e. For you the GPU is scaling 1920×1080 to 1024×600 and as you’ve seen it does a very good job of it:-)

For you the GPU is scaling 1920×1080 to 1024×600
and as you’ve seen does a very good job of it:-)

@Chris: Amazing! I sure would like to see an in-depth explanation of this technique, and exactly how it’s done. It’s counter intuitive to my experiences …

Amazing! I sure would like to see an in-depth explanation of this technique, and exactly how it’s done. It’s counter intuitive to my experiences …

The instructions are in the closed source “start.elf” (The GPU binary firmware image)

I am using a Raspberry Pi with an adafruit 5" 800×480 HDMI 5V display, see pictures here:
http://www.svrsig.org/images/HX056.jpg and http://www.svrsig.org/images/HX057.jpg

RISC OS starts up in 1920×1080 but the GPU is set (via the config.txt) to output from the Pi to the HDMI display at 800×480. It will take whatever RISC OS produces and scale it to that size. The programme in the photos is running in mode 21 (640×512) which, again, the GPU scales to 800×480 (hence the black strips at the sides).

There is a battery, 5" display and Pi stacked on top of each other. The leads trail a bit so I’m looking for more compact leads…

If I use a Raspberry Pi Zero, with USB hub, USB/Ethernet dongle it takes 0.8A. With a Raspberry Pi 2 it takes 0.85A. Either way, I get 4 hours out of the 5000mAh battery.

The next step is to get the touchscreen version working!

I am using a Raspberry Pi with an adafruit
5" 800×480 HDMI 5V display, see pictures here

@Chris Hall: Nice setup! What do we call these things? They’re of a tablet form factor, but lack the second most defining characteristic of a tablet: the touch screen!

Dangling wires make me crazy, so like you I try to find a way to tie everything together so I can carry it from place to place cleanly. I put the Pi2 and the LCD into an enclosure I already had on hand, even though it is about 100 percent oversize. It is easily my smallest computer, in spite of the bigger box. It’s vaguely like a “thick” tablet at 1.25 inches, and I think I have room for some batteries in the extra space.

Thanks for the pics and GPU info.

@WouterRademaker: Thanks for the info on the GPU.
I imagine Broadcom has a high-level-view explanation
somewhere, if I can find it.

I am using a Raspberry Pi with an adafruit 5" 800×480 HDMI 5V display, see pictures here:
http://www.svrsig.org/images/HX056.jpg and http://www.svrsig.org/images/HX057.jpg

Is it this one or a different one? The one I’ve linked is the one that I have, and the touchscreen should work automatically with any ROM from July 2015 or later.

Amazing! I sure would like to see an in-depth explanation of this technique, and exactly how it’s done. It’s counter intuitive to my experiences …

Probably autonymous clever hardware.

To give an example from my PVR (as I happen to have the datasheet for it), the incoming video is converted to a digital form by a TVP5150 chip. That converts baseband video (PAL, NTSC, or SÉCAM) into a YCbCr 4:2:2 digital signal. As far as the attached device can ‘see’, there is a small CCD imager connected, as that is what it ‘looks like’ to the host.

The host being a TI TMS320DM320 chip. It contains an ARM926 clocking about 200MHz and a DSP clocking about 100MHz. The DSP is capable of realtime encoding video at 640×480 to older style MPEG4 (similar to XviD). It can’t record or play back in H.264 or later, not enough power.
How it manages things is to have a variety of “co-processors” and autonymous modules. For instance, the video presented by the TVP5150 is read in by the “CCD Controller” which is responsible for interpreting the data coming from the image device, dealing with black level and such, and then dumping the data into an area of memory. Along the way is another module called “Hardware 3A” which deals with Auto-Exposure, Auto-White-balance, and Auto-Focus (the 3 A’s, get it?). By chopping the image into as many as 96 ‘windows’ and running the calculations in parallel, it is possible to determine a variety of things important for a digital camera. This isn’t done by the ARM, the hardware does it for itself. The 3A is, obviously, of less use to a video recorder. ;-)
What is of potentially more use is the “Preview Engine”. It can operate in two modes. The first is to read raw CCD data and convert it to YCbCr-4:2:2 and the second mode (can be used alone or in combination with the first) is to resize YCbCr-4:2:2 image data on the fly and in realtime (with smoothing) from x1 to x4 (enlarge) or 1 to 1/64th (reduce). It can do the vertical and horizontal separately in different scalings. The PVR cheats and uses this module to scale the input video down to 720×288 because a loss in the vertical resolution is less obvious than a loss in the horizontal; and also because the DM320 is a bit underspecified, it simply cannot manage to encode video in D1 (720×576@25fps for PAL) and run an operating system (for obvious stuff like USB, SDIO, and the UI) at the same time.

All of these things are done using clever hardware. The ARM instructs the modules as to what to do, and they get on and do it without any further intervention.

I rather suspect the GPU’s clever video rescaling operates in a similar matter. Rather than the GPU doing lots of hard work, it will likely toss the final output image data to a hardware module that will be instructed “this is what the input is, this is what the output should be, make it so”.

My PVR works, briefly, as follows. I am not a maths bloke, so I’ll need to let somebody else step in to explain further, or if I’ve messed up.

Okay – the horizontal interpolation sub-module uses a 2-tap or 5-tap interpolation filter, using averages of pixels either side of the pixel being interpolated. The 2-tap is simplistic, the 5-tap does some extra work to reduce false colour artefacts.

The smoother is an anti-aliasing filter using two kinds of FIR filters. The datasheet mentions Bayer mode, but doesn’t say much else.

The horizontal re-sampler provides seamless horizontal resampling (up or down) using a bi-linear interpolation of data from the smoother sub-module. There are some diagrams showing x2 up-sampling.

Vertical interpolation and re-sampler. Pretty much the same idea as the horizontal, working with two line memories. The exact process differs depending on the colour pattern of the CCD imager. There is a colour selector that reads in the colours and determines what colour should be output.

This, from a device when a 200MHz ARM9 was hot stuff. So, yes, I can imagine the Pi’s video scaler is a similar sort of thing, only with the benefit of a few years more experience and development.
At any rate, I would be surprised if any software (ARM or GPU) directly dealt with this activity. It’s surely hardware…

@Rick Murray: I never really thought about it, and I’m not a video guy, but your explanation made some things click for me. Thanks for a well worded all-in-one description – probably much better than reading the Broadcom docs :-) I come from a coding background, sans engineering. But, regardless, it’s a much clearer picture now. Thanks.

Is it this one

Yes.

the touchscreen should work automatically

the touchscreen should work automatically

I know. I don’t have it yet, just ordered it. The one in the photo is the non-touchscreen version.

The touchscreen version has arrived but it doesn’t ‘just work’.

With the touchscreen connected to the Pi Zero, running a 20-Dec-2015 RISC OS ROM build and the latest (Nov 2015) firmware, I get just a constant 640,512 from the screen (in mode 21), using MOUSE x,y,b. The touchscreen red LED is vigorously flashing as I stroke the screen with my finger, so it knows it is being touched.

USBDevices gives:

*usbdevices
No. Bus Dev Class Description
  1   1   1  9/ 0 Synopsys DWC OTG root hub
  2   1   2  9/ 0 Terminus Technology USB 2.0 Hub
  3   1   3  0/ 0 USB Storage USB Storage
  4   1   4  0/ 0 Logitech USB Receiver
  6   1   5 FF/FF ASIX Elec. Corp. AX88772B

Any ideas to get it working please? Do I need to configure RISC OS in some way please?

Any help gratefully received. The documentation says it should just present as a USB mouse.

Hmm. *USBDevices lists a “Microchip Technology Inc. AR1100 HID-MOUSE” on mine. It seems that your Pi isn’t seeing the “mouse” part of the display at all.

Do you have “max_usb_current=1” in CONFIG/TXT? Or, for that matter, the other config settings documented on Adafruit’s site (not that they should affect the mouse)?

Many thanks.

Tried again and found a USB A to micro B cable (which are like hens’ teeth) that was a bit better than the lead I was using before and all is well. It was a poor connection on the lead (which was a micro B to USB A male adapter, the latter half of it just being the guts (no socket surround) and mated rather loosely with the USB A female socket (and could be inserted either way up). I used the calibration utility (under WINDOWS) and found it could see the mouse if I fiddled with the lead.

USBDevices now shows:

No. Bus Dev Class Description
  1   1   1  9/ 0 Synopsys DWC OTG root hub
  2   1   2  0/ 0 Microchip Technology Inc. AR1100 HID-MOUSE

Now I just need to find a 800×480 MDF for RISC OS (made one now with !MakeModes) so that the mouse lines up with the screen (on mode 28, 640×480, the mouse is at the edge of the screen when my finger is at the edge of the screen. The display is centred with a vertical letter box though.

Edit: it is all now at 800×480, RISC OS, GPU and display, so the mouse lines up nicely. Several photos at my web site.