First screenshot: Beagleboard runs RISC OS 5 desktop

Published: 10th May 2009, 19:01:35 | Permalink | Printable

Picture exclusive - This is the first screenshot of Jeffrey Lee's port of RISC OS 5 for the ARM Cortex-A8-powered Beagleboard reaching the familiar ROS desktop and running several built-in applications. The port was produced using source code made available by the RISC OS Open initiative.

Click for a larger image

Jeffrey told Drobe he will submit his latest changes to the operating system's blueprints to RISC OS Open and publish instructions on how Beagleboard owners can build their own RISC OS 5 ROM images to test drive.

He said: "Later on today once I've worked out the last couple of issues I'll check all my fixes into the ROOL CVS and post a quick guide on the forums so other people can try it out."

Links

Early RISC OS 5 Beagleboard port RISC OS Open website

Previous: Five tips for ROL over the next five years
Next: Bug-fixed NetSurf 2.1 released

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

This is fantastic! Well done, Jeffrey. I think the community owes you an awful lot!

wpb on 10/5/09 7:37PM
[ Reply | Permalink | Report ]

Oh, and a USB to LAN converter! Interesting!

wpb on 10/5/09 7:42PM
[ Reply | Permalink | Report ]

Well done to all those involved in this project and very interesting USB-Lan converter and the Store and Go device.

Looks like things are coming together for a new way to get RISC OS.

bluenose on 10/5/09 7:49PM
[ Reply | Permalink | Report ]

Before anyone gets too excited about the USB to LAN adaptor, remember that just because it's listed by *usbdevices it doesn't mean that it's a device that's supported by RISC OS!

However the adaptor does work under Linux, so my intention (unless someone else gets there first) is to port the Linux driver to RISC OS so RISC OS machines (on the Castle USB stack at least) can use similar network adaptors.

Phlamethrower on 10/5/09 7:58PM
[ Reply | Permalink | Report ]

No, fair enough. We were just getting excited! From the looks of this thread:

[link]

There are some wifi USB adapters that are working with the Linux-loaded beagleboards. That might be interesting, too!

wpb on 10/5/09 8:57PM
[ Reply | Permalink | Report ]

Amazing. Well done.

AW on 10/5/09 10:27PM
[ Reply | Permalink | Report ]

Nice to see this the RISC OS desktop up and running on Beagle board.

sa110 on 10/5/09 10:39PM
[ Reply | Permalink | Report ]

Well done Jeffrey, you are an absolute asset to the platform. Things are looking interesting in RISC OS land again :-)

leeshep on 10/5/09 10:52PM
[ Reply | Permalink | Report ]

Brilliant work.

I like everyone else applaud your work.

nx on 10/5/09 10:54PM
[ Reply | Permalink | Report ]

This is very exciting.

What's the resolution of that screen shot ?

I want to read "an idiot's guide" to getting this bought, up and running with RISC OS.

Is there a UK distributor for the beagleboard ? - I don't have an easy way of paying for stuff in US dollars...

Found an interesting link of stuff to buy such as a suitable case etc but, again, all in the US...

https://specialcomp.com/beagleboard/index.htm

What an amazing achievement, Jeffrey.

Regards, Martin.

martin on 10/5/09 11:17PM
[ Reply | Permalink | Report ]

That screenshot is 640x480. The OMAP3530 is obviously capable of going higher than that, but after loading an MDF the display manager still wasn't letting me change mode so I guess there's another bug somewhere.

There isn't a UK distributor for the beagleboard that I'm aware of, but Digi-Key do provide good service (Express UPS delivery so the board arrives in a couple of days even if it's shipped from the US, and mine came with free shipping - although I can't find a reference for which orders qualify for free shipping). However they do have a downside in that the order process on their website isn't the most consumer friendly, and judging by newsgroup postings they occasionally have hiccups with their ordering software that flags the beagleboard as being export prohibited, leading to lots of cancelled orders and confused customers! Also you do have to be prepared to pay the delivery man VAT on delivery (about £20).

There's also special computing as you mention, which is the only place I know of that supplies a case. Just be aware that the beagleboard support page says that they only accept RMAs on boards purchased from Digi-Key, although I'm not really sure if that's true or not.

There isn't an idiot's guide to setting everything up at the moment. At the moment it's still very much developers-only, especially since there's currently no code to load/save the CMOS RAM state, and the beagleboard doesn't have a battery-backed clock so you'd have to reset the date and time each time you turn it on (Although there are rumours that the next revision of the board will have a battery for the RTC). I'm not really sure what ROOL's plans are for distributing the ROM image - they do have a download for an older version on the website, so maybe in a week or two once the code has settled down they'll put up a new image that's more suitable for the general public. Until then if you wanted to run it you'd have to have the C/C++ tools to be able to grab the source and make your own build.

At the moment I guess buying a beagleboard could be an atttractive option for people looking for a speed boost over a RiscPC, but there's not much point in Iyonix/A9home owners rushing out and buying one unless they plan on helping out with the port or if they have some particular piece of software that needs testing. It will still be a while until all the hardware features are available (e.g. the video overlay and hardware floating point), and a bit longer for software to start making use of the features, by which time there will hopefully be more consumer-friendly devices available like the Touch Book or Pandora.

Phlamethrower on 11/5/09 1:24AM
[ Reply | Permalink | Report ]

Thanks for a highly informative and helpful comment, Jeffrey. (Phlamethrower) Regards, Martin.

martin on 11/5/09 8:52AM
[ Reply | Permalink | Report ]

That's a terrific piece of work! My congratulations to all who contributed.

Has anyone documented the porting process?

It might be useful next time round - and I'm sure it should form the basis of a magazine article.

davehigton on 11/5/09 6:56AM
[ Reply | Permalink | Report ]

Open Source source RISC OS running on 'roll your own' type hardware seems like a really cool development. I wonder if the concept could take the platform in a direction that none of us imagined.

Well done to everyone involved.

Becky on 11/5/09 8:19AM
[ Reply | Permalink | Report ]

It's "shared source", not "open source", unless the powers that be have changed their mind about it. It might be interesting to know what the licence compatibility situation is like when people start porting Linux drivers to this platform, too.

guestx on 11/5/09 10:07PM
[ Reply | Permalink | Report ]

It is open source. It is referred to as shared source because the rules on what you can do with it are different from the usual rules for open source.

If the linux driver is a seperate module then there is no issue. If it were embedded in a single ROM image, there probably would be.

jess on 12/5/09 9:17AM
[ Reply | Permalink | Report ]

Even then, if the driver in question is LGPL, it's probably OK. Alternately, if the adapter works in a BSD, the BSD drivers are fair game.

bhtooefr on 14/5/09 5:46PM
[ Reply | Permalink | Report ]

jess: It is NOT open source. I suggest you go back and look up 'open source' again (try [link]). Opening sentence: Open source doesn't just mean access to the source code.

You absolutely cannot, regardless of contractual issues, distribute any RISC OS component commercially without a license - this is a point upon which all RISC OS-related companies are agreed.

With reference to the porting efforts here, any system would therefore need a commercial license to distribute any system with an OS on it.

This contravenes any acceptable definition of 'Open Source' regardless of the precise licensing position between ROOL/ROL/et al; to use the term 'open source' as people sometimes have done (notably not ROOL members) is therefore misleading.

md0u80c9 on 16/5/09 11:25PM
[ Reply | Permalink | Report ]

Of course, there's nothing stopping somebody just providing a download for the OS image along with instructions on how to get it going on a board bought from Digikey.

rjek on 17/5/09 12:06AM
[ Reply | Permalink | Report ]

Or, better yet, a pre-loaded ROM image that starts up, initializes a USB ethernet interface, downloads the ROM image from the ROOL site, and installs it in the on-board flash.

That's how a lot of Linux distributions get away with "including" closed source drivers that are GPL-incompatible - they don't include them at all, and instead have a script that downloads them and installs them, after prompting the user.

bhtooefr on 17/5/09 3:27AM
[ Reply | Permalink | Report ]

Shame that the pre-loaded ROM will be as complex as RISC OS itself

rjek on 17/5/09 11:50AM
[ Reply | Permalink | Report ]

That is the Open SourceTM definition. (to be able to use the Open Source trade mark)

Normally open source means the source is open to look at. So open source don't need to be licence free.

Jaco on 19/5/09 5:29PM
[ Reply | Permalink | Report ]

Jaco: "Normally open source means the source is open to look at."

Nope. Open source means exactly what the Open Source people said it meant - it wasn't a widely used term before they coined it. Whether or not you aim to adhere to the trademark requirements, calling "look but don't touch" stuff and "shared source" stuff "open source" is just deception.

"So open source don't need to be licence free."

Yet more deception here, too. Open source software generally has a licence attached, unless you're thinking of public domain works.

guestx on 31/5/09 11:44PM
[ Reply | Permalink | Report ]

Absolutely fantastic.

Well done Jeffrey.

As the Krankies would say.......

Fandabbydosie. :-)

Brightened up my monday.

Cheers Bob

nijinsky on 11/5/09 10:45AM
[ Reply | Permalink | Report ]

Jeffrey - you've managed to enthuse a lot of people about RISC OS again. This is a fantastic achievement. I hope it leads to renewed interest in the OS, and further enhancements to ROOL's branch. Many thanks for your hard work!

lym on 11/5/09 11:20AM
[ Reply | Permalink | Report ]

You can by beagleboards from this company in Europe (they have a UK end too):

[link][uid]=456

but they probably won't deal with individuals.

Nice one Jeffrey.

epistaxsis on 11/5/09 12:49PM
[ Reply | Permalink | Report ]

Awesome, this will get me back in to RISC OS!

highlandcattle on 11/5/09 5:00PM
[ Reply | Permalink | Report ]

This is excellent news. But I have a question: When the ROM image is built, does the whole lot have to be compiled from source, or is an existing version used, but a different HAL compiled and added to it?

jess on 11/5/09 5:05PM
[ Reply | Permalink | Report ]

You can build the whole OS in one go, for a specific target. I don't know if the build system allows for different variants to share common elements, or if it has to rebuild them all again.

If RISC OS were cross-compilable, it'd scarcely matter.

rjek on 11/5/09 6:50PM
[ Reply | Permalink | Report ]

Fantastic, well done Jeffrey. Best news for RISC OS in years. Is it possible to turn the beagleboard into a netbook/laptop with the right battery packs and a screen ?

broon on 11/5/09 6:30PM
[ Reply | Permalink | Report ]

Not only possible, but there's a company that's doing exactly that, with a tweaked BeagleBoard design: [link]

It's basically a BeagleBoard rev. C2 equivalent (I believe it's based on the B7, but is feature identical to the C2) with a built-in USB hub, a touchscreen (the touch part most likely USB interfaced,) a keyboard and touchpad (again, most likely USB interfaced,) USB-interfaced wifi and bluetooth, and 8 GiB of MicroSD for storage. Oh, and a couple decently sized batteries.

bhtooefr on 14/5/09 5:50PM
[ Reply | Permalink | Report ]

Yes, I agree, this is really fantastic news. But I will probably wait until the port is more or less completed ;-)

In reply to broon: I think there will be no need to build your own laptop since there are ARM Laptops or better Netbooks coming along this summer - at least several companies announced that they plan to produce them and it seems logical that they will appear. As far as I understand the good thing about the cortex processor is that it includes many other components for video, IO etc. This will hopefully make it quite easy (for those in the know) to not only get RISC OS running on the beagleboard but also on other devices using the same processor. But I may be wrong...

maikl on 11/5/09 8:34PM
[ Reply | Permalink | Report ]

You're close, but not quite right.

The device you're describing is a system-on-a-chip (As used in the A3010 if you can remember that far back!) In the case of the beagleboard the SoC is the OMAP3530, containing the CPU core (ARM Cortex-A8) and various other video, USB, SD/MMC, etc. subsystems. Some of the machines that appear over the next few months will be using the OMAP3530 (e.g. the Touch Book and Pandora), others will use different SoCs (e.g. there should be at least one netbook using the i.MX515 SoC from Freescale). So the amount of effort required will depend on whether the machine uses the same SoC or not.

Phlamethrower on 11/5/09 11:16PM
[ Reply | Permalink | Report ]

I really hope we see these netbooks but i won't be surprised if they never come out companies have been saying for over a year now that they will be releasing an ARM based netbook but have done nothing but show of dev units at trade shows.

I think the one company that could use an ARM chip is apple if it announces a netbook type device in a couple of weeks at it's WDC event as there is a strong chance they will use an OS based of the iphone software instead of the desktop OSX. Also they bought a semi conductor design company last year which had experience i think with ARM chips though it did also work on powerpc chips.

kuliand on 12/5/09 9:56AM
[ Reply | Permalink | Report ]

Words fail me. Well done Phlamethrower! Your effort is a huge step forward for RISC OS. Keep going. I look forward to getting my hands on a netbook/notebook with an OMAP3530 or i.MX515 SoC inside.

DaveLane on 11/5/09 11:56PM
[ Reply | Permalink | Report ]

Well done.

Stoppers on 12/5/09 8:11AM
[ Reply | Permalink | Report ]

So the ARM8's are no faster than the XScale?

AW on 12/5/09 10:47AM
[ Reply | Permalink | Report ]

AFAIK even OS X can run on an ARM processor. I have this from an apple newgroup where they were discussing whether there will be an apple netbook. Some believed that it might be based on an ARM processor, because OS X would run on it and you would get long battery live times.

maikl on 12/5/09 11:23AM
[ Reply | Permalink | Report ]

Yes i have also seen these apple ARM based netbook rumors all over the mac scene now.

Does anyone know how much truth there is to the iphone OS being based on osx?

As if they do come out with a netbook that is ARM based i think it must be based from the iphone software.

kuliand on 12/5/09 11:39AM
[ Reply | Permalink | Report ]

It's based on a similar kernel, and has a couple of the graphics libraries, but to call it OS X is a bit rich.

