RISC OS Build On Touchbook

...alternatively remap it in another module, if that’s possible.

Not sure but perhaps MouseKey may help (source code included).

Posted in the Tips’n’Tricks thread.

Having decided to try a wireless multimedia keyboard with inbuilt trackball on my Devkit board, only to realise there is no menu button, I thought I would make the menu key on the keyboard produce the menu button code. To do this you need to edit the Sources/HWSupport/USB/NetBSD/build/c/usbkboard file.

Look for the mapping_table array and change the KeyNo_Menu entry to read KeyNo_CentreMouse.

This should do that for you, though I’ve not tested it on OMAP:

http://www.effarig.co.uk/riscos/download/keymap.zip

Not sure but perhaps MouseKey may help (source code included).

Is that site still up and running? that account hasn’t been active for over 10 years!

There’s a slightly newer (and 32bit safe) version of MouseKey at http://www.mybigideas.co.uk/html/software.php if you need it!

Is there someone with a Touch Book and some spare time (haha) who can please answer these questions ?

Edit: And some Touch Book-specific updates to the AI wiki page are probably also needed.

Edit(2): There’s also the dev mailing list and Open issues wiki page¹.

¹ Note that the Open issues page has so far only previously been edited by Grégoire so it’d probably be courteous to contact him by email before adding RISC OS to it.

Some TouchBook news:

• Tablet battery charging should now work. But there’s currently no way of checking that it’s working, or reading the battery level. I’ll need to check over the Portable module before deciding how to handle that.
• Soft-off should now work. Unfortunately resets still don’t work and will just hang the machine, so I’ll need to do some more research into that. I have a feeling that it will require similar code to what’s needed to get soft-off working on beagleboards/etc., so hopefully it won’t be long before all machines support both resets and soft-off.

And in slightly non-TouchBook news, in order to get soft-off working on TouchBook I had to fix the bug that was preventing resets from working on non-TouchBooks.

More updates. Not all TouchBook related, but I’ll put it all here anyway:

• The builtin speakers now work, although the sound setup plugin will list them under “line out” instead of “speakers”. In reality the speakers are actually connected to the hands-free output of the TPS, and this output lacks a dedicated amplifier, so even though the sound setup plugin will give you a volume slider for the line out it won’t actually do anything. At some point I guess I’ll have to go back through and make everything a bit more flexible so that the different mixer settings all have the right names and they can have their volume sliders disabled if applicable.
• Resets now work. It turns out Linux was triggering a reset via a slightly different method to the one I found, so now I’m just copying what Linux does.
• The video driver now supports gamma correction
• Clever use of the gamma table hardware means that 16bpp modes will now work – although you’ll only get 4 blue bits instead of 5.
• I’ve also added support for GraphicsV_SetBlank, so DPMS screensavers, etc. will work. On the touchbook this will just turn the backlight on/off, but for other machines it should (hopefully) use the correct DPMS state.
• Non-touchbook bit – while adding support for gamma tables and the 16bpp hack, I also updated the video driver to R/B swap the palette and mouse cursor when they’re displayed on TV-out. This means that palettised modes will display correctly on TV-out, but 16/24bpp modes are still R/B swapped, since I don’t think there’s any way of fixing that without the colour phase rotation matrix (which can only be used with the LCD output) or adding support for new pixel formats to RISC OS.

Also I had a look into getting soft-off working on the beagleboard. It turns out that it’s quite easy to turn the power off, but the only way of turning it back on again is to switch the power on and off at the wall. This is because the beagleboard’s reset button is only routed to the OMAP, not the TPS - and if the power’s “off”, it’ll only be the TPS which would be receiving power and thus capable of responding to the button press. It might be possible to work around this by putting the OMAP into a deep sleep state instead of turning it off entirely, but that’s the kind of thing that would be rather tricky to get working right, so I’m not planning on looking into it any time soon. So for the moment it’ll only be the touchbook which supports power off.

