RISC OS Build On Touchbook

Another “crazy new innovation” of sorts: the Beagleboard Super-Jumbo.

So when’s the “Mega-Jumbo” coming out with RISC OS included!?

If only! Perhaps Chris Hall’s multi-OS technique could be incorporated. But the hot-OS switching can’t include RISC OS because of the non-Linux kernel.

Here are a couple of other AI tidbits:

• […] by licensing our designs […]
• ELC presence

Can anyone (Jeffrey or Trevor, I guess) tell me what the full charge voltage would be on the Touchbook for both batteries, as displayed by bcimon?

Also, how long would you expect it to last on batteries when fully charged, assuming fairly average use?

tell me what the full charge voltage would be on the Touchbook for both batteries, as displayed by bcimon?

Sorry, I won’t be able to check that for a few weeks :-( A few Touch Book related things are with my parents ATM, and I won’t be getting them back until the Midlands show next month. (Long-ish story, but suffice it to say that there really do exist people who mistakenly take other people’s luggage on trains and then hand it in at a lost property office with nothing missing – not even a fairly bulky and obvious digital camera!)

Portable_Speed

Hopefully there are no implications here regarding this notebook cooling patent trolling!

tell me what the full charge voltage would be on the Touchbook for both batteries, as displayed by bcimon?

Fully charged, plugged in, green light illuminated (normally orange when not at full charge):

• 3.92V, 4.10V (with slight variations)

Trevor, thanks a lot for that info. Much appreciated. And how long would you say it lasts on batteries with fairly light usage? (i.e. not compiling a ROM or some other such intensive task.)

After a full charge, I’ll unplug it and leave the following (single-tasking) program running. Final result to follow.

   10REM>TimeDump
   20:
   30REM Dump out recorded time to file.
   40REM Leave running from full charge until machine
   50REM runs out of juice and shuts down.
   60:
   70ONERRORCLOSE#x%:REPORT:PRINT" at line ";ERL:END
   80d%=1 : REM recording interval in minutes
   90e%=100*60*d% : REM convert to cs
  100x%=OPENOUT("Time")
  110h$="Elapsed time, in minutes"+CHR$10
  120PRINTh$
  130BPUT#x%,h$
  140t%=TIME+e%
  150s%=0:PRINT;s%:BPUT#x%,STR$(s%)
  160REPEAT
  170CASE TRUE OF
  180 WHEN t%<TIME : t%+=e% : s%+=d% : PRINT;s% : BPUT#x%,STR$(s%) : p%=PTR#x% : CLOSE#x% : x%=OPENUP("Time") : PTR#x%=p%
  190ENDCASE
  200UNTILFALSE
  210CLOSE#x%

[Edit: amend filename]

You do realise that WHILE loop will force the CPU to sit and spin in a loop, causing 100% CPU usage, don’t you? It would be much better if you stuck a WAIT in the loop, so it will spend most of the time asleep (although that would just measure battery life under 0 load, instead of the battery life under “fairly light usage”. I guess you could rig it to spend X% of the time spinning in a loop and the rest using WAIT…)

But apart from that, you’re also forgetting that bcimon already has logging code built in (although I can’t remember how user-friendly the output is!)

WHILE loop will force the CPU to sit and spin in a loop, causing 100% CPU usage

I must admit I didn’t exactly appreciate this, which certainly doesn’t qualify for “fairly light usage”!

also forgetting that bcimon already has logging code built in

I did remember that but had forgotten that it didn’t require the debug-enabled Portable module (which I thought I’d then need to reinstall the tools for and then rebuild that module again). I think I’ll try again with one of the CPU monitoring apps and use a loop/WAIT prog to simulate light usage as suggested.

I think the BCIMON logging code may possibly need amending to ensure the file is closed each time, as when we’re out of juice the file won’t be closed before the device shuts down. I’ll also check the logging frequency, as the prog above only writes once a minute. AIUI USB access consumes a not insignificant anount of power, so we may not want to be logging too frequently.

In the mean time, FWIW (from full charge):

• 100% CPU load, 600MHz, DPMS blanking disabled (screen constantly illuminated), USB Wi-Fi dongle inserted, USB writes 1x/min
  • Dead after 230 mins

In the mean time, FWIW (from full charge): [snip] Dead after 230 mins

Thanks, Trevor – that’s interesting. Does your Touchbook have the charging mod done on it?

charging mod

Not currently, but if/when I do it, I was thinking of incorporating a switch.

I’ll also check the logging frequency

[…] variables […] "How often to update the iconbar icon/log file", so that’s OK.

BCIMON logging code may possibly need amending to ensure the file is closed each time

Nope – it’s already closed within PROClog. Will run it again when fully charged and at a convenient time (probably tonight).

"[…] play around and see how many of the old modes I can get working […]"

I’m having a bit of a look at this. Adding "Generic Type 5" (listed in Docs.MakeMan as being “LCD”) to !MakeModes.MonList seems to help get started.¹ The typical frame rate of 60Hz is listed in the AU Optronics doc linked to from AI’s BOM, but we know it does 98Hz. How dodgy is it to test this further by pushing things either way? And I have no idea about the line rate – does this apply to LCD screens?

¹ [Edit: Apparently MakeModes should prompt to automatically add new defs to the list – maybe I’ve missed something. I’ll take a good look at the application note: 1, 2. There’s also Eric Rucker’s LCD MDF which I’ll investigate.]

Eric Rucker’s LCD MDF

Nice one, Eric :-) The 320 × 250 def gives the proper Mode 7, although it’s tiny. This doesn’t help with BeebIt, which needs the 640 × 480 def. But this is missing 20 pixels off the bottom and so far I’ve had no results experimenting with 640 × 500.