rjek on 12/5/09 3:25PM
[ Reply | Permalink | Report ]

Apple has, on more than one occasion, stated that they have no interest in entering the Netbook market, but are keeping an eye on it. That said, I think it's more likely they'll release a Tablet-PC kind of device indeed based on iPhone OS or another cousin of Mac OS X.

After the iPhone was introduced, its OS was officially called OS X. After the SDK was released in March of 2008, they officially renamed it iPhone OS. It is based on the same (UNIX-like) foundation as Mac OS X is, namely the open source Darwin OS. For more detailed information, check out [link]

Indeed, Apple acquired P.A. Semi some time ago and Steve Jobs already confirmed in an interview that they will be designing new SoC based on the ARM architecture for future Apple products. As many long time RISC OS users may know, Apple has been long connected with ARM processor technology. P.A. Semi was formed by the lead designer of DEC's original StrongARM design team, Daniel W. Dobberpuhl. See [link]

hEgelia on 12/5/09 3:48PM
[ Reply | Permalink | Report ]

Im still not convinced that apple or more importantly steve jobs thinks that a tablet makes any sense as what would it be used for out in the real world. I think a device with an 8-10" screen needs a keyboard and windows has proven that there is not a huge market for tablet devices as they have all failed.

kuliand on 12/5/09 7:30PM
[ Reply | Permalink | Report ]

Sorry, where's the connection between OS X and long battery life? Even in x86 netbooks, the CPU is not the main consumer of power.

rjek on 12/5/09 3:24PM
[ Reply | Permalink | Report ]

"Some believed that it might be based on an ARM processor, because OS X would run on it and you would get long battery live times."

He means the benefits of ARM for apple are two fold; firstly because OS X runs on it and secondly because of the superior battery life.

Monty on 12/5/09 3:33PM
[ Reply | Permalink | Report ]

Very interesting work, I'd always wondered what would have happened if RON (RISC OS on netBook) Psion's unit had come off!

I may have got this all wrong! Am I correct in saying that in addition to all the work necessary to work on a new 'platform' (Different memory controller and I/0: Video, keyboard, Mouse etc) the build of RISC OS has to be different to cope with difference within the CPU itself?

Is it also true that all non interpreted programs (e.g. not BASIC but compiled C & machine code etc) will need to be recompiled with setting for a Cortex A8?

Which compiler is being used? Acorn C/C++ or GCC I thought the RISC OS sources required Acorn C/C++ I didn't think it had been updated for Cortex-A8 support!

CJE on 12/5/09 11:31AM
[ Reply | Permalink | Report ]

> the build of RISC OS has to be different to cope with difference within the CPU itself?

Correct. The differences are as follows (note: may not be a complete list!) * The MMU and cache handling code in the kernel needed updating to handle the new MMU & cache type used by the Cortex. The MMU and cache differences shouldn't affect any well-behaved programs. * Changes in the way LDR/LDM/STR/STM handle non-word aligned data loads/stores has the potential to affect many programs. So far a few OS modules have been changed, but I suspect 90% of software (espeically that written in C) will continue to work as normal. * Finally there's VFPU support. If a program wants to make use of the hardware floating point, the easiest/best way of doing that is likely to be to recompile it (once the relevant compiler gains support for the VFP instruction set). There's the other non-easy way of modifying the FPEmulator to map old FPU instructions to new VFPU instructions, but that will be a hard (if not impossible) task and won't provide as good performance as a recompiled program would provide. * There have also been a couple of non-32bit compatible pieces of assembler I've found in the OS that previously used to work fine but have now started to fall over. I'm not sure of the exact reason for this, but I doubt it's going to affect any other software (due to the size of the OS it was inevitable that a few bits here and there would fall through the cracks)

So although I haven't actually tried any 3rd party software yet, I believe that most, if not all well-behaved 32bit compatible software will continue to run without a hitch. Then once compiler support for VFP is available, software authors can begin to recompile their code to take advantage of the speed benefit.

Of course there's also the issue of backwards-compatability with machines that lack VFP - this will likely be handled with a new FPEmulator, or just having two different executables (which could be quite attractive now that GCC has software floating point, giving much better performance than FPEmulator on non-FP hardware)

> Which compiler is being used? Acorn C/C++ or GCC I thought the RISC OS sources required Acorn C/C++ I didn't think it had been updated for Cortex-A8 support!

The ROOL sources are still tied to Acorn C/C++, but I believe efforts are underway to improve the source (mainly in the build system and makefiles) to allow GCC to be used (either natively or with the cross-compiler). And I'm sure that both ROOL and the GCCSDK team will welcome any help that people can provide to update the Acorn/GCC compilers to support the new CPU instructions!

Phlamethrower on 12/5/09 1:32PM
[ Reply | Permalink | Report ]

It may be best to enable alignment checking in the coprocessor (CP15, c1; A bit) and then fix up unaligned load/stores in a data abort handler to maintain compatibility with precompiled binaries; Norcroft certainly does(/did) use unaligned LDR to access 16-bit quantities and this sort of behaviour change can lead to obscure bugs that are very difficult to track down.

adrianl on 12/5/09 2:56PM
[ Reply | Permalink | Report ]

Yes, good point. That would also allow the ArtWorks rendering modules to run, which make use of non-aligned loads/stores. Of course, fixing the code will make it run a lot quicker, but it is very difficult to find all places in a program where unaligned loads/stores may be used, so it is important to have a fallback mechanism.

wuerthne on 12/5/09 7:28PM
[ Reply | Permalink | Report ]

Yeah, I'm thinking that using an exception handler might be the best approach, or at least something to consider as an interim solution. The ROOL website seems to be down at the moment but I'll raise the issue on the forums when it's back up.

Phlamethrower on 12/5/09 8:14PM
[ Reply | Permalink | Report ]

Astounding work! Forthcoming RISC OS shows organisers may need to hunt for larger venues soon!

trevj on 12/5/09 4:12PM
[ Reply | Permalink | Report ]

Now what rumours have you been listening to ;-)

helpful on 12/5/09 10:34PM
[ Reply | Permalink | Report ]

Very nice work! My BeagleBoard just arrived and I'll be starting to look at it from a video perspective.

ksattic on 12/5/09 10:54PM
[ Reply | Permalink | Report ]

Cool - I'll do a braindump to a wiki page so we can keep track of what state the video code is in. I'll post on the forums when it's done.

Phlamethrower on 13/5/09 1:09AM
[ Reply | Permalink | Report ]

Very good work (I am surprised at how quickly this has progressed), well done Jeffrey

AMS on 12/5/09 11:44PM
[ Reply | Permalink | Report ]

Nice work...

The cortex netbooks will reach market. None are actually overdue yet. All companies involved have said Q3 this year there will be aprox 5 available and a further 5 before christmas.

A few may not make it but I would have thought there will be some suitable units in the collection.

John

mrmac on 13/5/09 12:33PM
[ Reply | Permalink | Report ]

This is the best RISC OS news since the ROOL initiative was launched. I appreciate there is a long way to go before we have a fully sorted Cortex-A8 version of RO but for the first time in a long while I feel genuinely optimistic for the future. Well done to Jeffrey and others who have worked on this port!

bucksboy on 13/5/09 1:14PM
[ Reply | Permalink | Report ]

[link]

Looks like this might well be one of the first ARM based netbook type devices out on the market still saying Q3 though. Not sure this is the device i'd buy but hopefully one of the bigger players will have ARM based netbook aswell for Q3.

kuliand on 13/5/09 3:06PM
[ Reply | Permalink | Report ]

Nope...

There are plenty of slower ARM based hardware. (netbook like devices) that can already be bought that run linux or CE. No point though as they are slow and cheaply made. Cortex ones will be available Q3 and they are considerablly faster with good grfx hardware and will be available retail for a similar price.

mrmac on 14/5/09 11:40AM
[ Reply | Permalink | Report ]

AW:'So the ARM 8s are no faster than the X-Scale?': concerning basic processing power, I'd imagine they're considerably faster - for a start, ARM quote '600Mhz to over 1Ghz' and 'up to 2000 DMIPS' (presumably for the higher speed range) i.e. 2 DMIPS per cycle which would be double the X-Scale value, and presumably internal bus speeds and bandwidth are greater. I think Phlamethrower was probably referring to the fact that the port doesn't yet exploit the other hardware features. But I'm just an interested amateur; perhaps someone more knowledgeable would care to enlighten us?

bucksboy on 13/5/09 6:51PM
[ Reply | Permalink | Report ]

ARM8 is not the same as Cortex-A8, which is essentially ARM12. While some A8s are partially super-scaler, notice they say "up to"; not all instructions can be simultainously dispatched. In fact, most can't. Most XScales have large caches and very fast interconnects (The OMAP range have a slow local bus and SPI). The new Ferocean/Sheeva XScale cores are meant to be much faster. My bet is that they're similar in performance.

rjek on 13/5/09 8:35PM
[ Reply | Permalink | Report ]

The XScale in the Iyonix is crippled by a fault in the CPU's memory system meaning you can only access RAM at about 10% of the speed you should be able to.

Cortex-A8 in the Beagle board has a dual-issue pipeline which means that two integer instructions can be executed in parallel, as long as there are no hazards stopping this (e.g. one relying on the output of the next).

You also have the new VFP stuff that, given some supporting module, would give a great improvement in FP performance over the FPEmulator.

Finally, the OMAP chip in the Beagle also has a DSP which could be used to farm-off intensive codec-type functions, such as video decode, VoIP, etc.

Over all, I expect the Beagle board will significantly out perform and Iyonix in a number of areas.

riscosopen on 13/5/09 10:09PM
[ Reply | Permalink | Report ]

rjek: 'ARM8', as quoted originally by AW, I took to refer to the Cortex-A8 as in the Beagle board, not the ARM 8 as such - sorry for the confusion. But you (and riscosopen) have addressed the performance issue in any case - thanks.

bucksboy on 13/5/09 11:38PM
[ Reply | Permalink | Report ]

Didn't realise that about the Iyonix. Hopefully video formats should benefit greatly from the new hardware.

AW on 14/5/09 12:04AM
[ Reply | Permalink | Report ]

What didn't you use about the Iyonix? Please use threaded replies, or indicate who you are replying to!

As for the DSP on the OMAP; yes it's quite nice. The licence fee for pre-created codecs and the price of the compiler for it are not.

rjek on 14/5/09 9:15AM
[ Reply | Permalink | Report ]

maybe a fund raiser should be in place for the codecs and compiler, as I have always felt that RISC OS has been let down by video playback capability.

I for one, would place a donation, how much is it?

(as they way you are talking it would cost outside of the RISC OS community's pockets)

em2ac on 14/5/09 10:43AM
[ Reply | Permalink | Report ]

Tens of thousands.

rjek on 14/5/09 11:32AM
[ Reply | Permalink | Report ]

That will be a no then ;@)

em2ac on 14/5/09 3:02PM
[ Reply | Permalink | Report ]

Think you will find machines based on cortex (unless software/drivers are badly implemented) will be considerablly faster than any xscale devices.

