Qualcomm Snapdragon

Qualcomm's Snapdragon line of Systems-on-a-chip feature single or dual ARM cores at speeds of 1GHz or greater, a 600MHz DSP for audio/video encoding/decoding, 3D graphics acceleration, 3G/wifi/bluetooth networking, and essential I/O hardware such as audio, video, USB and SD/MMC controllers. The Snapdragon SoCs will be at the heart of Qualcomm's 'smartbook' product range - a series of always-on, always-connected mobile devices including netbooks, internet tablets, and smartphones.

ASUS Eee PC with 1GHz Snapdragon SoC, running Android Via GoodGearGuide, Engadget, Liliputing	Compal's Android-running, Snapdragon-powered smartbook Via Engadget, Liliputing
Other news 1.3GHz Snapdragon announcement - Liliputing Qualcomm coins the term 'smartbook' - Liliputing ASUS, Wistron, Inventec smartbooks revealed - Slashgear LinuxDevices coverage - LinuxDevices

TI OMAP3

Although perhaps not as many OMAP3 products were announced as I would have liked, it does look like there are at least a couple of OMAP3 powered products on their way to market this year.

ECS T800 netbook with 1GHz OMAP3, running Android Via Engadget, Liliputing	Pandora portable gaming console inches closer to release Via Engadget, unofficial Pandora blog
Other news Although there hasn't been much news about it recently, it looks like Always Innovating are gearing up for the Touch Book release, with a new info page appearing on the website and promising lots of news, information and pictures over the coming weeks.

nVidia Tegra

nVidia have revealed that they want a slice of the netbook/smartbook/smartphone pie, with the announcement of their Tegra platform - a hardware platform comprising an ARM11 CPU, GeForce GPU, HD video decoder, HDMI output, USB, and all the other bits you'd expect from any modern system-on-a-chip. According to their presentation at Computex at least 12 Tegra-powered devices are on their way this year. But then again, they also claimed that Qualcomm's Snapdragon fails at HD video playback and only gets 5fps in Quake, statistics that seem to have landed nVidia in some hot water judging by the fact that (almost) all pictoral proof of the slide in question has vanished from the internet. At the moment only Windows CE is supported by Tegra, but support for Google's Android is in the works.

12 Tegra products on their way Via Engadget, Liliputing	Mobinnova Elan netbook Via Engadget, Liliputing
Other news Tegra announcement - Liliputing HD video playback, hardware accelerated flash plugin - Liliputing A few pics of hardware and the mythical presentation - CNET

Freescale

Although Freescale's i.MX range of ARM-based SoC's don't appear to have as much grunt as some of their rivals, they still showed off a few products at Computex.

Kinpo's 7-inch Android tablet Via Engadget	GNB's 7-inch Android netbook Via Liliputing
Pegatron's original netbook prototype resurfaces Via Liliputing	Wistron's N900z netbook Via Liliputing
Freescale netbook & smartbook Via Engadget

Other

Whereas most of the above has focused on ARM based products announced at Computex that could one day run RISC OS, it's important to remember that there are a load of other ARM based devices out there. Such as...

• OpenRD-Client - A small computer akin to the A9home, the OpenRD-Client is powered by one of Marvell's Sheeva brand of ARM-based chips, and supports clock speeds of up to 1.2GHz
• VIA are entering the ARM based smartbook space - just not much concrete information about products yet. See also here for some more details.
• Skytone's Alpha 680 netbook - It's got an ARM CPU, it runs Android, and it features a swivel screen for converting to tablet mode.
• x86/ARM netbook/tablet combo - A HP mini 1000 with the screen removed and replaced with a removable ARM powered tablet. Like a Touch Book, but with extra x86 compatability (providing you don't mind the fact VNC is being used to communicate between the two halves!)
• IAC's Prodigy e-reader - Although you probably wouldn't want to run RISC OS on an e-reader due to the typical 0.5Hz screen refresh rate, it's worth listing just to show how many devices use ARM CPUs nowadays. See also here for another ARM-based e-reader.
• Snapdragon powered smartphones - Acer F1, Toshiba TG01

16 comments in forum ]]> Sat, 13 Jun 2009 20:00:00 GMT http://www.iconbar.com/comments/rss/news1224.html http://www.iconbar.com/comments/rss/news1224.html As most of you probably know by now, a few months ago I started work on porting RISC OS Open's RISC OS kernel to TI's OMAP3 platform - a group of SoC's (Systems on a Chip) which use ARM Cortex-A8 cores. To date, OMAP3 SoC's have been confirmed as being used in various products, including the Pandora handheld gaming console, the Touch Book convertible netbook/tablet, and the BeagleBoard development board. For years RISC OS users have been asking for a new portable RISC OS machine, and soon they may find that they have several available. As most of you probably know by now, a few months ago I started work on porting RISC OS Open's RISC OS kernel to TI's OMAP3 platform - a group of SoC's (Systems on a Chip) which use ARM Cortex-A8 cores. To date, OMAP3 SoC's have been confirmed as being used in various products, including the Pandora handheld gaming console, the Touch Book convertible netbook/tablet, and the BeagleBoard development board. For years RISC OS users have been asking for a new portable RISC OS machine, and soon they may find that they have several available.

Out with the old, in with the new

The Cortex-A8 and Cortex-A9 cores from ARM are the latest and greatest iteration of ARM chips. Although the 600MHz CPU in the OMAP3530 doesn't offer any increase in clock speed compared to the XScale-based CPU in the Iyonix, it has several advantages in other key areas:

