Question re : HAL / video programming

Hi!

As mentioned in my other thread (Netbook PRO Port) which I hope to start soon, I am getting the full Linux sources (including all hardware initialisation code) as well as the RISC OS HAL for Netbook (partially complete I believe).

I don’t know the state of the video support in that HAL, but something has been bugging me about the specifications for the Netbook PRO, and RISC OS:

The Netbook Pro has an Epson graphics controller. It seems to have very slow access to the VRAM it uses too. Also, it only uses 16-bit colour, and, can ONLY be access in 16-bit words (maybe 8-bit too, I am unsure of this).

My question is :

How would RISC OS cope with a video subsystem with only 16-bit access? (e.g. any software with direct screen access e.g. STR / LDR / STMIA etc isn’t really going to do very well!)

(and, does the solution to this preclude the use of the hardware acceleration which is an said Epson graphics controller?)

Thanks!

Matthew

You’d probably encounter a lot of problems getting RISC OS (and more importantly, existing programs) to work with a device which only supports 16-bit memory accesses. And you’d encounter even more problems if the pixel format doesn’t match that of RISC OS’s traditional 16bpp mode.

I’m thinking that the best solution might be a Geminus-like approach – use the MMU to trap writes to a fake framebuffer, then on the next VSync peform whatever work is required to transfer the modified pages to VRAM. This could allow you to support the full range of colour depths, as well as screen modes whose size don’t match that of the LCD panel (unless the Epson controller has fairly flexible display scaling, or allows for borders around the screen?) You probably wouldn’t get good enough performance to play any action games, but it should allow the full range of existing desktop apps to work without any problems.

The only other alternative would be to forget about supporting screen modes the hardware is incapable of and focus on updating RISC OS to work correctly with the restrictions of the Epson controller. This could involve implementing some of the extended framebuffer specification if the 16bpp format doesn’t match that used by RISC OS. You’d also have to track down all the code that writes to screen memory and make sure it only uses LDRH/STRH. Perhaps as part of the extended framebuffer support the HAL can be extended to indicate what width of memory accesses are supported by VRAM. Plus of course you’d have to update the kernel to select the right screen mode on boot (although this should be much easier than the other tasks)

I think we can safely say that there is probably not a single piece of rendering code in RISC OS that uses STRH commands. The 16-bit load/store commands were introduced in ARMv4 (StrongARM) but never worked in the StrongARM Risc PC because its memory bus was designed for ARMv3 chips. As a result, they are only useful in machines like the Iyonix, A9home and Beagleboard – and all the graphics primitive routines had already been written by this point.

There are an awful lot of these that would need rewriting: lines, triangles, rectangles, circles, ellipses, flood-fills, block-copies, system font (both VDU4/VDU5 versions), sprites, JPEGs, PNGs, alialiased fonts and drawfiles off the top of my head. And that’s ignoring the fact that applications expect to be able to write directly to the framebuffer using any instructions they choose. And many if not all of the above will have been written in assembler and optimised to use STR or STM instructions, which would all need unpicking. This is much more difficult than simply swapping red/blue or adding 5:6:5-layout 16bpp framebuffers, where the changes are restricted to colour lookup and manipulation.

I note that the Epson chip has a 16-bit data bus. Is there any chance that the bus controller in the PXA is bright enough to serialise 32-bit accesses from the CPU core into pairs of 16-bit accesses, at least if (as would be the case here) it is informed that the relevant chip-selects correspond to memory rather than a block of I/O addresses (this is a distinction made in PCI buses, for example).

Failing that, I think your best bet to get it working in a sensible time-frame is indeed to operate an off-screen bitmap and copy it across to the real framebuffer on a regular basis, perhaps by means of a DMA transfer.

I downloaded info on this controller (a full datasheet including all registers for hardware acceleration etc). It supports 4/8/15/16BPP colour depths, which is useful!

Initially I will just try to get some kind of display from RISC OS - I guess that it will be at least recognisable if 32-bit instructions are used to write to the framebuffer (e.g. missing or replicating every second pixel)

I think an off-screen bitmap is a good idea, although it depends on how fast the screen can be updated (need to look into the bandwidth available); it may need to be done using 10Hz updates or something.

Editing the code to use 16-bit accesses would take ages, but could be useful for future porting of RISC OS to devices with 16-bit memory interfaces (which may well still occur in embedded applications). This would be the best way to do things for applications that don’t use direct screen access.

Look forward to getting the HAL code (how much of it has been HALed?)

Matt