Also I had a look into getting soft-off working on the beagleboard. It turns out that it’s quite easy to turn the power off, but the only way of turning it back on again is to switch the power on and off at the wall. [...] So for the moment it’ll only be the touchbook which supports power off.

I’m not sure I understand this… Are you talking about two different issues, here: “Soft on” (via the reset button?) and “Soft off” (using the RISC OS Task Manager?)?

What, if any, is the difference between the BeagleBoard and the Touch Book in this respect, since soft off will only be available on the latter?

Are you talking about two different issues, here: “Soft on” (via the reset button?) and “Soft off” (using the RISC OS Task Manager?)?

Yes.

What, if any, is the difference between the BeagleBoard and the Touch Book in this respect, since soft off will only be available on the latter?

When you shutdown the TouchBook, the shutdown screen will be the same as the Iyonix – if you don’t hit the reset button within 5 seconds it’ll turn the power off. Pressing the power button would then obviously turn the power back on.

For the beagleboard (and all the other machine types) it’ll just sit on the “It’s now safe to turn off the computer” screen until you turn the power off (or hit the reset button)

Unless you were talking about hardware differences, in which case:

The TPS65950 is the main power management IC - it’s connected to the battery, AC adapter input, etc., and generates the different voltage rails needed by the rest of the system. So if the system is “off”, it’ll only be that chip which receives power, and in order for the system to turn on it’ll need something wired up to the “power button” pin. For the Touch Book it’s the power button which is wired up to the “power button” pin, but for the beagleboard it’s a circuit of some kind which causes the power to turn on when power is applied to the DC jack (This circuit might be as simple as tieing the pin to logic 1, but I’m not sure how that would affect the “force power off” functionality where the TPS will turn the machine off if the power button is held down for several seconds). So although it’s easy for the OMAP to tell the TPS to enter the “off” state, without any button attached to the “power button” pin of the TPS there’s no way of turning the power back on again without turning the whole thing on & off at the wall.

[...] there’s no way of turning the power back on again without turning the whole thing on & off at the wall.

Do you mean off and then on?

Meh, it’s still a step up from my Iyonix, which recently smashed its all-time record with me having to toggle the power socket five times before the graphics card successfully initialised!

Clever use of the gamma table hardware means that 16bpp modes will now work – although you’ll only get 4 blue bits instead of 5.

What are the two spare bits used for? Gamma correction?

Do you mean off and then on?

Yes!

What are the two spare bits used for? Gamma correction?

No. The gamma tables are just three seperate lookup tables which map the pixel red value to a gamma-corrected red value, the pixel green value to a gamma-corrected green value, and the pixel blue value to a gamma-corrected blue value. The same gamma tables are used across the whole display, much like a palette would be.

If you ignore the fact that we’re using the colour phase rotation matrix to swap the red/blue channels, then for 16bpp modes we need to map between the two different formats:

RISC OS 16bpp format:  ?BBBBBGGGGGRRRRR
OMAP 16bpp format:     BBBBBGGGGGGRRRRR

The OMAP’s red gamma table has 32 entries and is indexed by bits 0-4. The green gamma table has 64 entries and is indexed with bits 5-10. The blue gamma table has 32 entries and is indexed by bits 11-15. We can’t alter which bits are used to index each gamma table, but by duplicating entries within the gamma tables we can construct the tables in such a way that the values of one or more bits of the index are effectively ignored. Specifically we want to ignore the top bit of the green index and the top bit of the blue index, and to do that all we need to do is make sure that the top halves of the green/blue gamma tables are identical to their bottom halves. This means the gamma tables would be indexed as if we were using the following pixel format:

RISC OS 16bpp format:  ?BBBBBGGGGGRRRRR
Special gamma table:   ?BBBB?GGGGGRRRRR

Jeffrey! this is a very neat solution and works like a charm on my BeagleBoard! I can now run in 32k modes and have a proper image!! Amazing how simple some clever solutions are :-)

Thanks again!