• Dual-issue superscalar design - Previous ARM CPUs that have run RISC OS were all based around scalar designs, i.e. they only had one instruction pipeline and therefore were only capable of processing a maximum of one instruction per clock cycle. But the Cortex-A8 uses two instruction pipelines operating in parellel, allowing it to process up to two instructions per clock cycle. This means that although the CPU is only clocked at 600MHz it has a maximum theoretical performance of 1,200 MIPS, twice that of the IOP321 in the Iyonix.
• Vector Floating Point Unit - For many years ARM CPUs as used by RISC OS have lacked floating point units, resulting in poor performance in many modern number-crunching tasks such as audio/video encoding/decoding or 3D games. With the Cortex-A8 that's all about to change, as it contains support for both the VFPv3 and NEON instruction sets. Although this new floating point instruction set isn't backwards-compatible with the old FPA10/11 instruction set that RISC OS has historically used, the new instructions are far more powerful and look to be a key part of ARM CPUs for many years to come.
• L2 cache - The CPU core in the OMAP3530 has 256KB of L2 cache. This is practically nothing when compared to modern x86 CPUs, but this is the first time a CPU with an L2 cache has been available for use by RISC OS, and should help to speed up many common memory-intensive tasks.
• Improved memory interface - As many people will testify, the memory interface of XScale-based CPUs contains flaws that severly limit the available bandwidth. Cortex-based CPUs do not suffer from these flaws, and as a result the CPU has approximately 4x greater memory bandwidth available, despite the fact the RAM is often clocked slower (165MHz DDR on a BeagleBoard compared to 200MHz DDR in an Iyonix).
• MMU enhancements - The addition of a second L1 page table pointer allows for much faster task switching than the current lazy task switching system, and as a result a more responsive desktop (Although it is questionable whether anyone will notice the difference!)

• Flexible display controller - The display controller supports upscaling/downscaling and rotation of the display, helping to make the OS more usable on portable devices with small or irregularly-sized screens.
• Hardware YUV overlay - Nowadays this is an essential feature for video playback. When used together with the VFPU, it should greatly improve RISC OS's media player capabilites.
• C64x+ DSP - A second processor capable of running programs independently of the main CPU. Its instruction set is tailored to performing audio/video codec functions; once suitable drivers exist for RISC OS it will be able to alleviate the CPU of much of the work needed for video playback.
• SGX 3D core - Although the SGX drivers remain closed-source, there is some hope that in the future RISC OS will gain the ability to use it for hardware acceleration of 3D games or other rendering tasks.

• No IDE/SATA controller. Instead builtin flash memory (typically 256-512MB) and SD/MMC cards are used for primary storage. Although the price of SD cards has dropped significantly in recent years, they still don't offer the same price/GB ratio, speed, or total capacity as a hard disc. Secondary storage devices such as floppy or optical discs must be connected via USB.
• No PCI/podule bus. Instead USB is used as the main form of expansion, which could cause problems with device/driver compatability, or the poor CPU performance currently offered by the Castle USB stack.
• Limited display resolutions. The maximum pixel rate the OMAP3530 is capable of is 86.5MHz - which is just about enough for 1280x1024 at 57Hz. For portable devices like the Pandora or Touch Book this isn't much of an issue, but for people planning on using a BeagleBoard as their main computer it may be very important. The display controller is also incapable of generating the timings required for many standard VESA modes, so you may find that some tweaking is required to get an MDF that works well on your monitor.

Getting started

A while ago I got my hands on a BeagleBoard of my own, to help me more effectively work on the RISC OS port. For anyone else looking to get involved with porting RISC OS to the board, here's a rough getting-started guide, along with a few of the things I've learnt whilst working with the system.

List of parts

The first thing you'll need to do is draw up your shopping list.

• A BeagleBoard. The only official retailer is Digi-Key, who use UPS express delivery to get your board to you within a couple of days, even if it's been sent from the USA. Most other vital equipment can be ordered from Digi-Key also, although not always at the best of prices. Just be aware that if you are in the EU, you'll have to pay the delivery man VAT when he delivers your board (This will be about £20 in the UK if you just buy a board and a serial cable). You may also have to answer a couple of questions from Digi-Key via email to help convince the US export officials that you're not an evil terrorist, or put up with their ordering system mistakenly flagging the beableboard as export-prohibited and cancelling your order - but since it's free delivery for orders over you can't really complain.
• A case. Although not mandatory, a case will help protect your board from knocks, bumps and spills. Currently Special Computing are the only supplier known to sell cases, although at for a case and for international shipping it's hardly a cheap addition if that's all your in interested ordering from them. Special Computing also sell BeagleBoards and a few other supplies, so if you aren't worried about the fact that the Beagle Hospital only accepts RMAs on boards bought from Digi-Key then an order from Special Computing may be more appropriate for you.
• A power supply. You have a few options available here:
  • A USB cable plugged into the USB OTG port. All that you'll need for this is a standard USB A to mini-B cable and something to plug the other end into (e.g. a PC or a powered hub). If you own a PDA, PSP, digital camera, or fancy mobile phone then you may already have an appropriate cable.
  • A dedicated power supply plugged into the DC jack. 1A at 5V is all that's needed, although you should also be careful to make sure the jack is the right size and polarity (check the reference manual if you're in doubt)
  • A USB cable plugged into the DC jack. Special Computing are the only place I know of that sell an appropriate cable; I've had trouble tracking down suppliers in the UK.
  Just be aware that if you're powering the board via a USB cable then there will only be around 100mA of power available to the USB port(s), which is only really enough for one low-power device. But since the board only has two USB ports you'd usually want to use it with a (powered) USB hub anyway.
• A serial cable. Although you might be able to get by without one, it's strongly recommended that you have a serial cable available as it's the only sure-fire way of configuring the U-Boot bootloader that's used by the board. It's also the easiest way of debugging nasty RISC OS crashes, or setting up a different operating system such as Linux.
  The serial cable header on the BeagleBoard is suitable for an IDC10 connector. This is the same as used in most old PC's, so you may find that you've already got a suitable ribbon cable to convert from IDC10 to DB9M (The standard 9-pin serial connector). Then you can use an ordinary null modem cable to connect it to your host machine. If you don't have a suitable IDC10 cable handy, then both Digi-Key and Special Computing sell cables that can be used.