I have used so many xscale based devices (including some with poropper GPU's) and have never been overwhelmed by their speed. In fact In the Win CE world I have a 206Mhz strongarm CE device that will browse the web considerablly faster than a number of devices with 400-533Mhz xscale and one with Ati Imageon when browsing and doing in normal tasks, using GUI (in fact even outpaces the xscale in PIcalc up to 200,000 decimal places where after they seem to offer almost the same results.)

IMHO with all the places we will see cortex cpu's can't see it is worth persuing any devices with xscales in them

Still who cares. Beagle board project is great and there is going to be a netbook with a beagle board inside it...

mrmac on 14/5/09 11:55AM
[ Reply | Permalink | Report ]

The PXA series Xscales used in PDAs were seriously crippled, a 200MHz ARM9 based unit could run rings around a 400MHz PXA265 on everything except pure cache bound arithmetic.

But then entire Xscale range suffered from an appalling bad memory system implementation as can been seen on the IOP series used in the Iyonix. And don't even get me started on the hideousness of the pipeline with all of the data hazards the XScale is blighted with, something ARM avoided in their implementations.

Intel are certainly no DEC, and should stick to rebodging PIIIs.

druck on 14/5/09 3:22PM
[ Reply | Permalink | Report ]

By the way druck, did you get my emails about !cineworks a week back?

Monty on 15/5/09 3:13PM
[ Reply | Permalink | Report ]

No I'm afraid not, use my druck at druck dot org dot uk address

druck on 16/5/09 7:26PM
[ Reply | Permalink | Report ]

As someone the other side of the pond who has no "business" being interested in RISC OS, but who does any way, this is great news. At rougly $150 US (which is probably something like 90-100 UKP), the BeagleBoard is probably simultaneously the lowest cost and most powerful RISC OS computer ever.

The one issue with RISC OS adoption in the ARM hobbyist and (eventually, hopefully) netbook markets would be the lack of affordable software. There's good stuff out there, a lot of it costs as much as the BeagleBoard itself. One wonders if Icon could, perhaps, be convinced to make EasiWriter (or at least Writer+) available under terms similar to ROOL's licensing of RISC OS 5. Or maybe they would just need to cut a deal with netbook vendors for volume licensing...

mjk on 14/5/09 1:04PM
[ Reply | Permalink | Report ]

$150 of course gets you the motherboard and RAM; no mass storage or networking. By the time you've put it in a box, added networking, mass storage/optical media perhaps, power supply, gone through required regulation test, I imagine it'll end up costing the same as low-end PCs, which of course can run emulators. Still, a lot cheaper than now, were people still try to sell RiscStations for £550 on eBay.

rjek on 14/5/09 1:19PM
[ Reply | Permalink | Report ]

Well the Touch book (beagle based netbook/tablet) is pre-order price of about £270 with the keyboard module (ok so mass storage is 8gb SD but risc os isn't too heavy on storage a small usb key or usb hdd would supplement it nicely).

If that is the pre-order price then I would expect it to come down in price once retailing.

If it is running RISC OS 5 then that is free. + A lot of you out there will already own a lot of the software you would want to use.

OK so we could do with some holes in the software filled and some reasonable freeware (if we wanted to attract people to have a go) but if a device like this gets a few users back in the swing and maybe a few developers who want to make use of the hardware features to provide better media replay etc. I can only see this as a good thing.

I will be in the market for a cortex based netbook anyway (linux or CE based) so if I can buy somthing that will fill my netbook needs and allow me to have a RISC OS portable I would defo buy more software or updates in our small market.

John

mrmac on 14/5/09 1:33PM
[ Reply | Permalink | Report ]

Now would be a great time for riscpkg to get more software available.

jess on 14/5/09 3:59PM
[ Reply | Permalink | Report ]

No, now would be a great time to replace RiscPKG with something that's maintained and designed.

rjek on 14/5/09 4:10PM
[ Reply | Permalink | Report ]

Anyone fancy converting all of our pre-built downloads into RiscPkg packages? We've been thinking of this for a while but simply haven't had the time within ROOL.

riscosopen on 14/5/09 4:14PM
[ Reply | Permalink | Report ]

I hope you mean writing automated tools to make RiscPkgs. Manually doing it is pointless.

IvanDobski on 16/5/09 10:03AM
[ Reply | Permalink | Report ]

I've just seen the £550 R7500 on Ebay. Jesus that's an optimistic price! That said there is a "Make Offer" button.

IvanDobski on 14/5/09 1:49PM
[ Reply | Permalink | Report ]

I saw that last night. Perhaps the seller has been on another planet for the last few years and still thinks there is a large market for such a system.

sa110 on 14/5/09 2:01PM
[ Reply | Permalink | Report ]

Few years? Try decade.

rjek on 14/5/09 2:19PM
[ Reply | Permalink | Report ]

Given you can still buy the motherboards new for 50 quid, I'm tempted to offer £5.

rjek on 14/5/09 2:21PM
[ Reply | Permalink | Report ]

Too late, I offered £5.50. :P

After wasting his time asking if he'd ship to the US, and asking him what software was on there.

Of course, on a more serious note, how hard is it to get the RiscStation-specific ROMs?

bhtooefr on 14/5/09 6:05PM
[ Reply | Permalink | Report ]

I believe recent RISC OS Selects check if they're running on a RiscStation. So I suspect it's trivial, but best ask RISCOS Ltd. The ABLE ROM that ships with the 50 quid boards might even be able to boot it from the network/disc/flash/etc.

rjek on 15/5/09 12:44AM
[ Reply | Permalink | Report ]

I was under the impression that Adjust was the most recent that could run - ROL's site says that 4.03 (and a RiscStation-specific version at that) is the latest physical ROM that works, and then you can softload Adjust, but not Select 4 or 5.

Source: [link]

If ABLE can do an Adjust softload, though, that works around that problem nicely.

That said, I was just curious, and won't be buying a board, so I probably won't bother asking.

Anyway, if you want to troll the seller, I believe eBay does allow you to make a lower best offer than a previously rejected one, so a downward trend may have a quite funny effect.

bhtooefr on 15/5/09 1:14AM
[ Reply | Permalink | Report ]

For the ultimate low cost high speed ARM-based ready to run device, try the PlugComputer - [link] - 99 US$ will buy you a nice Marvell Sheeva 1.2 GHz-based device with 512MB RAM, USB2.0 and Gigabit Ethernet included. For RISC OS usage, you would of course need something to get Video out of it, i.e. one of the USB-to-VGA/DVI dongles...and a driver for it of course...and an OS port to start with...

Anyone up to the challenge? I'm prepared to sponsor hardware for people who want to have a go. The Marvell Sheeva dev board looks really fancy and would make a nice RISC OS target.

hubersn on 14/5/09 3:23PM
[ Reply | Permalink | Report ]

We have a couple of those at work. They're quite nice. But no IO, really. Also, I don't know of any USB to VGA/DVI dongles for which the specification is available.

Also, tip for SheevaPlug owners: you have cut the provided USB mini B cable's plastic work off for it to actually fit in the console/JTAG socket securely. Sigh.

The Sheeva itself is available in some nice packages that are even easily laid out on 2 layer PCBs (not just 2 layers, 2 layers of PCB!). With PCIe, throw a video card on and such, and away you go. This could perhaps even be done by an advanced hobbyist.

rjek on 14/5/09 3:31PM
[ Reply | Permalink | Report ]

For at least one of the USB-VGA chipsets, there is a Linux/X driver available: [link]

Unfortunately, it has a max. resolution of 1280x1024, and I don't have any experience with the performance of such devices - anyone using such a device on their PC?

hubersn on 14/5/09 4:14PM
[ Reply | Permalink | Report ]

The DisplayLink chipset is very nice; you can even do FMV over it. No specifications, and no drivers for anything other than Windows and Mac OS

I don't get companies who think all their IP is in a protocol, rather than the hardware and software engineering. No matter.

rjek on 14/5/09 4:33PM
[ Reply | Permalink | Report ]

Funny you should mention DisplayLink. Take a look at [link] which only went public today. And guess who wrote libdlo...

riscosopen on 15/5/09 6:40PM
[ Reply | Permalink | Report ]

Say hi to Chris and Tim for me

rjek on 15/5/09 8:34PM
[ Reply | Permalink | Report ]

I've only just found out that I've been using an ARM 11 based device for over a year now - a Nokia N800. Doesn't have quite the same specs as the PlugComputer but is certainly capable of running RISC OS.

gazza_fp on 15/5/09 2:52PM
[ Reply | Permalink | Report ]

Writer+ has been available with many new systems - e.g., bundled with RISC OS 4 and with the Iyonix, so I am sure that an agreement could be found for a newly released machine. It is unlikely that any member of the EasiWriter family will be made available under a similar licence as RISC OS 5.

wuerthne on 18/5/09 1:05PM
[ Reply | Permalink | Report ]

On the plus side, there is no reason why apps bundled with a given RISC OS 5 platform couldn't use their own licence - it's only a problem if you want to include your module in the ROM build, or your code in with some application which is already released under the Castle licence.

riscosopen on 18/5/09 3:13PM
[ Reply | Permalink | Report ]

I can only see comments to the 15th ????

microbits on 16/5/09 9:26PM
[ Reply | Permalink | Report ]

You can only sentence make no sense ???

rjek on 16/5/09 9:57PM
[ Reply | Permalink | Report ]

The truth is a three edged sword.

sa110 on 16/5/09 10:17PM
[ Reply | Permalink | Report ]

Two nuns are a superfluity.

rjek on 17/5/09 12:07AM
[ Reply | Permalink | Report ]

Two nuns and a monk = heaven

sa110 on 17/5/09 8:20AM
[ Reply | Permalink | Report ]

How's your granny off for soap?

Monty on 17/5/09 1:41PM
[ Reply | Permalink | Report ]

I'm not into that sort of thing.

rjek on 17/5/09 2:54PM
[ Reply | Permalink | Report ]

Can we get Castle interested in manufacturing a Cortex-A8 based computer?

DaveLane on 17/5/09 5:26PM
[ Reply | Permalink | Report ]

What would the advantage be over using one off-the-shelf?

rjek on 17/5/09 9:03PM
[ Reply | Permalink | Report ]

Perhaps he is hoping that CTL will release one complete with RO5 pre-installed. There by avoiding the ROL licensing issue.

sa110 on 17/5/09 10:15PM
[ Reply | Permalink | Report ]

Not exactly - but I think we could interest Castle in reselling an off the shelf one with RISC OS.

davehigton on 17/5/09 10:12PM
[ Reply | Permalink | Report ]

I think that would be great provided they can demonstrate definite advantages not least speed over, say, an Iyonix.

AW on 18/5/09 12:18AM
[ Reply | Permalink | Report ]

You mean advantages like being produced as opposed to no longer being produced?

riscosopen on 18/5/09 1:44AM
[ Reply | Permalink | Report ]

No, produced and better performance.

AW on 18/5/09 7:15PM
[ Reply | Permalink | Report ]

Well, we're getting closer to the point where one could usefully start performing some performance tests on the Beagle board. I'm very interested to see what the early results come out like.

riscosopen on 18/5/09 7:29PM
[ Reply | Permalink | Report ]

We just did a couple of very simple tests to compare an Iyonix against a RevB Beagle...

1. OS_CRC on the ROM (4MB)... took around 32cs on average on the Iyonix and around 36cs on average on the Beagle.

2. Copy a 6MB file from RAMFS to RAMFS... took around 51cs on the Iyonix and 21cs on average on Beagle.

So there are mixed results. However, I'm sure you'll agree that given the difference in cost and size, it's a very interesting prospect.

riscosopen on 18/5/09 8:01PM
[ Reply | Permalink | Report ]

very interesting indeed and i would say a good start for the cortex core.

I also imagine that any netbook to use the cortex core would be more powerful than the beagle board.

kuliand on 18/5/09 10:27PM
[ Reply | Permalink | Report ]

cs?

cycles per second?

Jaco on 23/5/09 9:31AM
[ Reply | Permalink | Report ]

Centiseconds. Ie, 100th of a second.

rjek on 23/5/09 12:23PM
[ Reply | Permalink | Report ]

rjek: 'what would the advantage be over using one off-the-shelf'? A number of users (maybe a sufficient number to justify it commercially) might prefer to pay a premium to have a working system 'out-of-the-box', including accessory drivers and storage etc. The advantage for CTL - or any other supplier - would presumably be that there would be no hardware development costs/risks. Speaking personally, I would be willing to buy a beagleboard or similar device and load RO5 onto it once the Cortex-A8 port is sufficiently developed, if that is the only way to get an up-to-date system, but I would certainly consider paying a premium for the complete OS/hardward package from a reputable supplier. AW: more speed would be nice, but a Cortex-A8 RO platform would be a) portable; b) under active development. That would tip the balance for me.

bucksboy on 18/5/09 10:19AM
[ Reply | Permalink | Report ]

Hi all Beaglers, I am sitting here in the Blue-eyed-Maid at a ROUGOL meeting. Anyone have a supportive message for ROUGOL? Can I report to the meeting any up-to-the-minute news about performance of the beagleboard?

DaveLane on 18/5/09 8:17PM
[ Reply | Permalink | Report ]

Did you see my comment about 15 mins ago?

riscosopen on 18/5/09 8:34PM
[ Reply | Permalink | Report ]

Yes, I have told the meeting the times for the 2 tests so far. Anything more? We are likely to be here for some time yet. We won't get turfed out quite yet.

DaveLane on 18/5/09 8:40PM
[ Reply | Permalink | Report ]

There are now a few benchmarks over on The Icon Bar for people that are curious...

[link]

</shamelessplug>

Phlamethrower on 19/5/09 1:11PM
[ Reply | Permalink | Report ]

Very promising :@) I for one would buy a Beagle board based on those bench marks alone! :@)

I still sense a pledge system to reward you all for your efforts, might be popular!

Well done to all of you involved!

em2ac on 19/5/09 1:30PM
[ Reply | Permalink | Report ]

I'd be up for that definitely.

wpb on 19/5/09 7:58PM
[ Reply | Permalink | Report ]

Very nice article on Iconbar, Jeffrey

I was about to plug it but you beat me to it !

Regards, Martin

[link]

martin on 19/5/09 1:53PM
[ Reply | Permalink | Report ]

Ye the OMAP is looking good just a shame about the limited resolution though.

Once the ground work has been done with porting to the cortex A8 core how much work is involved in porting RISC OS to other cortex A8 chips? like the ones from freescale that could be used in netbooks.

kuliand on 20/5/09 10:07AM
[ Reply | Permalink | Report ]

A new HAL and a new set of drivers would have to be written, but overall it should be less work than the total work required for the OMAP port.

Phlamethrower on 20/5/09 1:46PM
[ Reply | Permalink | Report ]

Is the cortex A9 core massively diffrent from the cortex a8 core to allow a upgrade path.

jlavallin on 20/5/09 6:07PM
[ Reply | Permalink | Report ]

The CPU isn't all that different. However, the CPU is only a small part of what's in an SoC; and that stuff can change greatly at the manufacturer's whim. (For example, how to boot it, communicate to sound, USB, video, etc etc etc.)

rjek on 20/5/09 6:56PM
[ Reply | Permalink | Report ]

I thought the main difference between the A8 and A9 was that the A9 allows for a multi core chip.

It still uses the same ARMv7 instruction set as the A8 aswell. But as said above the other components of the SoC can change so that's where the work will have to put in. Im not sure how different the OMAP4 will be to the OMAP 3 but i imagine alot of the SoC components will be changed or upgraded to newer versions.

Also how would RISC OS work with multi cores?

kuliand on 20/5/09 7:08PM
[ Reply | Permalink | Report ]

It's not as simple as that. Multi-core SoCs with ARM9s and ARM11s have been available for some time. My point is that the OMAP isn't a CPU, it's a System on-a Chip. And porting between models of SoCs can be complicated regardless of if you already support the CPU.

How will RISC OS work with multiple CPUs? Not at all well.

rjek on 20/5/09 8:06PM
[ Reply | Permalink | Report ]

Excellent to see such optimism rjek. Sure RISC OS in its current state won't make much use of multiple CPU's but this can and probably will change.

leeshep on 21/5/09 2:33AM
[ Reply | Permalink | Report ]

Simtec has already offered SMP systems for RISC OS with a module and API to allow applications to have multiple threads. The problem is that so much of RISC OS itself and its API assumes a single processor, so any interaction with the OS stalls all of the CPUs. So you get to do a huge source upheaval which is more involved than the 32 bit change, and then get to choose between good performance or compatibility with existing applications.