# 320 x 250 (70Hz)
startmode
mode_name:
x_res:320
y_res:250
pixel_rate:12587
h_timings:42,14,12,320,12,0
v_timings:2,109,0,250,0,88
sync_pol:2
endmode

# 640 x 480 (60Hz)
startmode
mode_name:
x_res:640
y_res:480
pixel_rate:25175
h_timings:94,22,22,640,22,0
v_timings:2,32,0,480,0,11
sync_pol:3
endmode

# 640 x 480 (73Hz)
startmode
mode_name:
x_res:640
y_res:480
pixel_rate:31500
h_timings:48,84,30,640,30,0
v_timings:3,28,0,480,0,9
sync_pol:3
endmode

# 640 x 480 (75Hz)
startmode
mode_name:
x_res:640
y_res:480
pixel_rate:31500
h_timings:64,76,30,640,30,0
v_timings:3,16,0,480,0,1
sync_pol:3
endmode

Something fishy’s going on. I don’t know whether it’s the MDF or possibly something within BeebIt.

• 320 × 250
  • Control codes seem to appear correctly
• 640 × 480
  • Some control codes don’t appear as blank chars but repeat the char just before (like held graphics IIRC), e.g. codes 136, 137, 141
  • Code 141 also doesn’t blank the subsequent line (for non-char codes) as would be expected
  • (Under RISC OS, this def still renders Mode 7 as a graphics mode, so I’ve not been abe to compare there)

The 320 × 250 def gives the proper Mode 7, although it’s tiny

Aha, I wondered why on the one or two occasions I’d tried to use MODE 7 on a beagleboard, it failed – though I never investigated why. I’ve become accustomed to the 640×500 teletext mode on the Iyonix. This should be easy to fix by adjusting Hdr:Machine.Machine to enable HiResTTX (and TTX256) for M_ARM11ZF, M_CortexA8 and M_CortexA9 – but then everyone will need 640×500 in their MDFs as well. I assume nobody would object to this change?

No objection from me. Although if you were feeling generous you could also update the code to allow it to use the slightly more common 640×512 if 640×500 isn’t available :) (And 320×256 for the low-res version I guess)