• HDMI/DVI cable. HDMI is backwards-compatible with DVI-D, so to save space on the board a HDMI socket is used instead of DVI/VGA. This means that with the appropriate cable you can connect the board to either an HDMI or DVI display - but not to VGA, as the board doesn't supply any appropriate analogue signals. With a good HD TV or monitor you may find that you can use high screen resolutions such as 1920x1080 @ 30Hz. For ordinary monitors 1280x1024 @ 57Hz is about the best you can expect. If you have a choice between HDMI and DVI, DVI is perhaps the best, since it allows the board to read the EDID information of the monitor (assuming the OS is capable of doing something with it!)
• Powered USB hub. The board itself is usually only capable of providing a small amount of power to the USB ports, plus there are only two ports available. A hub is therefore mandatory if you're planning on using the board for any serious work. Almost any powered USB hub should do, although you'll have to take into account how many ports you'll be using. The good news is that you can use the hub to power the board itself - i.e. one USB cable running from the hub to the board to provide power, and a second cable running from the board to the hub to provide the extra USB ports.
• USB keyboard/mouse. Technically you could use a USB switch/KVM to connect the board to your existing keyboard and mouse, but since my board was going to be connected to the same monitor as my RiscPC (which doesn't use a USB keyboard or mouse) I figured it would be a better idea to buy a dedicated device just for the board itself. Since I'm short on desk space I decided to try something new, and went for a mini keyboard with builtin trackball. Wireless keyboard+trackball/touchpad combos are easy to come by, but since I can't abide by replacing/recharging the batteries in wireless peripherals I went for a more expensive wired version. The only downside to a keyboard+trackball/touchpad combo is that most seem to only have two mouse buttons, so a seperate utility will be needed to use them properly with RISC OS (or in my case, a few minutes of hacking around in the USB HID driver to remap the Windows key to the middle mouse button).
• USB network adaptor. Not a necessity, but it's the easiest way to get programs to and from the board once the OS is installed. Although I have a couple of USB wifi dongles lying around the place, I wasn't sure if any of them worked with Linux, or even worse, whether any of them had open enough drivers and documentation for a RISC OS port to be made. With that in mind I decided to buy one of the cheapest USB ethernet adaptors I could find, under the assumption that cheap + mass-produced = high chance of open source drivers. Luckily this plan worked, as the device I bought has open source drivers available for both Linux and NetBSD. Plans are already in place to add support for the device to James Peacock's EtherUSB module so that it can be used under RISC OS. Note that you can also get USB hubs with builtin ethernet adaptors, such as the one sold by Special Computing, or by searching for 'laptop docking station' on any big retailers website. However these devices are often more expensive than if you were to buy a seperate hub + network adaptor, or may come with extra unwanted features (e.g. audio in/out, USB VGA adaptors, etc.)
• USB cables. To make the most of the OTG port you'll probably want two cable. The first is a male A to male mini-B cable to allow the board to be used in gadget mode. This cable will also allow you to power the board via USB. The other type of cable is a male mini-A to female A cable, which allows the OTG port to act as host - but since all new BeagleBoards have a standard full-size USB host port this could be an optional purchase. Finding places selling male mini-A to female A cables is a bit tricky - Special Computing sell them, as does this amazon seller.
• SD/MMC cards. Although the BeagleBoard does have 256MB of internal flash, it's not the best choice of storage medium for a writeable filesystem because it lacks hardware wear levelling. The NAND chip on the BeagleBoard is soldered ontop of the CPU and RAM, so there's no way of replacing it - unlike a cheap and disposable SD/MMC card.
  With that in mind you'll want at least one SD/SDHC or MMC card to use with the board, or more if you're doing serious development work or want to easily use multiple operating systems. For maximum compatability you'll want to make sure that the cards are supported by the ROM bootloader - this means they must be 3V 4 bit cards. Even though new versions of X-loader and U-Boot will work with cards which the ROM bootloader won't, it's a good idea to have at least one ROM bootable card around the place in case you corrupt the copies of X-loader/U-Boot that are held in the internal NAND memory. Also remember to get a USB SDHC/MMC card reader if your computer lacks one.
• Audio, S-Video cables. Depending on exactly what you're using the board for, you may want audio and/or S-Video cables to hook it up to speakers, a mic, and/or a TV/monitor with S-Video input.

• Formatting SD cards. The ROM bootloader only accepts them if they're formatted correctly, which they might not be when you purchase them. A Windows, Linux or Mac OS X PC should suffice for this.
• Compiling OS images. For compiling RISC OS you'll need a RISC OS machine to do the compiling, and a Windows/Linux/Mac machine for fetching source from CVS using ROOL's shell scripts. For compiling other operating systems, such as Linux or Android, you'll most likely need a real Linux machine, or at least a virtual machine - I don't think there's any guarantee that Cygwin or Mac OS will work correctly with the build systems that most OS distributions use.
• Installing OS images. Most BeagleBoard linux distributions use SD cards with two partitions - a bootloader-compatible FAT partition containing the kernel, and an ext2/3 partition containing the OS filesystem. To set this up correctly a Linux PC or a virtual machine is needed (Mac OS X will probably do the trick also). Windows alone is unlikely to work, due to poor support for ext2/3 and SD cards with multiple partitions.
• Communicating with the board. Any computer with a serial port, including RISC OS machines, should be able to do this. You can communicate with recent versions of U-Boot using the USB OTG port instead of the serial port, but unless the OS you're running on the board also supports using the OTG port in that manner you may run into some difficulty if the OS takes a dislike to your keyboard/mouse/monitor.

What to do when your board arrives

The first thing to do when your board arrives is to make sure that it works! The best way to do this is by following the instructions in the BeagleBoard System Reference Manual, or on the BeagleBoard wiki. This should also serve to familiarise you with terminology such as X-loader, U-boot, and the tasks required to create bootable SD cards. If you want to try a more complete system to test out your board, you can also try out the Angstrom Linux demo image, although if you're unfamiliar with linux you may struggle to do some of the more useful tasks such as changing the screen mode, running the omapfbplay video player, or installing new software.

After that you'll probably be wanting to try out RISC OS - in which case the guide on the ROOL wiki should contain everything you need to know about building the source and starting the ROM image (skip the start bit and scroll down to 'Getting started with the source code').

BeagleBoard impressions

There are several operating systems available for the BeagleBoard at the moment - Angstrom Linux, Ubuntu Linux, Android (itself based around a Linux kernel), Windows CE, and of course RISC OS. Angstrom is widely regarded as being the Linux distribution with the most support for the board and its features, so here I take a look at how it compares to RISC OS in terms of functionality and ease of use.

Angstrom Linux

After playing with Angstrom for a while, using both the demo image and my own self-built one, a few things became clear to me. Angstrom Linux, despite having its roots in ARM-powered PDAs such as the Zaurus range, still appears to suffer from the same problem as most other Linux distributions - the desktop experience is rather lacking. Beyond the SD indicator light flashing there's no indication whether the program you just clicked on is launching or whether it has silently failed. The Angstrom display manager doesn't yet support the new OMAP display drivers, so you're only able to change the desktop resolution by changing the kernel boot parameters, or entering the right values into a terminal window and restarting X. Angstrom also seems to be rather heavy on memory utilisation, with the memory monitor app reporting that around 100MB of the boards 256MB had been used by the time the desktop was reached.

But on the bright side, Angstrom does get several things right. It's the only Linux distribution to support all of the boards hardware features out-of-the-box, and installing extra software using the Angstrom package manager is easy (even if the online package browser is a bit broken at the moment). Firefox 3 seemed responsive, apart from the long time it takes to load pages - although I have a feeling that was more to do with dodgy USB drivers than a fault in Firefox itself.

It will be interesting to see what improvements are made to Angstrom once commercial devices such as the Pandora start shipping.

RISC OS

A lot of people seem to be interested in when the right time is to start buying BeagleBoards, Pandoras, Touch Books or whatever for general RISC OS work, so I might as well give an overview of where the RISC OS port currently stands and how it stands up to its main competitor, Angstrom Linux.

The most important thing to mention is that it's not yet a polished experience. There's no support for automatically loading/saving the CMOS RAM state, so the OS will always boot to the supervisor prompt. RISC OS also takes several seconds to reach the supervisor prompt instead of 1-2 seconds, due to the current slow implementation of the RAM clear code. If you're board is powered by the hub that the board is using for USB ports, then it will take even longer, as RISC OS attempts to poll the unresponsive USB OTG port. There's no !Boot sequence publicly available that is tailored to the hardware, so you'll have to build your own if you want to try running most apps from the desktop. The driver for the USB host port, although mostly functional, appears to have flaky device insertion/removal detection, so hotplugging storage devices often results in the dreaded 'Ambiguous disc name' error from SCSIFS. Performance of filecore-formatted USB drives is atrocious - an 8GB class 6 SDHC card, which should give at least 6MB/s read/write performance, takes up to two minutes to mount and only offers ~500KB/s transfer rate. Changing screen mode runs a risk of about 1 in 5 that the computer will lock up. Changes in the instruction set related to unaligned loads/stores means that, for the moment at least, most precompiled software won't run. A bug somewhere prevents you from setting the system clock to the correct time and date. Even if you could set the correct time and date, the lack of backup battery on current BeagleBoards means you'd have to reset the clock each time the computer boots (although this could be fully automated once the USB network drivers are more mature). There's currently no support for hardware acceleration of graphics redraws, so although some aspects of the desktop are responsive others are not (e.g. the 10 or so seconds it takes for '*modules' to complete its listing if you enter it after hitting F12 while in a high-resolution screen mode). There's also no support for any hardware differences between devices that use the OMAP3530, so even if you had a Pandora or Touch Book in your hands right now the chances are that RISC OS won't run on it.

But on the bright side, all of the above can and will be fixed, hopefully in time for the first consumer-oriented machines to start hitting the market. Even at this early stage it's clear to me that RISC OS still beats Linux in terms of memory usage, desktop responsiveness, and user-friendliness of application launching. If netbook manufacturers think that ARM netbook users won't be too worried about their inability to run Windows apps on ARM Linux, perhaps we'll be able to tempt a few ARM Linux users onto an operating system that provides a better desktop experience?

Benchmarks

Enough of the pointless speculation of about the OMAP's performance relative to existing RISC OS machines. Let's have some pointless benchmarks instead!

Dhrystone

Dhrystone is a benchmark that's often abused by people using compilers that detect the Dhrystone source code and replace it with hand-optimised assembler. But regardless of that, it can still be a useful benchmark, especially if you're in control over which compiler and settings are used.

Using RISC OS GCC 3.4.6 r3, I compiled the Dhrystone benchmark program, using the sources that are supplied with GCC. The Dhrystone program was then used to compare the performance of a BeagleBoard (running at the default CPU clock speed of 500MHz) and my Iyonix, resulting in performance figures in both Dhrystones/sec and DMIPS. Overall I ran the test twice - once without any optimisation, and once with ordinary -O2 optimisation. In the results, higher numbers = better.

Compiler setting	Iyonix score	BeagleBoard score	Relative performance
-O0 -mlibscl	395296.6 dhry/s = 225 DMIPS	467289.7 dhry/s = 266 DMIPS	118%
-O2 -mlibscl	806451.6 dhry/s = 459 DMIPS	1176470.6 dhry/s = 670 DMIPS	145%

Although these results fall rather short of the 1,200 DMIPS that ARM claim, they do show the speed advantage the Cortex has when performing CPU-intensive tasks using code produced by a standard compiler using standard optimisation settings.

Ackermann

The Ackermann benchmark is meant to be something to do with measuring the coding efficiency of procedures. That's about all I know about it, except that depending on the input parameters it will either complete the benchmark almost immediately or take longer than my patience (e.g. 10 seconds). Once again GCC 3.4.6 r3 was used to compile the source, both with and without optimisation. The resulting executables were run with '3 9' as the parameters. In the results, lower numbers = better.

Compiler setting	Iyonix score	BeagleBoard score	Relative performance
-O0 -mlibscl	534	150	356%
-O2 -mlibscl	203	96	211%

RISC OS mark

Finally something a bit easier to understand, and with benchmark results readily available for a variety of RISC OS machines. For these tests, RISC OS mark 1.01 was used to compare my RISC OS 5.12 Iyonix, running at 1920x1200x16M, against the 500MHz BeagleBoard at 1280x1024x16M. Note that the percentage scores as produced by RISC OS mark are relative to the base system of a 200MHz StrongARM RiscPC, so if you own one of those you'll have an indication of how well a BeagleBoard compares to that.

Test	Iyonix score	BeagleBoard score	Relative performance
Processor	260%	294%	113%
Memory (copy 128KB block)	187%	1089%	582%
Memory (copy 1MB block)	200%	832%	416%
Rectangle copy	1483%	38%	2.5%
Icon plotting	181%	305%	168%
Draw path	95%	163%	171%
Draw fill	53%	150%	283%
HD read (MB/s)	15	1.3	8.6%
HD write (MB/s)	39	1.3	3.3%
FS read (KB/s)	2520	2	0.0008%
FS write (KB/s)	2719	2	0.0008%

A few notes about these scores:

• The default RISC OS mark memory test of copying a 128KB block would have caused the results to be heavily skewed by the 256KB L2 cache on the beagleboard, so the memory test was performed twice - once with a 128KB block and once with a 1MB block.
• The rectangle copy operation has the potential to be sped up significantly once code is written to make use of the OMAP's DMA engine for hardware acceleration. The DMA engine in the OMAP is capable of rectangle copies, fills, and rotations, so should easily provide a level of hardware acceleration similar to that available with the Iyonix or ViewFinder/V-Pod equipped RiscPCs
• The Iyonix was using an IDE hard disc, whereas the BeagleBoard was using dog-slow USB mass storage. This is why the filesystem scores for the BeagleBoard are so low. These scores should improve over time now that the USB stack and USB mass storage drivers are a more important part of the OS.

!Befunge

I would have chosen something more useful for this last test, such as compressing files using command-line zip, but I was unable to find a compiler setting that would produce a working executable (presumably due to unaligned load/store issues). So instead I decided to try !Befunge, my WIMP Befunge interpreter, which luckily ran without any problems. To test the relative performance of the two systems I ran my turtle quine through the interpreter. On the Iyonix it completed in approximately 70 seconds, while on the BeagleBoard it took approximately 23, resulting in a relative performance of 304% (saving the resulting DrawFile to RAM disc instead of USB to avoid a nasty penalty).

Conclusion

What the OMAP3530 gives with one hand it takes away with the other. Although it's undoubtedly going to be the most powerful ARM CPU to run RISC OS, it's also going to require a certain amount of hard work from OS and application developers in order to support the new hardware features such as the VFPU, and to work around architecture changes such as the handling of unaligned loads/stores. The OMAP3530 may not offer high-resolution screen modes or a fast expansion bus, but it's an important platform to support if we want to see RISC OS running natively on affordable new hardware instead of just under emulators or geriatric RiscPC's.

9 comments in forum ]]> Tue, 19 May 2009 11:00:00 GMT http://www.iconbar.com/comments/rss/news1223.html http://www.iconbar.com/comments/rss/news1223.html The 2009 Wakefield Show takes place today.Stuart Tyrrell Developments' have unveiled their VPod graphics accelerator. For GBP149, the podule card for the Risc PC range of computers features hardware acceleration and high resolutions such as 1680x1050 in 16 million colours.NetSurf 2.0 has been released and is available for download on the NetSurf website.RISC OS Open has been demonstrated running on a A7000 computer. The 2009 Wakefield Show takes place today.