rjek on 21/5/09 9:48AM
[ Reply | Permalink | Report ]

RISC OS developers need to stop writing software that is so fragile to changes in the OS. Applications also need to contain the source code so that stuff that stops working for trivial reasons can be fixed and patched. Vast quantities of legacy software that's still potentially very useful and useable is failing because of the bewildering number of permutations of systems it needs to run on. Pause.... I feel a rant coming on... Regards, Martin.

martin on 21/5/09 10:17AM
[ Reply | Permalink | Report ]

Martin, the changes needed to make RISC OS a modern system are so massive, it's entirely legitimate for it to break software. Just by including the source in them doesn't mean that it'll get updated to use new APIs, although it does mean there's hope if the author has no interest.

rjek on 21/5/09 10:36AM
[ Reply | Permalink | Report ]

"RISC OS developers need to stop writing software that is so fragile to changes in the OS. "

Riiight. Sure. We do it on purpose you know. We're paid so much and sell such vast quantities of RISC OS software that we just knock out any old s***. What a totally moronic statement to make, Martin, really!

Frankly, what's needed is ANY commercial RISC OS developers right now, if RISC OS is going to go anywhere. If things like Beagleboard and A8 are to be the future, then developing applications to suit (using the VFP for example) will be needed. Throw away prettymuch every piece of 3rd party RISC OS software you've got and do you STILL want to try and use RISC OS as your primary platform? How far will you get? Nowhere really. RISC OS needs application developers as much/more than OS developers -- without apps, an OS is worthless. And I don't mean utterly crud applications like Flicker.

imj on 21/5/09 12:55PM
[ Reply | Permalink | Report ]

"RISC OS developers need to stop writing software that is so fragile to changes in the OS." - possibly a bit inflammatory.

"And I don't mean utterly crud applications like Flicker." - rude.

Let's try to be nice to each other. No one likes to be part of a community where people are like this. Whatever you think about a particular piece of software written by someone else, this isn't the place to make comments like that. Any development is good development as far as I'm concerned.

wpb on 21/5/09 5:44PM
[ Reply | Permalink | Report ]

"Any development is good development" -- probably so, yes. The point is that Martin is completely dissing RISC OS developers, then chucking out stuff like Flicker and actually expecting /payment/ for it! How many versions of RISC OS and how many configurations has that been tested on, I wonder? Does it still work on RISC OS 2? If not, why not? As rjek says, there's very good reasons to move onward and forget RISC OS limitations of the past. Progress is progress and if you don't want it, stick to stuff produced in the era you /did/ like. [RISC OS 2 has a charm long since lost, for example].

Anyway, this particular nonsense argument of Martin's coupled with the Beagleboard work it's hijacked beneath, has me wondering; what exactly IS "RISC OS" now/immediate future. I mean, what do people value most? Being able to run their 1995 issue of Impression, unmodified? (Not on a beagle you won't). Or just the desktop/filer/UI in general? (Which is prettymuch all beagle is likely to offer without some serious rebuilding of major apps from [probably lost] source and dead companies). Do people actually value any apps, or could we design a RISC OS API/UI-alike on, say, x86 and not care about silly ARM chips any more (They have few redeeming features really). How about what MacOS has done, sitting the same kind of UI experience on a completely different OS core?... People still think it's MacOS. What's beagleboard really trying to achieve other than "wooyay look what we COULD have if there were still developers". A feature-slim OS on its own is prettymuch worthless.

imj on 21/5/09 9:24PM
[ Reply | Permalink | Report ]

Rebuilding Riscos on top of netBSD would be good. Huge range of hardware, rock solid OS (so I'm lead to believe) and it would gain attention as a neat UI for existing BSD users.

Ah, dreams.

"What's beagleboard really trying to achieve other than "wooyay look what we COULD have if there were still developers"" Well there are, aren't there? Not many, but some.

Monty on 21/5/09 9:54PM
[ Reply | Permalink | Report ]

NetBSD is cute. Linux is useful, and has vastly better support of extant hardware. Where NetBSD wins is that it's easier to port to /new/ hardware, but Linux has such weight behind it users don't notice.

rjek on 21/5/09 11:59PM
[ Reply | Permalink | Report ]

Cripes - I wasn't trying to be inflamatory.

I may be about to say something that is not the case, but to me it's a depressing task to contemplate write a substantial application for any platform from scratch. It much easier to get going if you've got the essence of an idea in the form of a piece of working code that can be experimented with and developed.

Personally, I keep running into old but very good RISC OS software that does not run on up to date versions of RISC OS. The reasons for it not running are probably, in some cases, trivial. Many software authors have moved on, died or simply lost interest or motivation. Often, a perfectly aimiable original author no longer has the source code because the machine they wrote the software on was dumped/sold or they've lost the source when a Hard Drive crashed etc, etc. Without the source code it's close to impossible to do anything to rescue such software. It's particularly frustrating - hence my admittedly terse earlier post - when entire regions of functionality are lost. It's not just the programs in themselves, it's the potential they carried to be picked up by someone fresh and developed further.

My point was that software authors ought to have an awareness of the need to future proof their efforts as much as possible along such lines. I didn't expect anyone to find this controversial as it's the whole phisosophy behind open source which I hope, ultimately, is direction RISC OS will drift in, although if a few folk make a living out of it along the way, that's fine by me.

Flicker was written because I was given permission by Bob Seago to play around with what I thought was an inspiringly clever set of routines. It's coded with programming notes throughtout so that anyone interested can see how it does what it does. This includes things like responding to a double click on an application's file type, setting up simple wimp menus, setting up a wimp volume control, and grouped radio icons, quite aside from all of the sprite handling routines. So anyone wanting any piece of it can grab that part of it to recycle and reuse.

Andre Timmerman gave permission for it to use his TimPlayer sound module. So if you want to know how to add sound to your app in a way that works on Iyonix, Risc os 4 & 6, and Virtual Acorn, the gist of it is there - although there is still an "input focus" issue that needs to be coded up.

My particular frustration today revolves around trying to find something with which to write (using RISC OS) the "Tracker" files that Flicker plays as a soundtrack. Correct me if I'm wrong, but is there now a single tracker music making program that works on all modern versions of RISC OS ? Is there a tracker music making program that works on *any* modern version of RISC OS ?

There seem to be around eight old tracker music making programs - non with source. There is nothing upon which to build. It's depressing.

Regards, Martin.

martin on 22/5/09 12:27AM
[ Reply | Permalink | Report ]

The reason RISC OS has enjoyed reasonably good compatibility between old software and new is that the OS hasn't moved substantially in the past 15 years. If I were feeling really uncharitable, I'd say 20.

rjek on 22/5/09 12:51AM
[ Reply | Permalink | Report ]

And the same is true of Windows and Unix.

imj on 22/5/09 10:31PM
[ Reply | Permalink | Report ]

There's something to be said for getting it right in the first place

And in Windows's case; slowly and incrementally introducing new APIs and porting it to all the sensible hardware, so software actually uses it.

rjek on 23/5/09 12:18AM
[ Reply | Permalink | Report ]

I would sadly agree with that!

we need an evolution like Arthur > RISC OS 2,

I would gladly help, but haven't learnt C yet (I'm a BASIC man), which I really should get started on. :@)

em2ac on 23/5/09 10:42AM
[ Reply | Permalink | Report ]

Arthur to RISC OS 2 wasn't an evolution, it was a fresh start. Almost no commercial software used the primative Arthur BASIC desktop, but implemented their own full screen windowing system, none survived the transition to RISC OS 2, they all needed a rewrite.

The same thing would be required if RISC OS changed to PMT and multi-core capable, almost every application would need significant work to ensure the assumptions made in a CMT environment were eliminated.

Even if the OS is metamorphosised, who's going fix all those applications, most of which aren't being maintained now?

druck on 23/5/09 6:36PM
[ Reply | Permalink | Report ]

Arthur to RISC OS 2 wasn't an evolution, it was a fresh start. Almost no commercial software used the primative Arthur BASIC desktop, but implemented their own full screen windowing system, none survived the transition to RISC OS 2, they all needed a rewrite.

What about First Word Plus. I remember back on RISC OS 2 (not around in Arthur days), that used it's own full screen mode, own filer etc. Always thought it seemed a bit strange when compared to other programs. I guess it's because it was written for Arthur.

sa110 on 23/5/09 6:48PM
[ Reply | Permalink | Report ]

I know one of the chaps who wrote First Word Plus for the Archimedes. He'd moved onto other things even by then, so wasn't available for doing the rewrite. I also remember it being so dreadful it hurt

RISC OS 2 (and even RISC OS 6) can run most Arthur GUI apps still, but only single-tasking. druck's right; to take advantage of any PMT, everything would need rewriting, just like everything did to take advantage of CMT in RISC OS 2.

rjek on 23/5/09 8:26PM
[ Reply | Permalink | Report ]

I don't think I had mentioned PMT (Personally I prefer the idea of CMT, but that's me opinion).

I am pretty sure this community is split into:

Those that do Those that wish Those that moan about the other two.

As for the "Aren't being maintained now?" bit, isn't that a pointer to something? no S/W = no platform?

I use Impression, Eureka (for table support in impression), DigitalCD, ProCad, Paint, and my own half-arsed music library / player system based on DigitalCd's Libraries, RDPClient.

oh and Netsurf.

How much Win 3.1 / 95 stuff still works under 7?

em2ac on 24/5/09 9:07AM
[ Reply | Permalink | Report ]

"How much Win 3.1 / 95 stuff still works under 7?"

Many Windows 2 apps still work under Vista, so I wouldn't be surprised if many ancient stuff still works under Windows 7; one of the reasons for Windows's hideous size is its backwards compatibility. They'd never sell it into businesses if it didn't have the ability to run old crusty software.

rjek on 24/5/09 12:13PM
[ Reply | Permalink | Report ]

"one of the reasons for Windows's hideous size is its backwards compatibility".

HMmm... not really. I wouldn't consider it "hideous size" these days. Considerably smaller than a RedHat5 install for example. Moreover, you can get a useable/useful Xp system in just a few megabytes... the reason it's "so big" is that it supports so much hardware out of the box, with pretty graphical UIs for everything, sound schemes, backgrounds and soforth. But who really gives a DAMN about how big an OS is these days? What's there to care about with OS size?

It's possibly more telling that RISC OS only runs an absolutely /TINY/ amount of hardware out of the box. Where's the stock USB stack, Wifi stack, Bluetooth, Firewire, DVD, smartcard, soundcard, etcetc that all other current OS's support out of the box? Sure, RISC OS tradition was to supply some low level drivers via card ROMs, but that's vaguely stupid and has bitten things badly in the 32bit world for example. It was an interesting idea for 15 years ago, but not so smart now.

"everything would need rewriting, just like everything did to take advantage of CMT in RISC OS 2" -- well, again I'd disagree - even Arthur had a Wimp_Poll and fundamentally the same WIMP structure. I reckon the biggest change may really have been around the interaction with other apps and filer in particular. And don't even begin to talk about why the hell a 21st century OS still has its fundamental operations supplied by prehistoric crap like OSByte...

imj on 24/5/09 4:54PM
[ Reply | Permalink | Report ]

Ubuntu's install is comparable to the size of a Windows XP install. Except it comes with a whole office suite, and a load of other apps.

As for the driver situation under RISC OS; yes. It's a complete mess.

For rewriting, loads of Arthur stuff needed a hell of a lot of reworking in their GUI code to be made RISC OS 2 apps. I'm just saying that a similar amount, if not more, would be needed again to move them onto a PMT system.

rjek on 24/5/09 6:51PM
[ Reply | Permalink | Report ]

Some questions for the experts.

Why not just run the old apps in an emulator box so that each CMT app thinks that it's the only application running on its own, with its own copy of RISC OS? This might mean that each application has an additional 4meg overhead or so. The real work would be making it seamless but it should be possible with an OS like RO and some patches to the window manager. I never understand this obsession with maintaining full binary and source compatibility with old hardware and OS. For example, Amiga OS has stuck to this and it's now pretty much an unsellable proposition due to the lack of memory protection. All to run ancient software that can be emulated at a faster speed than the original hardware anyway. Would RISC OS devs mind if there were a few new calls added to the system in order to run as a full pre-emtive app? Maybe someone who has done more WIMP programming than me (I was mainly a asm game and demos kind of guy) could tell us how big the changes would have to be.

Secondly, couldn't someone make an RM for handling the second core as a co processor? All programmers need is an interface instruct the second core to run a piece of code at a certain address and deposit the result at another address. That seems like a far more realistic goal than reinventing RO as a truly multi-core operating system.

killermike on 25/5/09 3:06AM
[ Reply | Permalink | Report ]

Giving each process its own copy of RISC OS; I've suggested this before. It's likely to work, but it has its own problems. (Working out shared memory, module sharing, etc etct)

Using a module to provide access to additional CPUs: This has already been done with the Simtec Hydra and the threading module it came with. Nobody seemed interested.

rjek on 25/5/09 9:50AM
[ Reply | Permalink | Report ]

Yes I found that odd, as it seemed like an entirely fantastic opportunity to kick start multi-threading under RO.

em2ac on 25/5/09 10:29AM
[ Reply | Permalink | Report ]

Remember any RISC OS application is utterly useless running on it's own. Every application needs to communicate with at least the filer in order to load and save files, and other applications to allow the drag and drop transfers which we find so useful.

Problems come if you have to communicate between these separate RISC OS shells, whether they are CMT to CMT or CMT to PMT, to uphold the rules existing applications expect two or more shells will have to stall, and the system will at best appear to work as it does now, at worst be an awful unpredictable mess like Windows 9X.

There really aren't any shortcuts here, either you do things properly (which is now beyond our resources), or you'll just make the user experience worse.

druck on 25/5/09 12:24PM
[ Reply | Permalink | Report ]

Druck, I re-sent that email to the one you specified. Have you recieved?

