The Icon Bar is the longest running RISC OS portal. The sensibilities that Acorn instilled in us still influence our interests and writing.
Let us know!
Posted by Mark Stephens on 10:27, 28/4/2018
| Programming, Tutorials
Chris Hall has been trying to make the most of power for a RISC OS based RaspberryPi for his GPS system. In his guest post , he lifts the lid on how he does this...
1 comment in the forums
A Raspberry Pi can be powered by a mains adapter or by a powerbank. I found myself often pulling out the power plug to power cycle the Pi and came up with a software power switching method that would allow power to be removed under software control.
A 'power booster' board allows an internal 3.7V Lithium-Polymer battery to produce a 5.2V output and any external 5V power source will take over this rule and charge the internal battery until fully charged. Switching on and off is controlled by an 'ENABLE' input, pulled high by default. A blue LED lights if power is being supplied to the computer. With the booster board output disabled, only a minimal current is drawn from the internal battery. A red LED lights if the internal battery becomes discharged below 3V (and if a diode is fitted to the 'LBO' pad this can disable the output automatically). Fully discharging the internal battery is likely to damage it.
While the internal battery is being charged a yellow LED lights, turning green when it is fully charged. A small current drain to light the green LED to show a full charge seems enough to keep some power banks happy even whilst the unit is otherwise powered down and the internal battery fully charged.
This means the external source can be connected and disconnected without affecting the operation of the device except to extend battery life. Power control
With no power control hardware it is difficult to ensure that the computer is not, inadvertently,turned off during a write operation to the SD card, which can corrupt the file or the whole card. My power control circuit allows power to be applied at any time by pressing the 'on' button. The 'off' button simply signals that a power off has been requested, which can be detected in software. A shutdown/restart cycle will then remove power as soon as the system has been shut down and the CMOS updated.
If software detects a 'power off' request then all it has to do (once it has completed any essential tasks) is to issue the command:
which will do a shutdown/restart cycle.
Doing a manual shutdown (CTRL-SHIFT-f12) and then pressing 'Restart' will also remove power (if a 'power off' request has been issued). How Does It Work?
Software can detect the 'on' button being pressed or held down by reading the GPIO 19 line and can use this information for any purpose. The fact that the 'off' button has been pressed (and the 'on' button remains open circuit) can be detected by reading GPIO 26, meaning that 'power off' has been requested.
A little piece of software in !Boot.Choices.Boot.PreDesk sets GPIO 4 to output high (which ensures power stays on even after a 'power off' request).
During a restart cycle, before any writes are made to the SD card, the ROM modules are reset which takes GPIO 4 to high impedance: with a 'power off' request pending this will remove power.
Provided that the unit has been operating for at least six seconds (enough time for the RISC OS desktop to start), the 'off' button will pull GPIO 26 low but do nothing else. Software can detect this, complete any essential tasks and then either explicitly set GPIO 4 low (if a Witty Pi is present, this will remove power immediately) or (if not) perform a complete system shutdown using the command SYS "TaskManager_Shutdown",162 which will shutdown all applications tidily and restart RISC OS. The effect of this is to update the CMOS êlast time onë setting and restart the ROM. As the ROM reinitialises, GPIO 4 becomes high impedance thus removing power.
The 'on' button has some additional functions: whilst pressed, components (R6, R7 and LED) may also be fitted to present an LED load to any external power source that will only light if the external source is healthy (this works by sensing whether Vs from the power boost board is 3.7V or 5.2V). If a voltmeter is fitted as shown, the voltage of the internal LiPo battery is displayed whilst the button is depressed. A power meter can also be connected between the power boost board and the Raspberry Pi giving a voltage, current and power consumption readout. Battery Life
With an internal 4400mAh LiPo battery, a Raspberry Pi Zero with an OLED display and GPS module (but with no HDMI connection) uses about 170mA (at 5V) and the battery should therefore last for about (4400 x 3.7)/(170 x 5.2)h which is just over 18 hours. A 5000mAh 5V powerbank should extend this by about 28 hours. Chris Hall's website
Posted by Mark Stephens on 09:35, 28/7/2017
| Software, Reviews, Tutorials
Comment in the forums
In a previous article
, we looked at installing the new ROM for your Titanium. This time we will look at what the new release offers.
This is actually quite a major update and there is a long list of changes. The offical full list of changes is on the ROOL website. Some of the changes are not really relevant to Titanium users (Pico build fix, introduce iMx6 to ROOL repository) but there are lots of interest.
From a user's point of view, there are 3 major new features
The first is the addition of 256 colour modes.
This makes it much easier to use old software which was written for these modes.
Another bounty enhancement
is the new EDID support means that your machine can be much 'smarter' when you plug a monitor into it. It is not Titanium-specific (but very nice to have). This is the result of the EDID bounty from ROOL.
Improvements to ADFS now mean that you can have up to 8 terabytes of storage on RISC OS (and RISC OS uses large drives more efficiently).
A nice little enhancement for Paint is the addition of a timer control for the spray can (which was previously a little unwieldy on fast new modern machines). Paint is now version 2.21 (last updated May 2017).
BASIC and the Chars and Draw applications both get enhancements and bug fixes.
The whole package is free to download and brings the Titanium bang up to date with RISC OS developments. What are your impressions of the new update? Have you found any problems?
Posted by Mark Stephens on 10:23, 22/7/2017
| Software, Support, Tutorials
2 comments in the forums
Elesar emailed all its clients and announced on the newsgroups
that there was a new software update for the Titanium. In this article we will download and install it with a sequel to look at the new features.
As well as the 'vanilla' Titanium, CJEmicro's
have systems based on the board. As my machine is from R-Comp
, I checked with Andrew Rawnsley about whether it was a good idea to install or wait for an official update from them. R-Comp are indeed planning to do a proper machine-specific update once they had done their own testing. You can wait for them or you can use the new update. If you have a machine from CJEmicro's I would confirm their advice first.
If your Titanium is your critical work machine, you might want to wait
a little while to let others test the upgrade (which is equally valid advice on new MacOS, Linux or Windows updates).
The Elesar download link actually takes you to a download page on the ROOL website where you have a choice of downloads, depending on how 'cutting edge' you would like to be. The bottom item is the recommended stable release and it is twice as big because it includes a second version of the ROM.
The official download is the 5 meg download which contains everything you need to upgrade your Titanium and a clear and helpful readme.
There is a potential risk for things to go wrong, so you are advised to make sure you have backups of all your data before you start (always a good idea to keep regular backups in any case!). Murphy's law generally means the more prepared you are the less likely things will go wrong...
Two versions of the new OS release are supplied, with and without zpp included. Which one you choose will be down to your personal preferences and the software you are using.
The actual upgrade consists of 3 steps:-
1. Update the software on your disk (using Merge to update !Boot with any changes).
2. Sanity check by soft loading the ROM on your machine using the softload obey file, just to make sure. If there are any issues, you can then revert back to the original with a quick reboot.
3. Use the FlashSQPI application to burn a new copy of the ROM onto your system. This can be a little time-consuming and should not be interrupted. Once it is done, you can reboot the machine.
Before you do any of this, it is worth reading the readme fully TWICE.
It is very easy to see if the machine has been updated.
You have an updated machine running the latest version of RISC OS for your machine. Next time we will look at what is new...
Posted by Jon Robinson on 14:57, 28/6/2014
| Hardware, Castle Technology, Software, Writing, Tutorials
Continue reading "Getting FAT32FS working on a RiscPC with a Castle USB Card"
| Comment in the forums
I have a RISC OS 4.39 RiscPC with a Castle
USB card and Compact Flash card reader attached. This uses Castle‘s !SoftSCSI to access the flash cards.
For a long time, I have been frustrated by its inability to mount any flash card larger then 2 GB in size. I really wanted to use a single flash card, to back up my 40 GB hard drive, as having to use a pocket full of 2 GB cards is a real pain.
I had been put off experimenting with Jeff Doggett‘s FAT32FS
before, because I had read somewhere that it only works with the USB stack on the Iyo.
But, as it‘s the only solution, I did have a go at trying to get FAT32FS working on my RiscPC, recently. And, luckily, it turns out that the USB podule card on the RiscPC, is sufficiently similar to the one in the Iyonix, that it does
, in fact, work.
It did take a bit of experimentation, however, to work out how to do it.
Posted by Jon Robinson on 23:30, 21/7/2011
| RISC OS, RISCOS Ltd, Tutorials
What is Unicode?
Continue reading "Getting Unicode Working With RISC OS 4 (and 6?)"
| 20 comments in the forums
Unicode has been developed as a standard way of representing the characters in all the world’s basic languages.
It was designed to make it easier to exchange files, between computer users who write using different alphabets, and to make documents that do not use the Western, Latin alphabet, readable all over the world, regardless of which program, or operating system is used to view them with.
Before Unicode was introduced, people used standard eight bit (one byte) fonts, which allowed the representation of only 256 different characters. When creating complex documents which included, for example, special symbols and foreign-language characters, you would have to use several different fonts to get all the required characters.
The problems would start when you emailed this to somebody else, and they didn’t have the same fonts installed on their system, that you had used to create it with. Parts of the document would be unreadable.
A further problem arises when two different encodings are used for the same set of characters.
For instance, Cyrillic web pages are often encoded in either KO18-R, or Windows 1251, which both have the same characters, but in different positions in the font table. If you sent a KO18-R document, or email, to somebody whose system was set up for Win 1251, they might not be able to read it.
Unicode was designed to get around these problems by using more than eight bits to represent a character. By using more than one byte, virtually every symbol, or character that exists in any language, can be allocated its own, unique number (or code point), so that the character can be represented by the same number, whatever operating system, or program you are using anywhere in the world.
If your system supports Unicode, a word processor or web browser that loads a Unicode document, will check all the code points in the document against a look up table, which tells it whether that character is defined in any of its installed fonts. If so, it retrieves the character’s details, and renders it to the screen.
Unicode makes the sharing of documents and web pages, across national boundaries, much easier, and is a God-send to those who regularly communicate with people who don’t use our alphabet, or are interested in studying foreign languages.
So how does RISC OS bear up to the challenge of supporting this international standard ?
Posted by Jon Robinson on 22:00, 11/1/2010
| RISC OS, Open source, Video, Tutorials
Continue reading "Video Processing on RISC OS"
| 19 comments in the forums
One of the frustrating things about being a RISC OS user, is its lack of support for commonly-used video formats, other than its own dedicated Replay system.
A few attempts have been made to remedy this situation, but, until recently, they have come to nothing.
In the mid-1990s, Innovative Media Solutions produced a range of Acorn readers for PC-format, educational CDs, such as Microsoft Dinosaurs
and Dorling Kindersley's The Way Things Work
. These readers included dedicated versions of ARMovie, which could convert the CD’s AVI files to Replay format on the fly.
Unfortunately, the work that IMS had done, did not result in the release of a souped-up version of Replay, which could play all Quicktime and AVI movies, despite the fact that RISCOS Ltd
seem to have done some work in this area about five years ago.
But now, with the release of the open-source applications, Murnong and FFMpeg, by Chris Martin, things have started to take a turn for the better.
Although RISC OS still does not have a proper media player, which can play all the common video formats, we do
now have the next best thing - an application that can capture a YouTube video stream as it arrives, and convert it to an MPEG file, which can be played using KinoAmp.
Posted by Phil Mellor on 12:00, 17/2/2009
| Mac, Media, Hardware, Tutorials, Video
Continue reading "Making a Mac mini media centre"
| 4 comments in the forums
Here's the plan: take an old Mac mini, blow the dust off it, and repurpose it as a media centre. In particular, I wanted it to:
- Watch and record Freeview channels
- Watch shows on BBC iPlayer
- Play downloaded videos
Here's how I got on.
Posted by Jeffrey Lee on 20:00, 20/12/2008
| IYONIX, Programming, RISC OS, Support, Tutorials, Video
Continue reading "Video conversion on RISC OS"
| 1 comment in the forums
A while ago you may remember that I wrote an article about video conversion for RISC OS
, and near the end raised the topic of video conversion on
RISC OS using a port of ffmpeg
. Although the version of ffmpeg I originally tried on RISC OS was old and broken, Christopher Martin obviously thinks there's some merit to this approach, as he has recently produced !FFmpeg
, a working port of ffmpeg for RISC OS.
Once more in the interests of SCIENCE, I threw a few test videos at !FFmpeg and measured its performance against that of a similar version of ffmpeg running on my Windows PC.
| Comment in the forums||
| 1 comment in the forums|
| 9 comments in the forums||
| 8 comments in the forums|
| 19 comments in the forums||
| Comment in the forums||