• Stuart Tyrrell Developments' have unveiled their VPod graphics accelerator. For £149, the podule card for the Risc PC range of computers features hardware acceleration and high resolutions such as 1680x1050 in 16 million colours.
• NetSurf 2.0 has been released and is available for download on the NetSurf website.
• RISC OS Open has been demonstrated running on a A7000 computer.

29 comments in forum ]]> Sat, 25 Apr 2009 08:01:00 GMT http://www.iconbar.com/comments/rss/news1221.html http://www.iconbar.com/comments/rss/news1221.html Reader Mike sent in these pictures of something he found while out walking his ferret. Yes, we have readers with ferrets. Although the concept of a reader with a ferret confuses us, luckily we don't have to use our brains for this update because Mike was kind enough to send in some words to accompany the pictures.

Standard disclaimer: As most of you have probably noticed, this was our April Fool's piece for this year. If you liked our UK:Resistance theme used for the fool then you'll be glad to hear it's been added to the theme selector available from your account control panel. Of course in the end the joke was on us, because UK:R changed their website design from traditional red and black to their new colourful layout a couple of months ago. Oh well!

Click the owly pic above to see the article in its intended guise.

"Dear The Icon Bar, here are some pictures I took while out walking my ferret last weekend."

"I believe that you will find this very interesting, not for the fact that I own a ferret, but for what the pictures contain."