Monty on 25/5/09 5:19PM
[ Reply | Permalink | Report ]

"There really aren't any shortcuts here, either you do things properly (which is now beyond our resources), or you'll just make the user experience worse."

It doesn't have to be that bad.

Keep some things cooperative (opening/moving windows, RO-style inter-process messaging, user input), but allow multiple processes to draw their windows simultaneously and use other IPC mechanisms for things like sound. In that way, you can have your video playing uninterrupted on one window while another task is rendering a draw image.

When you move a window, window updates pause temporarily, but you're concentrating on moving the window (and the sound from the movie should continue uninterrupted).

Stoppers on 25/5/09 10:32PM
[ Reply | Permalink | Report ]

"Keep some things cooperative (opening/moving windows, RO-style inter-process messaging, user input), but allow multiple processes to draw their windows simultaneously and use other IPC mechanisms for things like sound. In that way, you can have your video playing uninterrupted on one window while another task is rendering a draw image."

How do you plan to do this, without introducing a new Poll call?

rjek on 25/5/09 11:45PM
[ Reply | Permalink | Report ]

"How do you plan to do this, without introducing a new Poll call?"

I plan to add a new poll call. :-)

But only for new applications; old RO apps get to see the same behaviour as before.

Actually on umpteenth thought, even that may not be necessary.

How about a Poll response code (for modern applications, and only when requested) that indicates that the application's request has been queued, but the Wimp is busy. The application may then do some non-Wimp work (decoding video or audio, for example) before trying again. As long as it doesn't wait too long between tries and doesn't hog the processor in the mean time, it should provide a good, RO-like, user experience.

Stoppers on 26/5/09 11:22AM
[ Reply | Permalink | Report ]

What about going for the OS X/Classic method?

Make a new API, and put ALL the new stuff in a wrapper process that's running the old OS.

bhtooefr on 31/5/09 6:01AM
[ Reply | Permalink | Report ]

I wondered why you were all hankering after a pre-emptive OS. Killermike is right; his suggestion is an actually an old Unix idea called “forking”. Obviously, since the A9 is symmetrical (all cores can access the memory) you don’t need to replicate the whole 4MB of the OS, just a unique data area. You also need to split of the API from the OS. Clearly, access to hardware and task management must be centrally arbitrated, let’s say by the Central Control Program (remember Tron?) which resides always on the same core. The key to porting RISC OS to a multiprocessor system then lies in the SWI decode routine. When a task calls its instance of the SWI decode routine, that routine must determine whether it can handle the call or whether it must pass the request on to the CCP. Provided the application behaves well, it does not need to be aware that it is operating on a multiprocessor system.

So, to put flesh on the bones of killermike’s suggestion; A CCP, responsible for allocating hardware, and co-ordinating tasks, is permanently allocated to the first core. When a new task is requested, its API is set up in memory along with the task, and the pair are allocated to a core. Once the task is initialised it returns via Wimp_Poll. It’s API saves the processor state and relinquishes control of the processor core. When Wimp_Poll returns, the CCP allocates a core to the API and task, and starts the API from where it left off.

You don’t need PMT to take advantage of a multiprocessor system, CMT lends itself well to multiprocessing and PMT is inefficient on a single user system. For those who don’t know, the original purpose of PMT was to allow multiple users simultaneous access to a single processor. Windows XP and vista are evolutions of Windows NT, a multiuser competitor to Unix. Multithreading was originally part of the PMT solution. Back in the days of yore (early 80s) I used to manage a Perkin Elmer computer with 8 register sets (of 32 registers). You can imagine the overhead of providing simultaneous access to 5 graphical terminals on a 25MHz system using one register set. So the Perkin Elmer used block multithreading, which is not the same as the simultaneous multithreading you get on the Intel Atom. The Cortex A9 is not multithreaded, and I don’t believe its successor will be either. Instead, it uses something called speculative out of order execution. I am not sure how well it will deal with old calculator stacks.

To take full advantage of the multiprocessor system (one task split over two processors) the task needs to be multithreaded. If Simtec wrote a module to do that, best drag it out and dust it off. Alternatively, you could implement a very coarse multithreading strategy by splitting background activities (Printing, saving files, etc) to a separate task. Without multithreading, the system won’t slow down so much when you add more tasks. With multithreading, a program can speed up as cores become available.

BTW. I'm new to this thread. I stopped using RISC OS 5 years ago (it was a tough call) but I would pay a reasonable fee to be able use !Organiser on a netbook.

Viking on 25/5/09 7:05PM
[ Reply | Permalink | Report ]

"PMT is inefficient on a single user system"

Buh. What an old-fashioned attitude.

rjek on 25/5/09 8:29PM
[ Reply | Permalink | Report ]

Buh. What an old-fashioned attitude.

True. On a 1GHz system, the overhead for PMT is not significant. But RO already has facilities for PMT, just not at the WIMP task level. What is the point in rewriting the API, risking additional incompatibility? The way in which the OS deals with requests from tasks is a different matter.

Viking on 26/5/09 6:58AM
[ Reply | Permalink | Report ]

My buh was for suggesting it was inefficient in single-user systems. Personally, I like the fact I can still web browse without lumpy interruptions while a CD burns or rips, or when my mail client checks for new mail or usenet posts, or when I'm encoding my recent holiday videos, rasterising a printout in the background, updating the search database in the background, etc etc etc.

I'll think you'll notice that 1GHz ARM-compatible systems are already available, and more are on the horizon. Additionally, Linux on ARM systems, even ones such as the A9 Home, have much greater throughput than RISC OS does; precisely because of its PMT and better memory management.

There's no point porting the OS and rewriting the API at all, you're right. The amount of old software that would break in the name of progress will massively outweigh the new software that might be written, and most people would stick with their ancient crumbling RiscPCs anyway.

(Which is precisely the situation that let me to use other systems for my day-to-day computing.)

rjek on 26/5/09 9:47AM
[ Reply | Permalink | Report ]

Sadly too true!

em2ac on 26/5/09 10:37AM
[ Reply | Permalink | Report ]

...Personally, I like the fact I can still web browse without lumpy interruptions while a CD burns or rips, or when my mail client checks for new mail or usenet posts, or when I'm encoding my recent holiday videos, rasterising a printout in the background, updating the search database in the background, etc etc etc

Fair enough! I see what you're driving at now. I should mention that I'm using Windows XP and I do get lumpy interruptions while CD (or at least a DVD) burns, but I agree you can force the kind of responsiveness you describe using PMT. It shouldn't be necessary, though.

I didn't say there was no point in porting the OS, I just don't see rewriting the API for PMT as useful if the problem lies in scheduling within the OS or poorly written applications. For instance, I’ve never understood why so many RO applications hang the system when they rasterise a printout. My (very old) PRMs actually recommend calling Wimp-Poll throughout the print process, so either applications are ignoring the PRMs advice, or the Print manager is asking for the whole lot in one go.

I’m afraid I’ve not used a modern ARM compatible system, but I can see how recompiling code to take advantage of the target hardware, coupled with better memory management, would increase throughput. But I expect PMT to increase the number of context switches and that can only slow the system down. We may be talking at cross purposes. PMT is usually associated with block multi-threading, and that could certainly reduce bottlenecks.

Viking on 26/5/09 7:41PM
[ Reply | Permalink | Report ]

"But I expect PMT to increase the number of context switches and that can only slow the system down. We may be talking at cross purposes. PMT is usually associated with block multi-threading, and that could certainly reduce bottlenecks."

Yes, but unless a task is using 100% of the CPU, it won't get process-switched unless it yeilds. And you want to force it to in that situation anyway, for precisely the reasons you describe. So there really aren't that many unwanted context switches.

rjek on 26/5/09 7:47PM
[ Reply | Permalink | Report ]

Yes, but unless a task is using 100% of the CPU...

I think we may be using the same words for different things. An example of "block multithreading" would be if Wimp_Init required a table of addresses to jump to for individual events. This would mean the Wimp would not need to encode the event and the task would not need to decode it, thuse removing one bottleneck.

The ARM does not contain multithreading hardware, so any task running on an ARM CPU core has access to 100% of that core (less SVC, FIQ and IRQ).

When you say, "for precisely the reasons you describe", do you mean to overcome poor porgramming practices?

Viking on 26/5/09 9:34PM
[ Reply | Permalink | Report ]

I've not heard the term "block multithreading" before. Under UNIX and similar systems, you only really have one extra entry point (the signal handler); everything is done via system calls blocking and letting another process run until the process can be unblocked (data loaded from disc, data arriving on a socket, a file changing, etc). There's no reason the API for RISC OS couldn't be adapted to do the same; it's just loads of software won't work because they expect to be the only thing running between Wimp_Poll calls. Now, extending the Wimp_Poll API is one solution, but old software will still have to block the entire system; and given most software is old, and the likelyhood of new software being written is astonishingly tiny, there's little point.

As for the ARM not containing multithreading hardware; it doesn't contain anything like Hyperthreading. But it has everything that any other OS can use quite effectively; a high-resolution timer, an atomic swap instruction (which was introduced for the multithreading explicitly), different modes for kernel and user land, and virtual memory. You don't need anything more.

rjek on 26/5/09 11:42PM
[ Reply | Permalink | Report ]

Bear with me on this. I think you're saying there is no point in rewriting the OS for PMT because there old software will break and there is no new software, and with such a small dwindling userbase, there is no margin in writing new software.

The only way around that is to increase the user base, for example by porting it to new, cheap, hardware. If that works, it might be worthwhile writing new software and if it is properly written, it will work on either PMT or CMT.

With regard to the ARM and multithreading, again we are using the same terms for different things. The ARM does not contaibn visible copies of the user register set and this would be required for hardware multi-threading. I hadn't really thought about the SWAP instruction, but it might tip my view in favour of PMT.

Viking on 27/5/09 5:57AM
[ Reply | Permalink | Report ]

"The only way around that is to increase the user base, for example by porting it to new, cheap, hardware."

And why would people want to move to an OS with no Javascript, Flash and Java-enabled browser worth using, with no video media playing, and a host of other things?

As for what would be required for hardware multithreading, a whole bunch of hardware would be required. So what? I don't see why you keep going on about that.

rjek on 27/5/09 6:52AM
[ Reply | Permalink | Report ]

You could turn that round and ask why people would wish to continue using a system with a poor GUI, when they could easily use RDP to access all the missing applications. (Ok you have to put up with the poor GUI on those apps, but at least you get a decent GUI the other apps you use.)

jess on 27/5/09 8:43AM
[ Reply | Permalink | Report ]

Why have two computers, when you can get along quite happily with one? Personally, I much prefer the UNIX UI to the RISC OS one; but I'm not just limiting myself the the GUI.

rjek on 27/5/09 10:21AM
[ Reply | Permalink | Report ]

And why would people want to move to an OS with no Javascript, Flash and Java-enabled browser worth using, with no video media playing, and a host of other things?

In a word: choice. Which is the original point of Linux, I believe. I couldn't comment on the functionality of any RO browser, but Google seems to disagree with you, BTW.

If I appear to keep going on about hardware multi-threading, it is only to establish what we are discussing. I have no interest in hardware multithreading, except to determine whether it is likely to appear on ARM in the near future (I think not).

But structuring code in a way that allows many separate routines (threads) to run independently (which I have called multi-threading) is the way to take full advantage of multiple processors. In my original post, I have suggested several ways this could be achieved.

Viking on 27/5/09 9:21AM
[ Reply | Permalink | Report ]

Linux's existance is because somebody had a personal itch, and it's grown to be something that is specifically free and well-engineered. It's difficult to compete with that on technological grounds.

I'm not sure what you mean by Google disagreeing with me; we have Java 1 system that is so ancient nothing works with it, an equally ancient Shockwave player, and an unusuably slow Gnash port, which doesn't support most Flash applets anyway.

As for how things could be achieved, the simple way of implementing threads which everybody else already uses and has been tried and tested seems to be the best choice; although it'd be a waste of effort anyway, regardless of how it's done.

MIPS has "hyperthreading", after a fashion. If it actually becomes a feature customers want, ARM may add it. But you can usually just throw another ARM code in the same package for a similar cost in complexity.

rjek on 27/5/09 10:24AM
[ Reply | Permalink | Report ]

I agree with you about the technical quality of Linux and its price

The Linux community has fought off Microsoft in the past specifically to protect the freedom of computer users.

As I said, I cannot comment on the functionality of any RO browser, but Netsurf is a browser that is developed on RO and ported to other OS, such as Linux. Google have asked the authors to provide mentorship during their "summer of code".

I think in the case of RO, the best choice for doing anything is the one that takes least effort at the moment. In your view, that would at least minimise the waste of effort. I don't really care whether it's a waste of effort or not. Personally, I would like to see how RO performs on new hardware and if somebody wants to spend time doing that, I'm happy for them to do so. I'm even happy to pay a few quid if it works out.

I have to agree that multicore processing provides better value than multi-threading, and I can't really argue with the idea of ARM submitting to customer demands. But I think ARM will have already considered hyperthreading, and have decided against it because they get a better return from speculative out of order execution (It's to do with condition codes).

Viking on 27/5/09 12:37PM
[ Reply | Permalink | Report ]

"As I said, I cannot comment on the functionality of any RO browser, but Netsurf is a browser that is developed on RO and ported to other OS, such as Linux. Google have asked the authors to provide mentorship during their "summer of code"."

I can comment; I'm one of the mentors

rjek on 27/5/09 12:57PM
[ Reply | Permalink | Report ]

Way to go!

Viking on 27/5/09 1:11PM
[ Reply | Permalink | Report ]

Viking; Your understanding of processors is stuck back in the mainfraim era, it doesn't mater in the slightest whether threads can be run simultaneously on one core or multiple cores, it's about whether the OS is capable of utilising them, and RISC OS isn't.

