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:23, 22/7/2017
| Software, Support, Tutorials
Comment 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.
Posted by Jeffrey Lee on 12:00, 28/11/2008
| Columns, Programming, Tutorials, RISC OS, Games
Continue reading "Building the Dream 4 - Random city basics"
| Comment in the forums
As stated in the last article
, this time I'll be looking at what went into the MK I map generator for my eternally work-in-progress game, DeathDawn
Specifically, I'll be looking at the implementation and evolution of the following components of the generator:
- City block placement. This is arguably the most important stage as it defines the overall layout of the city.
- Edge and node linking. A housekeeping stage that prepares the data structures for the road weighting stage.
- Road weighting. A city with roads which all have the same number of lanes isn't very realistic, so this stage uses an algorithm to determine the number of lanes each road should have.
- Road and building painting. With the city structure generated, all that's left is to translate it into the format used by the engine during actual gameplay.
Posted by Jeffrey Lee on 12:00, 23/8/2008
| Columns, Programming, Tutorials, RISC OS, Games
Continue reading "Building the Dream 3 - Random map generators, redux"
| 1 comment in the forums
After writing my first article about random map generators
, I said I was going to write a city generator. Well now I have, and I'm here to tell you about it over the course of the next few Building the Dream
Blow your own trumpet much?
Although this article could just be dismissed as me blowing my own trumpet, I'm hoping that it will serve a somewhat more useful purpose. Before, during, and after working on the map generator I've searched the Internet for examples of similar generators and failed to find any. Sure, there are odd bits and pieces - descriptions of simpler generators that have given me ideas on some techniques to use, or screenshots of sexy work-in-progress realtime generators, but no actual algorithms or code samples from generators that come close to the required complexity of my generator.
So hopefully this article will become a useful reference point for anyone else wanting to undertake the task of writing a city generator, whether they're targeting a grid-based world representation like mine or a vector-based one.
Apart from discussing the algorithms used in the generator (and why they're used) I'll also talk about the data structures that are used - so even if you're not interested in random map generators you should be able to find plenty of examples of uses for the data structures covered in the first Building the Dream article, as requested quite some time ago.
| 9 comments in the forums||
| 8 comments in the forums|
| 19 comments in the forums||
| Comment in the forums|
| 7 comments in the forums||
| Comment in the forums||