"As you can see I have followed the customary rules for taking multiple photos of the target object from a number of different distances, both to prove the authenticity of the find and to help build to a suspenseful conclusion."

"The object I found, a glorious one-slice Acorn Risc PC, was far from its natural habitat, and clearly the worse for wear."

"Perhaps it had been out drinking with friends the night before, only to get ambushed by faster, more power-hungry Wintel machines."

"If ever there was a case against knife crime in the UK, this would be it. - Mike"

Unfortunately Mike saw fit to take more photographs than write sentences, so we'll have to continue the rest of this on our own.

But that's OK - we've recovered from the news that Mike owns a ferret.

That's because we've now come to realise that this isn't any old down-and-out Risc PC.

This is a Risc PC 700!

A FEMALE!

Seemingly aware of this fact, Mike reaches in for a closer look...

This is illegal in most counties, you know.

You'd better clear your browsing history and burn your modem after finishing viewing this.

Will you look at the chips on that!

A StrongARM revision K! This was a high-class girl!

Come here baby, let me take a closer look...

Say, do you want to come back to my place? We could hang out...

Oh, sorry madam, I didn't realise.

Even though this girl is clearly well past her use by date and infested with disease, Mike still goes on to take over fifteen additional photos.

I don't know if you and your ferret get off on that kind of thing, but we certainly don't.