RISC OS has it's roots back in Arthur which in turn was a warmed up version of the BBC B's MOS, basically a single program running at any one time, and a single state for all interaction with the OS. The only change was allow programs to yield to others on request at certain points - the Wimp_Poll and co-operative multi-tasking.

The crucial thing to take any advantage of multi threads/cores is to give each application it's own OS context so the OS can simultaneously deal with more than one application, no matter what it is doing. This also allows both pre-emptive multi-tasking and multi-processing across cores. With say a 90% rewrite of the OS and all application modules, this could be achieved.

However RISC OS is further hampered by the fundamental assumption that things like WIMP messages happen in a certain order, and any other events being received will stop most applications from handling the messages properly. You have a choice of either maintaining a compatibility behaviour and still having everything freeze if one task isn't responding, or accept a lot of things will no longer work.

As for your Wimp_Poll idea, I assume you are suggesting that the handler for each type of event be run in a separate thread, which has little or no advantage, and would be guaranteed to break everything.

druck on 28/5/09 1:45PM
[ Reply | Permalink | Report ]

A thread can only be run on one core at one time. For an application to run on more than one core simultaneously, it must be multi threaded.

Killermike has suggested giving each application its own OS context, and I have pointed out that this is a technique used in Unix systems (back in the mainframe era). It would require some rewriting of the OS and extension modules, but would it really need to be so extensive?

Rjek has rightly pointed out that a switch statement with a long list of case statements is less efficient than a jump table for handling the Wimp_Poll reason codes, but I have already agreed that any saving would be insignificant in itself.

The Wimp_Poll idea was to allow applications to respond to more than one event at a time, in a multiprocessor system. Wimp_Poll itself would become redundant because the OS would never return from it. Instead, it would call the event handlers in the jump table. I realise that you'd lose compatibility, but I don't think it would require an extensive rewrite of application code because the only effect is to change the way you get to an event handler. The advantage, in a multiprocessor system would be that an application could carry out background tasks, (responding to Null events) while simultaneously doing, say, a window redraw and, say, a task to task data transfer. Of course, if you go down that route, you might as well make it possible to register unique instances of handlers for different objects.

Having said all that, I have also suggested that you could take advantage of multi-cores by starting a new task to handle background activities (such a rasterising a print, or saving a file to memory) and that Simtec's Hydra software should be re-examined. My intention is only to offer suggestions for porting RO to new hardware with limited redesign resources, and if my understanding of processors is stuck back in the main frame era, then modern processors should be more than capable of handling those suggestions.

Viking on 28/5/09 10:13PM
[ Reply | Permalink | Report ]

"A thread can only be run on one core at one time. For an application to run on more than one core simultaneously, it must be multi threaded."

"Killermike has suggested giving each application its own OS context, and I have pointed out that this is a technique used in Unix systems (back in the mainframe era). It would require some rewriting of the OS and extension modules, but would it really need to be so extensive?"

Hugely extensive. I tried to make a list of contexts in RISC OS that would need to be replicated, but gave up when I reached 20.

Untrue; it may be multiprocess, or the compiler may do magic to make safe parts execute on different hyperthreads or cores.

"Rjek has rightly pointed out that a switch statement with a long list of case statements is less efficient than a jump table for handling the Wimp_Poll reason codes, but I have already agreed that any saving would be insignificant in itself."

No, myself and imj both said that a switch statement gets /compiled/ to a jump table anyway. (In ARM code, a jump table is a single instruction followed by a list of branch instructions).

"The Wimp_Poll idea was to allow applications to respond to more than one event at a time, in a multiprocessor system"

Other systems simply have a job dispatch thread; it would listen to Wimp_Poll, and dispatch jobs to handler threads. This is both simple, and good enough.

rjek on 29/5/09 12:12AM
[ Reply | Permalink | Report ]

rejk: "Other systems simply have a job dispatch thread; it would listen to Wimp_Poll, and dispatch jobs to handler threads. This is both simple, and good enough. "

Lovely! I assume you're talking about modifying the Wimp_Poll loop so that it schedules jobs with the kernel (rather than execute the event handler code directly), using semiphores to avoid races and deadlocks. In fact, in an object oriented environment, it seems a more elegant solution.

Viking on 29/5/09 7:53AM
[ Reply | Permalink | Report ]

No. You have multiple threads in your application. One of those threads is responsible for calling Wimp_Poll. It then wakes up or spawns new threads to deal with the new events. The kernel has nothing to do with it.

rjek on 29/5/09 9:35AM
[ Reply | Permalink | Report ]

Viking, you can't take applications and deliver events to them simultaneously in different threads unless the application is specifically written with this in mind. Some events will change data (e.g. key presses in an editor), others will read data (e.g. redrawing text), and unless threads are synchronised with semaphores or mutexs to prevent reading when the data is in mid update and inconsistent, the application will fall over.

As for Hydra, adding it to a Risc PC would have done precisely nothing. To take any advantage of it, applications would have to be extensively re-written, and with the RISC OS still being CMT, getting any benefit out of the additional cores is vastly more difficult than on any other platform. That's why when the StrongARM came out, offering faster single core operation, it was dropped like a hot brick.

druck on 29/5/09 10:49AM
[ Reply | Permalink | Report ]

I keep getting the feeling that we take different meanings from the same terms. In order to clarify the situation, can I point to the Wikipedia entries for multithreading and forking?

RO is presently a N:1 multi-threaded system, that is all thread are mapped onto a sinlge processor, and the application itself schedules those threads. In most cases, it does so in response to reasoncodes retruned by Wimp_Poll.

My Wimp_Poll suggestion is an attempt to change to a 1:1 multithreading system, where all thread scheduling is carried out by the kernel. I suppose it would be more correct to consider such a system pre-pemtive, and to finish the picture, I wonder if the pre-filter mechanism could be used (by the kernel) to prevent blocking. Simtec's Hydra was introduced before prefiltering, I think.

Killermike's suggestion is called "forking" in which the OS creates a new instance of itself and starts a process (application) within that instance, thus giving each application its own OS context. Clearly, since all applications need to share hardware resources, the child processes would not be a copy of the OS, just the API. The rest of t he OS would need to be rwritten to allow more than one context.

Viking on 28/5/09 11:38PM
[ Reply | Permalink | Report ]

"RO is presently a N:1 multi-threaded system, that is all thread are mapped onto a sinlge processor, and the application itself schedules those threads. In most cases, it does so in response to reasoncodes retruned by Wimp_Poll."

Well, there are no threads at all.

"I wonder if the pre-filter mechanism could be used (by the kernel) to prevent blocking. Simtec's Hydra was introduced before prefiltering, I think."

Possibly, but the work is best done centrally. Hydra only worked in RiscPCs, which meant they must have been running RISC OS 3.5 at minimum. Filters were introduced in 3.1 IIRC (and are noticeably absent from 3.0)

"Killermike's suggestion is called "forking" in which the OS creates a new instance of itself and starts a process (application) within that instance, thus giving each application its own OS context."

Forking almost always refers to a process, not the OS. ie, the call fork() makes a copy of the process (copy on write in all modern operating systems), and returns one value to on process, and the PID of the newly spawned process to the other.

rjek on 29/5/09 12:15AM
[ Reply | Permalink | Report ]

The definitions you are using are not the same as mine, that's why I've suggested taking a look at the Wikipedia entries.

Every process has at least one thread by definition, and a thread owns its copy of the register set (so must run on one core).

In Unix, the Shell (command line interface), for example, forks. I have suggested that the API could be split off from the OS, and this could fork. Of the 20+ contexts that you counted, how many could be naturally replicated by a fork?

Compiling a switch statement to a jump table is an optimisation. Copy on Write is one way in which forks are implemented. The child process shares the same physical memory as the parent until either parent or child writes to it, at which point it is copied.

Viking on 29/5/09 6:09AM
[ Reply | Permalink | Report ]

I'm beginning to boggle at you. fork() requires advanced memory management and multitasking abilities. RISC OS doesn't have these. Adding them would be as much work as reworking the dozens of places RISC OS keeps state.

I can't think of a compiler anybody actually uses on ARM that doesn't compile switch statements to jump tables where possible.

I can't think of an OS anybody actually uses that has fork that doesn't do it copy-on-write. (And then you go and tell me what copy-on-write is. Boggle.)

rjek on 29/5/09 9:34AM
[ Reply | Permalink | Report ]

Viking, how can you split the API from the OS? The API is just the entry point, the OS contains the code and the context. You can't just have multiple copies of the same code running in different threads, what is needed is change the code to allow multiple contexts.

Take a simple one such as directory enumeration. Currently the OS only has one context, so an application must call a SWI to get the first file, then make a number of additional calls to get the rest of the files. It cannot allow another task to run during this operation, as if that also talks to the OS, it will destroy the context, and the enumeration will subsequently fail.

Now you can't just run two copies of the entire OS to get round this, firstly because there is only one set of disc hardware, and even if you got round that with virtual machines, you then have not only two separate contexts for the enumeration, but also the disc contents. i.e. the contents of the disc could appear different to each application.

The filing system code needs to be re-written to allow use of the API by separate threads, providing a context for each of them, but maintaining a single consistent state for the filing system (synchronsisng reads and writes by each thread), and driving the disc hardware.

This can only be done by re-writing the OS to be thread aware. There are no short cuts that can be taken, "fork everything" just wont work.

druck on 29/5/09 11:07AM
[ Reply | Permalink | Report ]

Rejk, I apologise for making you boggle. I am looking at this from a “computer science” point of view and I think you are looking at it from a C/C++ programming point of view. I wasn’t trying to teach you to suck eggs, I was pointing out that “fork” and “copy on write” are not synonymous. RISC OS does not need to do copy on write in order to fork, it just means that the memory will always be allocated, even if the child does nothing. I think you are looking at fork() as a C function, I am suggesting the CONCEPT can be applied to other problems. Similarly, I think you are looking at threads in terms of C/C++ library functions, so their implementation is invisible to you as a programmer. But for two threads to run on two processor cores, the kernel needs to be have allocated the cores to those threads.

Druck, I would have to dig out my old PRMs from the loft to answer your questions properly, but I’ll try to explain what I have in mind for now. There are two different concepts here. The first, forking, is a suggestion for a methodology to allow the OS to run existing application simultaneously by allocating separate applications to separate cores. The second, “Wimp_Poll idea” is a suggestion for 1:1 multithreading of an application.

With regard to the question, “how can you split the API from the OS?” Would it make any difference if I used the term “API layer”, meaning a layer of software which began at the API and reached to various extents within the OS? Depending on the modularity of the OS, this could simply mean putting one module in the API layer, and another outside. It might be possible to implement some features using pre and post filtering, and some features will have to be completely rewritten.

So, for example, if we were able to intercept the calls to enumerate a directory, and store the context within the API layer, we can work around the problem. If an SWI causes only the core it was issued on to switch context (and I think that must be so), then we can intercept any call we choose within the API layer.

As for the Wimp_Poll idea, getting one task to run on multiple cores would require some rewriting of applications. Given that much of the available software is no longer maintained by original authors, I think it might be worthwhile concentrating on a single, well understood, part of the application; the Wimp_Poll loop, and its associated data. In 1:1 multithreading, the OS is aware of all a task’s threads and schedules them directly. I can see that allowing two threads to simultaneously access the same object (a window, for example) could cause problems, but there are ways around that. You have already mentioned semaphores and mutexes. Semaphores could be implemented as global task data. Mutexes are a little more complicated, but perhaps event handlers which were related to a single object (eg codes 1-6 etc) could call some sort of locking routine before dropping into the existing code.

I’m not going to claim that either of these suggestions is the best way forward; It may be necessary to intercept every call to the OS in order to have a forked API layer (too costly). But if there is a shortage of resources to rewrite all the applications and all of the OS, I think any methodology would be worth considering.

Viking on 29/5/09 4:30PM
[ Reply | Permalink | Report ]

"if Wimp_Init required a table of addresses to jump to for individual events."

Which is close enough to what it does do. List the messages it wants to receive in the init call and mask reasons in the poll call. The actual business of how it hops to the handler is insignificant.

imj on 28/5/09 4:40AM
[ Reply | Permalink | Report ]

At present, Wimp_Poll returns a reason code (event) and the task chooses the subroutine thread) that handles it.

The suggestion was that the task of choosing the routine could be handled by the WIMP. The WIMP then does not have to encode the event as a reason code, and the task does not have to decode it. Typically, decoding would be carried out in C/C++ by a case{} statement with 27+ comparisons. The case statement would then call a subroutine, with the overhead of (at least) 1 APCS call. While this bottleneck may be insignificant in itself, removing bottlenecks throughout code is the approach favoured by Steve Jobs (Apple) to improve responsiveness.