I agree, it’s a very neat solution, and thanks again for all the work listed above (speakers, reset, gamma correction, proper 16-bit screen modes, etc.)! :)

As well as for your thorough explanation of the soft on/off issues.

I’ve got a Touch Book, myself, as well, but I haven’t yet tried running RISC OS on it, as I’ve wanted to wait a little until the port was more stable (like I did with the BeagleBoard port, as well), but it’s very encouraging to see that RISC OS is now working there, as well… :)

Now I no longer need to rely on emulation for RISC OS on-the-go: Good work! :)

It that 32k trick possible on the newer Iyonix cards too?

Is the new Smartbook thing from the same firm likely to be suitable for RISC OS too?

Is the new Smartbook thing from the same firm likely to be suitable for RISC OS too?

It’s based on the BB-xM so definitely a suitable candidate. It also sounds like AI may be shipping soon

OMAP 16bpp format:     BBBBBGGGGGGRRRRR

Ah – so exactly like Select’s much-vaunted 64,000 colour modes, then?

It that 32k trick possible on the newer Iyonix cards too?

Not to my knowledge, no. The problem with the new GeForce cards (or at least the problem with my card) is that the red/blue channels are the wrong way round in 16bpp modes. This is something that can’t be fixed with gamma tables (although admittedly I know practically nothing about the GF gamma table hardware!)

Ah – so exactly like Select’s much-vaunted 64,000 colour modes, then?

Yes. Although I’m sure you know that it’s 65,536 colours, not 64,000 ;)

Jeffrey! this is a very neat solution and works like a charm on my BeagleBoard!

Works a treat but NetSurf isn’t too happy… perhaps it’s a Tinct issue – if so, I’ll post to the list before filing a report.

If you click menu on the Nefsurf iconbar icon. Then click ‘choices’ then ‘images’. If you change forground and backgroung to ‘Use OS’ Netsurf should be OK again. I believe this stops it using Tinct.

Is that 32k trick possible on the newer Iyonix cards too? Not to my knowledge, no. <snip>

Ahh, I think I see what is going on. The OMAP has only got 2 bits wrong, and you are masking them out with the gamma, resulting in 14 bit display of the standard 15 bit mode. (32K is not worth spending a huge amount of effort on if 16M is available.)

Is the new Smartbook thing from the same firm likely to be suitable for RISC OS too? It’s based on the BB-xM so definitely a suitable candidate.

That looks interesting. Very interesting. I hope that means that the Smartbook would also work, (it would be nice to have RISC OS on the MID too)

...If you change foreground and background to ‘Use OS’...

WFM. Thanks. Observation posted to the netsurf-users list before I’d checked this (wrongly assuming I wouldn’t be able to do so for a few days).

The shipped AI software has been updated The default is apparently now Android Froyo rather than AIOS. A beta hot OS-switching capability is also available (although presumably this uses the multi-OS selection screen, meaning RISC OS obviously can’t easily be included).

This discussion regarding mapping Android’s menu button may (or may not – in which case, apologies for the distraction) be relevant to RISC OS functionality. It suggests an on-screen popup bar, although I think this is suggested to be activated by an on-screen ‘button’ rather than a physical button.

Therefore, perhaps not too useful…

There’s this $0.99 starting price Touch Book listed on ebay. (No keyboard, and international shipping would be extra.) Anyway, I’ve already arranged a private purchase with another poster on that forum, so hopefully mine will arrive soon – not sure how long I’ll keep it but am curious to see how usable it is.

Thanks, Jeffrey. My (v.1) Touch Book has arrived and RISC OS boots :) I’ve yet to update AI’s wiki page but will do so when I can. I’ve not had time to really experiment much yet.

• Write the SD image to a freshly formatted card (there’s a temporary copy linked to in this AI forum post, although we can all easily make and write our own images now, thanks to SDCreate)
• Open the top part and replace the current card with the RISC OS card
• Reassemble (optional)
• Turn it on
• *desktop etc.
• Note: a slim USB stick is needed in order to fit inside the top part (to boot from)