This is the last time we open any emails from a ferret owner. Or a Mike. We haven't decided yet.

4 comments in forum ]]> Tue, 31 Mar 2009 23:00:00 GMT http://www.iconbar.com/comments/rss/news1222.html http://www.iconbar.com/comments/rss/news1222.html THIS IS AN APRIL FOOL AS WELL THIS IS AN APRIL FOOL AS WELL
Just in case you can't tell.

We just received this by courier from Stuart Tyrrell:

Ok, so we're not Roman, but when have we ever let a small detail like that get in the way of a good party? And, if we're talking of partying, who better to show us the way? Ave Caesar!

It's been exactly V years since we last marked Veneralia with a product launch so we thought that it was about time that we did it again.

Last time it was our unique UNIpod hopping onto the stage that caused the uproar and has proved incredibly popular ever since. This year we're hoping our vibrant Vpod will spring forth to a similarly vast audience.

UNIpod: the only podule you'll ever need
Vpod: the only other podule you'll ever need ;-)

It's early in the season and Vpod is still a little bud, full of potential and vitality, verging on blooming but not yet bearing fruit.

We expect them to ripen by the 25th of April and to have a bountiful crop in time to produce stunning displays at the Wakefield flower^H^H^H^H^H^HRISC OS show.

So come along and share our vivid Vpod vision!

Venus Verticordia, the guest of honour at our celebration, had this to say about the Vpod: "I love it already and so will you!"

Adjusting her myrtle wreath vainly, voluptuous Venus voiced, "Vpod is such a fantastic product, I'm glad you named it after me."

Sorry, no pictures are available yet. Our artist has run out of #ffcba4, he expects to be able to pick some more up on his way back from lunch.

He dithered about mixing #ffcda3 and #ffc9a5, but he likes his pictures perfect.

Notes for Romans
Wakefield is a new town on the road from EBVRACVM to DANVM, between LAGENTIVM and CAMVLODVNVM.

Wakefield show: Dies Saturni xii Aprilis MMIX

Vpod costs X denarii

2 comments in forum ]]> Tue, 31 Mar 2009 23:00:00 GMT http://www.iconbar.com/comments/rss/news1220.html http://www.iconbar.com/comments/rss/news1220.html Newsgroup postings and the Portsmouth local newspaper are reporting that Paul Vigay was this morning found dead near his home in Southsea after being reported missing last night. His death is not being treated as suspicious. An online book of condolence has been opened for Paul. Newsgroup postings and the Portsmouth local newspaper are reporting that Paul Vigay was this morning found dead near his home in Southsea after being reported missing last night. His death is not being treated as suspicious. An online book of condolence has been opened for Paul.

Paul was well known throughout the RISC OS community. He became interested in computers around 1978 and had an extensive knowledge of a range of computer platforms from Acorn, Commodore, Sinclair and Atari to mainframe and mini systems to 'current' machines such as Iyonix's, PCs and Macs. In 2005 he started his RISC OS friendly ISP, Orpheus Internet.

Links
Original The News (Portsmouth) article
Second The News article ("Mystery of man found dead in the sea") (Front page thumbnail)
Third The News article ("Tributes paid to Hampshire UFO Expert")
BBC News article
Online book of condolence for Paul

13 comments in forum ]]> Fri, 20 Feb 2009 16:50:00 GMT http://www.iconbar.com/comments/rss/news1219.html http://www.iconbar.com/comments/rss/news1219.html 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 channelsWatch shows on BBC iPlayerPlay downloaded videosHere's how I got on. 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

The Mac

This was an old PowerPC Mac mini: 1.4Ghz G4 processor, 1GB RAM and 80GB 4200rpm hard drive. Although not very powerful by today's standards, it has decent connectivity - USB, Firewire 400, bluetooth, gigabit ethernet, and 802.11g wireless networking.

First I performed a clean installation of OS X Leopard. This left me with about 60GB of free disk space for recording TV programmes. A half hour show takes approximately 1GB of space, so I should be able to store at least 24 hours of TV without any trouble. If the internal drive fills up I'll try connecting a firewire hard drive.

Lovely as Leopard is, I didn't want to use the desktop interface from the sofa. There are several good media centre applications, but few support the PowerPC architecture. XBMC (XBox Media Center) and Boxee (based on XMBC, but with an emphasis on social networking) only support Intel processors, and the (unofficial) Mac port of MythTV has little support for USB TV tuners.

This left me with Front Row. Version 2 comes as part of Leopard and is very similar to the Apple TV interface (although the implementation is rather different.)

Connecting to the TV

How could something so simple prove so troublesome? The only suitable connection type was VGA (using a DVI to VGA converter), but my Samsung television has notorious problems connecting to it. Sometimes the computer would boot up and display sucessfully, but it would usually either not display anything at all (the TV would give no indication as to the problem, merely blinking its standby light) or flash on for a few brief seconds before disappearing again. This was particularly troublesome if the TV had been switched off for a while but the computer had not.

In the end, I resorted to a hardware hack. I removed pin 12 from the VGA cable, disabling the monitor detection facility. This allowed me to choose a more reliable resolution and frequency (1280x768 @ 75Hz) instead of the default (1360x768 @ 60Hz).

It's still not perfect but switching to a different input source and then back to VGA seems to help.

Annoying.

Control

The old Mac mini doesn't have an infra-red port so I couldn't use an Apple remote with it. This is a shame as the alternatives aren't quite as user friendly as I'd liked.

First I experimented with iPhone apps to simulate an Apple remote. The first, Rowmote (59p), worked reasonably well when the iPhone was connected to the wireless network. Unfortunately the iPhone disconnects from the network after a period of inactivity, causing the virtual remote to cease functioning, and it became frustrating having to prod it and wait for it to reconnect.