In fact, the suggestion impinges on another area of the disucssion. In a multiprocessor system (the Cortex A9 can have 4 cores, but it won't stop there), A single application can only take advantage of more than one core if the OS sees it as more than one entity (thread).

Viking on 28/5/09 6:59AM
[ Reply | Permalink | Report ]

Suggesting changing the poll interface to remove one jump of overhead (given I'd have thought that most of these Wimp_Poll event code dispatch routines get compiled to a jump table) seems, to me, entirely insane.

All you're doing is moving where the jump table is; not eliminating it.

rjek on 28/5/09 9:50AM
[ Reply | Permalink | Report ]

If you think that a C 'case' statement handling a WIMP reason is encoded as a string of comparisons, you're way off. Why exactly do you think this is a "bottleneck" anyway? Did you deliberately pick one of the MOST EFFICIENT dispatchers as your target for pointlessly changing?

imj on 28/5/09 1:15PM
[ Reply | Permalink | Report ]

My copy of the PRMs says it's highly problematic to multi-task during printing. PRM 3-561

Multitasking is incompatible with the queueing mechanism used by the Printers application. If you call Wimp_Poll whilst printing, the printers application will assume that you have finished; if there is another job in the queue it will continue with that, which will obviously cause an immediate error. Future versions of RISC OS may address this problem.

It is difficult to arrange your printing such that you call Wimp_Poll sufficiently often to confer a useful degree of multitasking on the rest of the system, since you cannot predict for all classes of printer the size and complexity of rectangles that you will be asked to print. To do so properly, you need to use a timer.

You must select the previous print job before polling the Wimp, and reselect your own job on return.

In practice these problems are likely to outweigh any advantages conferred by multitasking. If you have any doubts as to whether or not you should multitask, WE RECOMMEND THAT YOU DON'T [my caps]

So where in the PRMs did you read the recommendation to poll?

IvanDobski on 31/5/09 12:59PM
[ Reply | Permalink | Report ]

Just to clarify, I meant the ARM Cortex A9 processor, nothing to do with the A9 Home.

Viking on 26/5/09 7:51PM
[ Reply | Permalink | Report ]

I know for a fact that Avid Liquid 7 needs to be 'bodged' to work under Vista , and fails completely under home.

and I have heard of nearly a hundred others which worked under XP (alot failed under that too), but fail under Vista, it is only the real mainstream products that patched the software early to take advantage of vista.

Any MS VB6 made software struggles to install under Vista (I have a set of instructions on how to munge it to work), as the installer fails to install an older dll and even then has been known to blue screen Vista.

All I was saying was, yes we are luck to have this old stock of code, lets start developing for the newer OS's / future OS's and forget about RO3, as an example.

em2ac on 25/5/09 10:36AM
[ Reply | Permalink | Report ]

Software that makes broken assumptions is broken anywhere

Often, installing as Administrator solves many; but I've had a handful of 16 bit Windows software working a treat under Vista Business.

rjek on 25/5/09 3:00PM
[ Reply | Permalink | Report ]

Did someone not make available WIMP2 or somthing like that which swapped from being co-operative multitasking to preemptive.

For starters would it not be an idea to investigate if this could be implemented into RISC OS 5? I am sure pre-emptive multitasking would be a good start.

Would pre-emptive multitasking also not make it possible to develop further and dole out diffrent tasks to diffrent cores? (ok so not multi-thread but at least it would be able to carry out more than one thing at the same time).

Just wondered as not sure if that is workable but as RISC OS 5 is open source and development seems to be going forward what are peoples thoughts? Is pre-emptive a good idea?

John

mrmac on 21/5/09 1:05PM
[ Reply | Permalink | Report ]

WIMP2 worked by forcing processes to call Wimp_Poll, and then collecting events for them, and passing them to them one by one. It caused many problems, and didn't solve any relating to having multiple CPUs; only one program was running at a time, so it didn't matter.

The problem is that so many parts of RISC OS only have one "state"; everything from which directory you're in to how you're printing. Normally, this isn't a problem because the author of the software is careful about when he returns control to the OS for another application to get its turn. However, with PMT and SMP, there's no way to know when it is safe to swap task. What needs to be done is for every task to get its own state; including current directory and perhaps 50 other things.

rjek on 21/5/09 1:16PM
[ Reply | Permalink | Report ]

I don't think PMT vs. CMT is particularly related to the issue of multiprocessor support. I don't see why it wouldn't be possible (though lots of hard work) to have one WIMP operating on each core, 'scheduling' tasks to run on that core, with only the two WIMPs communicating with each other, to cope with redraw and drag+drop events, and other messages.

You'd still have the problem of all the modules not being mp safe, let alone the bottleneck that RISC OS's blocking filecore would become. But you'd have all those problems under multicore PMT anyway.

How is state handled by the wimp anyway? The few wimp apps I've written have never made any assumptions about the csd, so I'm not sure how that's handled. Does the wimp restore csd on returning from the wimp_poll? If that's the case, then you could still shift processes between cores each time they poll, provided you make their state data available to the other core.

ninja on 21/5/09 5:17PM
[ Reply | Permalink | Report ]

Your suggestion doesn't solve all the other state issues; WIMP messaging is just one. RISC OS is not designed to have more than one thing talking to the OS at once; too much of the API is implicitly stateful. If FileCore were adapted so it could yield rather than block, then when one process blocks on disc, others can use the CPU. This gives you a big performance increase over CMT, multi-processor or not.

The CSD is a global, shared among all processes. Much like environment variables, the sprite context, the VDU pipeline, and dozens of other things.

rjek on 21/5/09 7:12PM
[ Reply | Permalink | Report ]

"The CSD is a global, shared among all processes. Much like environment variables, the sprite context, the VDU pipeline, and dozens of other things."

This is true, and the reason most programs don't rely on them except, possibly, to assume that they won't change between calls to Poll. If each program had it's own CSD, sprite context, etc. they wouldn't see a difference. Environment variables are another case; they should be shared but it probably wouldn't break anything to allow changes between Poll calls, but if that turned out to be the case, the shared environment could be copied on each Poll.

A lot can be achieved by allowing programs that are aware of the multi-processing capability of the OS to carry on working while waiting for a poll response, while avoiding doing anything that would affect other, more traditional programs.

ROLF allows processes to detatch from the Wimp polling process and be signalled when an event that it should take care of has occurred, and also to keep working while waiting for the Wimp to re-introduce the process into the traditional CMT environment.

Stoppers on 21/5/09 9:40PM
[ Reply | Permalink | Report ]

I don't doubt that making all these shared contexts swapped in and out along with the rest of what the WIMP does will improve maters; but it's a hell of a lot of work, and in some cases requires API redesigns, meaning existing apps can't make use of the new functionality. Additionally, I bet there are a fair few apps out there that /rely/ on the shared contexts.

rjek on 21/5/09 11:53PM
[ Reply | Permalink | Report ]

Yes, you're right - it's not just all the modules that would have to be rewritten to cope with, well, simultaneous reentrancy, I suppose you could term it - but the whole of the operating system.

Still, I guess in one way it's lucky that RISC OS is one of the few remaining microcomputer OSes at heart, in that (interrupts aside) it doesn't do *anything* unless some code calls an OS function. It's about as deterministic as you can get.

But I'm not convinced application state is an issue. If the wimp doesn't preserve state, it means no application can rely on state, so, for example, no app will use the CSD.

But anyway, I was just pointing out that the issue of CMT vs. PMT was not directly related to the issue of MP - which is a whole can of worms whatever way you look at it.

Regarding filecore blocking on I/O, if it were possible to introduce a new asynchronous API or something along those lines, it'd be a great improvement to the responsiveness of the OS, PMT or no PMT, MP or no MP.

ninja on 21/5/09 11:38PM
[ Reply | Permalink | Report ]

No, the issue is that so many developers assume (rightly, at the time) that the CSD won't change unless you call Wimp_Poll. And the same applies to dozens of other facets of RISC OS. I bet bags of applications rely on things like the CSD, sprite context, currently open Templates file, and lack of file system races. And they'll all break.

As the the file system, you don't need non-blocking APIs to make a performance improvement, you just need the ability to run a different program while another is waiting on disc.

rjek on 21/5/09 11:58PM
[ Reply | Permalink | Report ]

Ah, I see your point now. Yes, CSD (and other) consistency is an issue if the OS expects to be able to interrupt a program preemptively. If you're still running CMT but on two cores, applications still don't get interrupted like that, but you do have two applications running at once. I guess you'd need two copies of the CSD, the sprite context, and, er, interesting things like the system volume.

Regarding filecore, asynch apis would let well written applications poll while waiting for I/O. Sure, it'd be a beast to write for, but then writing for CMT has always been fundamentally harder than writing for a PMT system (assuming an underlying os that has per-process state).

Lets face it, RISC OS that supported pre-process state, PMT and SMT wouldn't really be RISC OS any more. I'm just thankful (with my RISC OS hat on) that they're still making ARM cores with outrageous clock speeds, and that the promise of multicore chips with lower clock speeds hasn't yet come to pass.

ninja on 22/5/09 2:02PM
[ Reply | Permalink | Report ]

Am I missing something or are you arguing over how difficult it will be to port riscos over to a platform that no-one has suggested it will be ported to?

If the (A8) port gets to a mature enough state, I'll probably buy one (in whatever form) just out of perversion, (that and it'll be nice to loft the RiscPC that no-one uses).

Did anyone set up a donations pool to help with porting resources in the end?

Zhadnost on 22/5/09 7:04PM
[ Reply | Permalink | Report ]

People still haven't really explained what they expect to be able to do with this marvel of computing. What's the point of an OS on a new platform if there are no apps for it?

imj on 28/5/09 1:17PM
[ Reply | Permalink | Report ]

Progress! >

rjek on 28/5/09 1:51PM
[ Reply | Permalink | Report ]

well you have to start somewhere. once the OS has been ported to new platforms hopefully interest in it will rise and new developers will come and create new apps.

kuliand on 28/5/09 2:18PM
[ Reply | Permalink | Report ]

For one, my interest has been triggered and i have a beagleboard rev C3 that now runs RiscOS :-)

Next to that i can mount USB disks and hope to get it running with a !boot structure. That would make it more usable. So thanks to all who contributed to this effort!

JanRinze on 29/5/09 10:19AM
[ Reply | Permalink | Report ]

"I wasn’t trying to teach you to suck eggs, I was pointing out that “fork” and “copy on write” are not synonymous"

Given I'd already alluded to that, I can only imagine you didn't read what I wrote; so I'll give up now. The rest of your post is also maddeningly insane and confused.

rjek on 29/5/09 4:50PM
[ Reply | Permalink | Report ]

Sorry, rjek.

How about you, Druck? Killermike’s idea is clearly technically possible, but is it just a pipedream? Is there just too much work in it? I’m not really bothered about the “Wimp_Poll” idea.

Viking on 30/5/09 5:25AM
[ Reply | Permalink | Report ]

The first part of what I suggested, a windowed VM, is pretty easy to do. You could do it with a bit of script hacking and a copy of RPCEmu. Basically, whenever the filer (any OS) runs a RISC OS executable, it uses a script to launch RPCEmu with a modified boot sequence so that some parameters specifying which program to run can be passed along to it. Obviously, as someone else pointed out, it's not much use for an OS like RO as drag and drop, but it would work.

Making it seamless is the hard part but not insurmountable. Surely, this is what Aemulator is doing? Once that was running you could abandon legacy compatibility and start integrating something like WIMP2.

The other point that I was making was that a module that allowed programmers to run a piece of code on the second core would probably quite useful. Making RO a multithreaded, multi processor OS seems like too much work. I'm sure that most users would be prefer video acceleration for example.

killermike on 30/5/09 8:06AM
[ Reply | Permalink | Report ]

Killermike, the “API Layer” I propose IS a Virtual Machine. Some people spotted a couple of technical problems with your proposal, and this is intended to overcome those problems. My proposal is a fairly simple concept: Any program making a call to the OS uses an SWI instruction. The OS contains a decoding routine which generates an address from the SWI number. Changing that decode process to intercept calls that will cause compatibility problems and deal with the incompatibility, solves the problem. As far as the application is concerned, it is running on standard RISC OS, but the software on the other side of the API layer could be anything. There are some modules, such as BASIC and CLI which would have to be thought of as part of the API layer because applications are able to interface to them without SWIs. I don’t “think” there’s that much work to my proposal, but I can’t quantify it.

Like you, I don’t think a fully “multithreaded” OS is on the cards at this point, so the idea is to find a way to run two or more apps on additional cores. The software that sits under the API Layer can’t be RISC OS as we know it because it must include some multithreading just to schedule two or more cores.

I think you’re right about taking advantage of new graphics hardware, but if TI, Qualcomm and Freescale are all including graphics hardware on the chip, which one do you support?

Viking on 30/5/09 2:35PM
[ Reply | Permalink | Report ]

Viking, in practice you'd find your layer was larger and more complex than the OS underneath it. It would be the bodge to end all bodges, and really too horrid to contemplate.

With any software development, and particularly OS development, if you can't do it properly, do it at all.

druck on 30/5/09 7:22PM
[ Reply | Permalink | Report ]

Thanks, Druck. As I said I don’t have the wherewithal to quantify this sort of thing. I’m not sure it needs to be a bodge, though. The API Layer as I describe it, or something very close to it, already exists; it’s just that there is only one instance of it, and it’s not defined as such. Creating a new instance of it for each application would resolve many compatibility issues, such as the CSD problem, but I couldn’t quantify the issues it would not resolve (those that would need pre or post filtering; ie bodging).

I accept your view that we should not be writing software which doesn’t do things properly. But I think creating a new instance of the environment that supports an application for each application is doing it properly.

In my view, the real issue, the reason for contemplating this, is that multi-core hardware is going to be available in the foreseeable future, and if RO is to progress, it will have to be developed to take advantage of that new hardware. In doing so, it will have to maintain backwards compatibility for old software for some time. This is, I think, one way of doing it, but if this solution is too complex, a different solution should be sought.

Like the one just proposed by bhtooefr. Would that allow RO to run on more than one core?

Viking on 31/5/09 7:06AM
[ Reply | Permalink | Report ]

Viking, no such API layer or anything close to your concept currently exists. There is no easy way to do this, and no amount of wishful thinking will change that.

druck on 31/5/09 8:37AM
[ Reply | Permalink | Report ]

Surely the way forward for this sort of problem is to define a new API and behaviour that does what is needed.

Then create a module that provides this API for existing RISC OS versions (and hopefully lets new apps use additional processors).

Once enough programs use the new system, the OS could be rewritten to support the new API directly (the old API might even be supplied by an optional module, rather than remaining in the core of the OS.)

Until the OS were rewritten, all the PMT apps would presumably be one CMT task as far as it is concerned, which would obviously limit its effectiveness.

jess on 31/5/09 2:02PM
[ Reply | Permalink | Report ]

There's a name for this process. It's called moving to another system and running an emulator for all the ancient stuff you refuse to abandon.

rjek on 31/5/09 6:37PM
[ Reply | Permalink | Report ]

Viking I have been trying very hard to understand what you are proposing, but I am sorry to say I have to come to the conclusion that you don't have the vaguest idea what you are talking about. API SWI's are Software Interrupts by definition they are short bits of code. Trying to make the system side of the SWI multi threaded is just not going to work.

Jwoody on 31/5/09 8:08PM
[ Reply | Permalink | Report ]

It would be nice for there to be an emulation layer running as a process inside your favorite posix-based OS, such that RISC OS windows had equal billing with native OS windows, otherwise the RISC OS apps will always be at a disadvantage (whether that's actually a desirable situation is another discussion entirely).

That situation would be ideal for me, because then I could use my linux machine as my real primary machine without losing access to my Easiwriter docs. I think it would be a retrograde step for a significant minority of current RISC OS users though, at least in the short term. A modern Linux distro runs so much stuff in the background that something always goes wrong. And while it's easier to fix anything that it is to, oh I don't know - get RISC OS running on all the hardware currently supported by Linux/BSD/whatever, it's still a significant learning curve for newbies.

Note for anyone still reading: this discussion is well and truly off-topic, in case you hadn't noticed. It's got sweet FA to do with Jeffrey and others fantastic efforts towards getting RISC OS running on inexpensive, efficient hardware (or for that matter, any discussions of SMT or PMT or the actual feasibility of doing any of this).

It also broke Drobe's new threaded view at around 120 comments

ninja on 31/5/09 8:42PM
[ Reply | Permalink | Report ]

Well,

Qualcom just announced the new 45nm snapdragon will be sampling from end of year.

1.3Ghz (30% faster with 30% less power draw)

[link]

John

PS chipset includes wi-fi, bluetooth, video acceleration, HSDPA, CDMA

mrmac on 1/6/09 11:18AM
[ Reply | Permalink | Report ]

Just read a bit more...

The 1.3Ghz also has improved Grfx capabilities

Also looks like Qualcomm has 1.5Ghz Dual Core Snapdragons on the way as well

So maybe we should be having a more in depth discussion and plan formation about how multi-core support/better multi tasking could be implemented into RISC OS. Would it be worth having a specifiic discussion area set up for this purpose? Surely now the ROOL project is showing it's usefullness it would be worth having a think about some real improvements and moving the OS forward.

mrmac on 1/6/09 12:44PM
[ Reply | Permalink | Report ]

The forum at the RISC OS Open website is IMHO the ideal place to have such a discussion.

hubersn on 2/6/09 10:14AM
[ Reply | Permalink | Report ]

Yet another target coming up for Jeffrey:

[link]

I want one :-)

davehigton on 2/6/09 2:28PM
[ Reply | Permalink | Report ]

Historically, Qualcomm have been very secretive. All the Qualcomm-based Android mobiles (such as the HTC G1) come with a big fat bundle of closed-source kernel modules to make them work; there is little public-facing documentation

rjek on 2/6/09 2:36PM
[ Reply | Permalink | Report ]

Really? You seen this?

1Ghz OMAP Cortex

And such a sexy case

[link]

mrmac on 2/6/09 2:49PM
[ Reply | Permalink | Report ]

Well personally I'm hoping there will be some useful boards based on the Freescale i.MX515 - a 1 GHz Cortex-A8 with built-in Ethernet and ATA controllers (noticably lacking from the TI OMAP3 that Beagleboard uses, and its OMAP4 successor), it's one step closer to an ideal desktop chip. Shame the video (as with most if not all of these chips, it seems) is still limited to 720p and no external PCI bus.

bavison on 3/6/09 1:44AM
[ Reply | Permalink | Report ]

There are modern Sheeva and Ferocean SoCs that offer 1GHz single or dual-core with twin Gigabit, twin SATA, bags of PCIe, DDR2 and 3, etc. I'm assuming they've fixed the memory access problems wince Ferocean, given it's almost entirely a ground-up redesign.

rjek on 3/6/09 6:50AM
[ Reply | Permalink | Report ]

Actually looking at the vids from now and previous incarnations the freescale units seem to be slow compared to the others.

I think the best cpu for power use would be the Snapdragon with it being faster clock for clock than cortex cores and 1.3ghz and dual core 1.5ghz units on the way.

The last option is the Nvidia Tegra which seems to have 12 units including a good few netbooks on the way. IIRC it is a 667Mhz Arm 11 with DSP and GPU, They have HDMI out and think support 1080p on the HDMI.

However the results seen from omap seem good so far so hopefully there will be enough netbooks based on this to give us some nice options.

John

mrmac on 3/6/09 8:51AM
[ Reply | Permalink | Report ]

Well, while we're playing wishful thinking, I prefer the look of this.

[link]

A little less of a mobikle phone asic.

Now just need someone to donate a few man-years of work to get all the hardware running.

Doh!

Zhadnost on 2/6/09 8:35PM
[ Reply | Permalink | Report ]

Before we get too carried away, I'd just like to point out that this beagleboard development is only happening because Jeffrey has the skills, and found the project interesting enough to attempt, and then other people have come along and helped out where they can, again because they are interested.

Doing a base port like this is a very specialised bit of work. We should be careful not to sound like we're planning Jeffrey's evenings for the next twelve months here. There's no one out there willing to fund this sort of work, so we should make sure we don't look like we're taking it for granted.

ninja on 3/6/09 5:41PM
[ Reply | Permalink | Report ]

Sorry, I was merely trying to suggest that the conversation appeared to be getting out of hand.

Zhadnost on 3/6/09 6:06PM
[ Reply | Permalink | Report ]

Without meaning to belittle Jeffrey's efforts, I think he's shown that you don't need years of experience of developing RISC OS 5 to be able to port it to new hardware - something that wouldn't have have had the same impact if one of us at ROOL had done the port.

That demonstration is really valuable, because hopefully it will encourage new developers to come forward, and so maybe, yes, we can look forward to having a wide choice of hardware on which to run RISC OS. We're already beginning to see the number of developers getting involved rise - and with luck it will keep on snowballing.

After all, compared to 10 years ago, or even 5 years ago, there is now a huge selection of ARM chips available that are capable of delivering a decent RISC OS experience - ARM's traditional embedded market no longer has to mean low performance.

bavison on 4/6/09 3:15AM
[ Reply | Permalink | Report ]

I agree,

Don't think anyone was trying to give Jeffery more work.

We are excited about the possability of good portable hardware and are pointing out some of the possabilities coming to market that could be a good base for risc os.

Doesn't meen there will be a port from them but if it is someones intention to have a go surely it's good to see all the hardware coming out.

Esspecially any based on beagle board or OMAP cortex's

John

mrmac on 4/6/09 10:05AM
[ Reply | Permalink | Report ]

Well this is intresting....

Nvidia Tegra (ARM 11 with GPU & DSP) which is going to come with Windows CE has been shown running the desktop version of Firefox 3.5

This a day after someone showing a android cortex machine running firefox.

Why is this intresting - well it managed 4 tabs at once. It means someone has compiled an ARM Linux version. And a WinCE ARM version of desktop firefox. Maybe some of the work here will make it easier to use Firefox on RISC OS on these new processors.

It does somewhat show of the power of these new chips being that a cortex should be 2 x the CPU performance of the tegra.

[link]

mrmac on 4/6/09 4:32PM
[ Reply | Permalink | Report ]

What's surprising about that? There has always been ARM Linux builds of Firefox. It gets you precisely 0% of the way to a RISC OS build however.

druck on 5/6/09 7:04AM
[ Reply | Permalink | Report ]

Well...

android is based on linux but is not a full build...

However an ARM Windows CE build is new.

Just thought it was good to see more firefox development on ARM really. And how well it seemed to run on the new hardware which will be of interest to us.

John

mrmac on 5/6/09 8:30AM
[ Reply | Permalink | Report ]

Under a UNIX on ARM, one simply builds Firefox in the usual way; as they might on x86. There's no ARM-specific development here.

rjek on 5/6/09 10:37AM
[ Reply | Permalink | Report ]

There may be for CE...

Again it was really just seeing the software run on hardware that could be targets for RISC OS and won't be too diffrent in performance to the beagle board.

If the tegra can handle desktop firefox 3.5 with full flash support and 4 tabs (due to the 512Mb ram) and the speed of the browsing looked excellent (would say faster then most atom machines I have seen) then it bodes well for the ability of the new ARM hardware.

mrmac on 5/6/09 10:46AM
[ Reply | Permalink | Report ]

"If the tegra can handle desktop firefox 3.5 with full flash support and 4 tabs (due to the 512Mb ram) and the speed of the browsing looked excellent (would say faster then most atom machines I have seen) then it bodes well for the ability of the new ARM hardware."

When combined with an efficient OS that it was designed for, perhaps.

rjek on 5/6/09 11:31AM
[ Reply | Permalink | Report ]

Any work for CE will involve changes to the Windows specific code and user interface, it's irrelevant to RISC OS.

Just as irrelevant as fact that all the OS's run on the same processor. Firefox is written in C and compilers can spit out code for any processor. The problem os RISC OS is so privative compared to the other OS's, CE included, a vast amount of work has to be done to provide the facilities the application expects.

Unixlib provides these facilities, but in it's current form it will never allow applications to run at speeds comparable to other OS's on the same processor. There are too many layers because RISC OS is just too different, and feature poor.

druck on 5/6/09 3:22PM
[ Reply | Permalink | Report ]

Don't agree... Firefox is a heavy beast on memory.

Ok so it's running CE but that would likely mean it is missing things firefox needs so would need a lot of extra bits to make it run.

CE is not really designed to run large applications like this so although the OS is designed to be light I feel CE is not going to give Firefox a benefit. If anything it may give it more problems that cause overheads.

Anyway disagree is you wish. I am sure RISC OS is lighter than CE (it fits in a much smaller footprint) although is likely missing some more modern developments CE may now have.

I really wasn't trying to start in in depth discussion or ask for people to pick holes in post after post about why I am wrong.

Just impressed with the speed of Desktop firefox on these modern, recently released, ARM processors. Am I wrong? Does this not show some of the power available? Not sure any Xscale up to 600Mhz would make a decent job of running a desktop version of firefox?

Most CE devices with 400Mhz xscales and a good GPU struggle to make Pocket IE or Opera Mobile run at an acceptable speed and it is designed to be small and light.

mrmac on 5/6/09 1:13PM
[ Reply | Permalink | Report ]

Windows CE is about 20 years ahead of RISC OS in terms of operating system technology. Windows CE can fit into truely tiny spaces, much like RISC OS can. My experience of the Psion Netbook Pro (400MHz XScale) running Linux, Firefox was still painful; but Firefox itself is a lot faster these days than it used to be.

rjek on 5/6/09 1:31PM
[ Reply | Permalink | Report ]

Agreed, though CE can only fit into tiny spaces if you hack away parts of the OS. When installin in truely tiny spaces it is usually for an embedded device with a spcific purpose so you can build a rom image with most things stripped out.

Modern CE - if you don't include any OS software components but all the files and dll's required to make the OS with GUI work - even if you compress the OS would like still take 12-16Mb of ROM.

IIRC CE has quite a lot in common with Win95.

I am currently building a custom rom for my StrongArm CPU'd HPC (like a mini netbook with 7" screen). So I know how big full CE with GUI and normal OS components and dll's is.

My problem is trying to fit all the software I want into the 32Mb rom now

John

mrmac on 5/6/09 1:49PM
[ Reply | Permalink | Report ]

What nonsense. Win CE is based on Windows NT, and is no relation to Windows 95. A full build of WCE OS can easily fit in to 32B, Windows Mobile 6 OS and application suite will fit in 128MB. Most devices these days include an absolute minimum of 256MB of flash.

We aren't working in the days of 4MB masked ROMs anymore.

druck on 5/6/09 3:07PM
[ Reply | Permalink | Report ]

32bytes?

even 32k?

kernel maybe.

If you meant 32MB that don't see where I said it wouldn't...

mrmac on 5/6/09 3:13PM
[ Reply | Permalink | Report ]

And you know what it was a CE software hardware dev that said it was a lot like 95 so I don't know what to say really.

mrmac on 5/6/09 3:40PM
[ Reply | Permalink | Report ]

Windows CE is based neither on Windows 95 or Windows NT. It is a complete reimplementation of a "Windows flavoured" OS. It has many differences. From the API point of view, it possibly has more in common with Windows 98, but it is a very very different OS. At least, it was when I last used it (2 or 3 years ago). Windows CE can easily fit into the smallest sensibly-priced Flash.

Perhaps you misunderstood what this "CD software hardware dev" said, are reading more into what he said, or perhaps he was just wrong.

rjek on 5/6/09 3:58PM
[ Reply | Permalink | Report ]

It was in reply to it someone making a comment that CE had a lot in common to 98. This Dev who I know very well mentioned to them it had more in common with 95 (PS CE2 was released in 1997).

This developer isn't run of the mill and is seriously up on CE and WM.

Just don't understand Drucks comment. I guess he meant 32MB but I never said CE didn't fit in 32MB. I said stripped down and compressed it may fit in 10MB and I said the custom Windows CE rom image I am building for my device would struggle to fit in 32MB.

mrmac on 5/6/09 4:05PM
[ Reply | Permalink | Report ]

"This developer isn't run of the mill and is seriously up on CE and WM."

Then I can only assume you misunderstood what he said. I suppose it's got a lot in common, if you think being called Windows, naming storage devices with letters, and using FAT enough.

rjek on 5/6/09 5:01PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

NetSurf bags GBP10K investment from Google
Four uni coders lined up to improve web browser

35 comments, latest by tlsa on 24/11/08 4:19PM. Published: 21 Apr 2008

Random article

German ROS show this month
Bring a friend

2 comments, latest by highlandcattle on 3/9/06 8:23PM. Published: 3 Sep 2006

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Is it too late to nominate Drobe in the best own goal category?"
Page generated in 0.4302 seconds.