I tried a second app, Snatch, which is more expensive (£3.49) but comes with a free trial version. This has added usefulness like a virtual keyboard and the ability to use the iPhone screen as a touch pad (like a laptop). Although the touchpad interface was slick, the app proved less than great as a whole - the interface isn't particularly slick when switching between different modes and the interface for creating virtual keyboard buttons was horrible: the editing controls were small and fiddly and there was a complete lack of feedback when recording keypresses. In addition, some of the shortcuts I assigned (such as the one to open Front Row) didn't work at all.

Finally I tried Remote Buddy. This is a powerful Mac application that allows applications to be controlled by many different types of device - including the Wii remote (via bluetooth). This works very well; you simply hold the 1 and 2 buttons on the remote to connect it to the Mac. I didn't find the default button mappings very intuitive but I soon reconfigured it so I could navigate Front Row and EyeTV effectively. It would be nice to use the remote's infra-red pointing facility to move the mouse pointer, but the sensor bar used by the remote to detect where you are pointing only works when the Wii is running.

Remote Buddy also has an Ajax interface which allows the desktop to be controlled remotely via a web browser. This is neat but sluggish, and dead handy for reconfiguring the system when I couldn't get anything to display on the TV.

It's expensive - 20 euros (£18) but I suspect I'll bite the bullet and buy it when the 30 day trial expires.

Watching TV

This is the best bit. I bought an EyeTV DTT (£35) and it works really well. It comes with a tiny aerial and a little sucker to hold it to the window. It easily picked up a signal for all the Freeview channels. Previously, for the TV, I used a much larger powered indoor aerial which was quite fussy about where you placed it.

You can schedule recordings using the EyeTV 3 software. This is quite neat, particularly the way it creates live searches to record future episodes of shows. The built-in programme guide is fairly comprehensive, although for some reason it seems to have confused Five US with a German TV station. I particularly like that I can log into the tvtv web site and schedule a recording away from the computer. The recordings are saved in MPEG2 format, and you can convert them into iPhone compatible files automatically and access them remotely. (In the end I disabled this feature because the conversion process is very CPU intensive and the poor little Mac mini didn't enjoy the experience one bit.)

It isn't perfect; like a video recorder it doesn't cope well with schedule changes. I tried recording an episode of Being Human but ended up with 15 minutes of overrunning rugby instead. Luckily the guide is good at finding when programmes are repeated (and it can distinguish repeats from new episodes) so it was trivial to reschedule another recording. Hurrah for BBC Three's endless repeats!

There's even a full screen interface which integrates with Front Row thanks to a third party plugin called PyeTV and a bit of funky AppleScript.

Other video

I configured iTunes to share the files from my laptop. This allowed me to play music, TV shows and films through Front Row on the Mac mini. It even worked for DRM-enabled content once I had authorized the Mac mini in the iTunes store.

The Mac won't play most of the popular internet video formats out of the box - for this you need Perian, an open source QuickTime component that adds native support for AVI, DivX and more. The final step was to create an alias in the Movies folder on my Mac mini pointing to the share on my laptop, allowing me to play videos over the network.

BBC iPlayer

I'd like to access the BBC iPlayer too, but I'm yet to discover a workable user interface to it.

There's a handy big screen version but it's still hard to navigate the interface without a mouse and it doesn't integrate well with Front Row. I knew I could access web pages using Couch Surfer, but the virtual mouse pointer (controlled using the direction buttons on the remote) was sluggish and awkward to use. The full screen option didn't work within Front Row either, leaving me with quarter-screen sized videos.

The flash player needs quite a powerful CPU to function properly. Unfortunately the G4 1.4GHz PowerPC processor in the Mac mini couldn't cope with the high quality streams.

Conclusion

It was fun to set all this up, but it's all a bit of a Heath Robinson affair and there comes a point when it's easier to buy something that just works. The Mini isn't quite up to spec for the job (a more recent Intel edition would be much better) but I don't want to spend much on upgrading outdated hardware. If, as rumoured, the next Apple TV has an integrated PVR then I'll be first in line to buy one. Until then, I'll continue with this useful but quirky system.

4 comments in forum ]]> Tue, 17 Feb 2009 12:00:00 GMT http://www.iconbar.com/comments/rss/news1218.html http://www.iconbar.com/comments/rss/news1218.html Once again the time has come to wish you all a Merry Christmas. By the time you read this, chances are that Christmas has already been and gone, although I'm sure some of you will have a peek at the site today whilst chomping on your mince pies :) Once again the time has come to wish you all a Merry Christmas. By the time you read this, chances are that Christmas has already been and gone, although I'm sure some of you will have a peek at the site today whilst chomping on your mince pies :)

From everyone at The Icon Bar, we would like to wish you a Merry Christmas and a happy and prosperous New Year. Thanks for reading TIB in 2008 (what there was of it to read!) and we'll see you in 2009. Oh, and don't forget to vote in Drobe Awards 2008 poll while there's still time!

Links:
Christmas (Wikipedia)

3 comments in forum ]]> Thu, 25 Dec 2008 00:00:00 GMT http://www.iconbar.com/comments/rss/news1217.html http://www.iconbar.com/comments/rss/news1217.html 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. 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.

Test one: DVB-T

Since my first article was largely concerned with converting recorded DVB-T (aka Freeview) TV programmes for watching on RISC OS, I figured the logical place to start would be with testing that. I copied a short clip over to my Iyonix and attempted to convert it to a suitable resolution for playback (416x312x25fps MPEG 1 @ 850kbps). The conversion rate was about as bad as I was expecting - 3fps. But at least it did work, and the resulting file was played back through !KinoAMP without any problems.

Of course since there's currently no software/hardware available to record DVB-T on RISC OS, there's little point in transferring multi-gigabyte files over to a RISC OS machine in order to encode them - you might as well use the PC that recorded the programme in the first place. In my case, my 2.6GHz PC was able to re-encode the test clip at a much more acceptable 235fps.

Test two: YouTube

For this test I saved a .flv file from YouTube and converted it for playback. Since the video resolution was only 320x240, I decided to keep things simple and just used the !FFmpeg WIMP frontend to handle the conversion for me (more on that later).

End result: My Iyonix achieved a conversion rate of 11fps. Since the !FFmpeg frontend used the -sameq option, the quality of the video did not degrade due to the transcoding, but the output file was 3 times the size of the input. Nevertheless, KinoAMP was able to play it back without any problems.

Performing the same conversion on my PC resulted in a conversion rate of 1080fps - so still about 100 times faster than what RISC OS can offer.

Test three: YouTube on a RiscPC

Since the conversion rate on the Iyonix was nearly acceptable (or at least in the double-digit range) I decided I might as well try converting the same .flv video to MPEG on my StrongARM RiscPC, with the right settings for RiscPC playback (288x216x25fps video @ 250kbps, same 64kbps mp3 audio as source). The conversion ran at a less than stellar 2-3 fps, but once more the output was watchable when played back through KinoAMP, and the video quality hadn't degraded too much.

The !FFmpeg frontend

As mentioned earlier, !FFmpeg comes with a RISC OS frontend, which can simplify the task of converting many videos. However it doesn't allow you to specify the output resolution, so if you're converting a high resolution video, or one for playback on a RiscPC, you'll have to run ffmpeg from the command line for the best results. Unfortunately that isn't as easy as it sounds, as ffmpeg seems to have trouble finding files unless you give it the full pathname or remove the filename extensions (which could make life even more difficult since you'll have to specify the output container format manually).

Conclusion

Video conversion on RISC OS - it's now possible, but the poor performance of converting even low-resolution videos like those on YouTube means that it still isn't something you'd really want to do unless you have no better alternative available. However it is worth noting that the current version seems to have been compiled against GCC 3.4.6, which means it's missing out on the soft-float support available in the GCC 4.1.1 pre-release. Soft-float support could result in a significant performance boost, even if it still doesn't result in better-than-realtime conversion.

If you really do want to watch YouTube on RISC OS, you might want to have a look at Murnong, an ffmpeg-based solution again created by Christopher Martin. The transcoding performance isn't likely to be any better, but at least it will simplify the number of steps you need to go through to get a video downloaded and converted.

1 comment in forum ]]> Sat, 20 Dec 2008 20:00:00 GMT http://www.iconbar.com/comments/rss/news1216.html http://www.iconbar.com/comments/rss/news1216.html Saturday 6 December saw the Midlands User Group's RISC OS Christmas Show in Birmingham. The show was held at Birmingham University's Guild of Students, and was attended by a steady stream of people throughout the day. What follows is a brief report and some photos from the event.

The main announcements for this show were from RISCOS Ltd. who had their new RISC OS Upgrade CD available, along with a "RISC OS Virtually Free" CD, which for a few quid gives you a licensed copy of RISC OS 4 to be used with emulators, and comes with instructions for some emulators on how to get started.

RISC OS Open Ltd. had an Iyonix which was running a ROM image built from the publicly available sources, and were selling calendars, t-shirts, mouse mat and coaster packs and source CDs.

Orpheus and RISC OS Now were also present, notably with free mince pies for the punters (which were yummy!). A new issue of RISC OS Now was available, albeit in A5 size instead of the usual A4 size booklet. Paul Vigay took along an Acorn System One to show off, along with an Enigma Machine kit, which were on display on the Orpheus stand.

NetSurf were in attendance showing off the latest builds of the open source browser, including a Linux build with support for tabbed browsing. CJE had their mini-tardis at the show for all the spares you could need, and R-Comp had their usual selection of RISC OS products for punters, ranging from Games to laptops.

The Acorn through the Ages display contained working examples of Acorn kit from days gone by, from the Atom through to the Omega (although the Omega had an amusing sign on the top stating "Microdigital Omega - Non working". The BBC Model B on display sadly went up in smoke during the afternoon, leaving the unmistakable smell of burning electronics hanging around that half of the room for the afternoon.

Shortly before the show ended, the raffle was held. Each punter who entered had a number on their ticket (I was visitor number four!), and the number was picked randomly by a programme on Graham Shaw's computer, with source code available for anyone who wanted to check it was all above board. The winning number, as I recall, was 20.

Shortly after the raffle, the show drew to a close as crowds thinned out. Overall, it seemed a productive day. There were plenty of people at most of the stands throughout the day, and it looked from my viewpoint at the NetSurf stand that a fair amount of money changed hands around the room. Next year's show will be on the 5th of December. I'll leave you now to peruse the photos below from today's event. For those who missed them, the live feed and its photos are still available for the time being, here.

Show photos

Click a photo for a larger view

The show venue		The show is this-a-way
		Exhibitors getting ready	Punters start to trickle in
	Paul Vigay looks like he's up to something...	He's got an Acorn System One, and a built Enigma kit	ROL look ready for Christmas
Paul Vigay shows off his kit to Drobe's Photographer and ROOL	CJE get busy	RISC OS Now was popular with the punters (and exhibitors!)	Advantage6 had some A9 all-in-ones
	ROL check out the opposition	John Cartmell looking amused	Despite this photo, the Atom was working
This BBC B later went up in smoke, leaving the smell of toasty electronics hanging around for a while	Archimedes and A3010 on display	A5000, A7000 and RiscPC	A portable BBC Master
R-Comp had lots to sell	Orpheus special offers	NetSurf	A rather dark MW Software (sorry Martin!)
Microdigital Omega. Non working	Home-Made portable	Another look at that non working Omega	A9 Home in a briefcase, and a VA-running laptop
Kinetic RiscPC in a tower case	ROOL goodies		Meteors, anybody?
Linux port of NetSurf with tabbed browsing	Iyonix running a ROM image built from publicly available sources	General show atmosphere	Another look at PV's Acorn System One and Enigma kit
Electron		Another look at the Omega
		Paul Vigay had free mince pies!	I decided to not ask.
	The show starts to wind down		Artworks and Easi/TechWriter highlights
R-Comp find a quiet moment	Just after the raffle. The chap behind the chap in a suit won.

10 comments in forum ]]> Sat, 06 Dec 2008 20:43:00 GMT