South East show report - RISC OS News, Software and Information

South East show report

Published: 24th Oct 2004, 00:05:03GMT Source: drobe.co.uk
By John-Mark Bell

Page 1 of 1

VA Linux, graphics acceleration, CTL and ROL and more

John-Mark Bell recalls his day out with RISC OS in Guildford, and the various goodies, news and views he ran into.

Another year, another trek to Guildford for the South East show. This is traditionally the time of year that the fruits of the labours of the months since Wakefield are announced, or at least wheeled out to briefly tease us with. So, what was new at Guildford?

Geminus
Geminus logo

Firstly, there was the new Geminus product from the Aemulor team. This is a rather clever module that provides multiple monitor support for the Iyonix. The demonstration machine had two LCD monitors side by side, demonstrating the ability to have the desktop span two screens, which is extremely useful if you're always running out of space on a single monitor - I certainly do, especially when editing source code.

Additionally, Geminus has the ability to rotate the screen display such that you can work in portrait mode. There appears to be a slight issue with this in that the mouse pointer remains as if the screen was in landscape mode (although this is probably a simple thing to fix).

Geminus itself is written mainly in C, with speed-critical parts written in assembler. The resultant module is about 40KB in size, though programmer Adrian Lees seemed upset by how large it was. It makes use of DMA transfer of data to-and-from the graphics card(s), thus speeding up screen scrolling, for example. This was especially noticeable in portrait mode, as listing the machine's configuration status from the command prompt was noticeably slow without DMA transfers enabled. Adrian thinks there's probably some more speed increases to be made in this area.

Also, there didn't appear to be any form of screen caching, such as that demonstrated in Adrian's RedrawCache module. Having used the RedrawCache module on my Iyonix, it's obvious that this would be a desirable additional feature, and one which the Geminus team seemed keen to add.

Faster drawfile graphics
Secondly, and also graphics-related, was the fast drawfile rendering by "SIMON". This was supposed to be demonstrated on the RISCOS Ltd stand, although the machine that the code was running on only had 32MB of RAM and the test drawfile was about 47MB. Therefore, I didn't have the chance to see the rendering in action at first-hand.

ROL chief Paul Middleton did, however, give a demonstration of the technology in his theatre presentation, using a drawfile he created containing a number of copies of the Artworks apple. I've no idea of the resultant drawfile's size, but that's fairly irrelevant. The first render was demonstrated in Draw, and this was quite obviously slow. The second render was done in the demonstration software and this was appreciably faster, if not near-instantaneous.

One thing I did notice, however, was that the graduation on the Draw-rendered page was rather smoother - although this may well have been the result of viewing it on a projection screen rather than a monitor.

Paul was rather coy about the whole thing, although I did manage to extract a few small pieces of information out of him. Firstly, this isn't an entirely software approach: it uses some custom hardware, but what this hardware actually is and does is unknown. From what I could see (and while Paul wasn't looking, I took a look at the result of *modules and *podules on the demonstration machine), there was nothing obviously different about the demonstration RiscPC. It simply had a Viewfinder podule (though with what graphics card, I don't know) and a NIC in it.

As for the identity of "SIMON", Paul was equally evasive, suggesting that if SIMON's real employers found out, they wouldn't be best pleased. When asked if a similar solution could be made available for Iyonix machines, Paul didn't see any reason why not, although he wasn't sure how or where the hardware would fit in.

Linux Virtual Acorn
VA Linux logo

Thirdly, VirtualAcorn were demonstrating a Linux version of their product, although it isn't yet for sale. This is probably good news for those who have been uncertain about the merits of running a RISC OS emulator on the Windows platform.

In other areas, R-Comp were demonstrating their new Netfetch and Dialup software, Icon Technology were demonstrating and selling Easi and TechWriter 8.30, complete with page-break bug (there's apparently a downloadable upgrade on its way soon) and MW-Software was demonstrating the latest version of Artworks2. Peter Naulls (a drobe.co.uk editor) was promoting his Unix Porting Project and Iyonix Linux port, including news of a port of the Firefox browser to RISC OS (although this has a number of issues and is some way off being releasable). Martin Hansen was demonstrating his Maths software, which I confess to neglecting to look at (apologies Martin) and CJE appeared to have brought a small black hole with them, given the amount of items available on their stand.

Theatre presentations
Of the theatre presentations going on, I attended the Castle and RISCOS Ltd. ones, along with the Lillingston and Middleton show at the end. My apologies to Peter Naulls and John Cartmell for not attending their presentations, but the lure of the show hall was too much.

Castle's presentation was mainly based around their new DIY Iyonix product. Jack Lillingston and Will Ling spent much of the presentation demonstrating the process needed to build your own Iyonix, based upon the kit available from Castle. There was a short question and answer session at the end, but there was little new information to come out of this.

More interesting was the presentation by Paul Middleton of RISCOS Ltd. He spent some time demonstrating the drawfile acceleration technology, as I described earlier. After that, he detailed some of the possible future enhancements to Select. The first of these was the intention to make the Artworks file format the default vector graphics format on RISC OS.

It appears that they wish to extend the fast drawfile rendering idea to other parts of the desktop experience, such as enabling transparent windows and optimised redraws. I asked him beforehand whether the idea behind these improvements was to be able to have a compositing system similar to that in Mac OS X. He seemed to suggest in reply that such a thing would be desirable.

In response to a question about future uses for RISC OS, Paul mentioned the BBC and high-definition TV. I'm not entirely sure how RISC OS fits into this, but he seemed to think it was a possible area for consideration. A question was also asked about the new filing system that RISCOS Ltd. had proposed to develop before. Paul stated that searching for files and information contained within them was something that they wanted to do. He seemed to indicate that approximately half the required work had been done on the new filing system.

In the light of the recent agreement of cooperation between Castle and RISCOS Ltd. over the development of RISC OS, the RISCOS Ltd. presentation was reduced in length, in order to allow a question and answer session with both Jack Lillingston and Paul Middleton.

A variety of questions were asked, but the main focus of the session was on the future plans of both companies, along with "who does what". Essentially, it seems that Castle will focus on the embedded market, along with the low-level OS components, whilst RISCOS Ltd. will be charged with developing RISC OS for the desktop market. As an indication of this, Castle's Merlin project research and list of things suggested by users has been passed on to RISCOS Ltd. for them to consider and implement things as and when they see fit.

As for the merging of the two source trees, this is likely to happen over a period of time, with things being merged in as and when appropriate. The general idea is to cherry pick the best bits from each tree, though the actual feasibility of doing this for everything is unknown.

Paul Middleton envisages a series of step releases during the convergence, beginning with Select32 in around about May next year. Paul also seems to think there is now little point in continuing to actively develop for 26bit systems, including the Risc PC. He believes that within 18 months to 2 years, sufficient new hardware will become available (and at the right prices) to persuade users to upgrade to more modern systems from their now aging RiscPCs.

It transpires that the 32bit OS developed for Advantage Six's A9 product range is not based upon a HAL (ie it is tied to that hardware). Both Paul and Jack seem to be committed to the prospect of any future OS versions being based upon a HAL similar to that used in RISC OS 5. Jack seemed very happy with the 32bit OS developed for the A9 range, even though Castle had nothing to do with it.

I enquired about the likelihood of some updated documentation for programmers once the convergence was reasonably complete. Paul corrected my interpretation of the RISCOS Ltd. policy with regards to documentation, saying that the rationale behind API documentation only being available to Select subscribers is due to the constantly moving target that is the Select API. Jack stressed the importance of programmer's reference material and suggested that up-to-date documentation was something that he wants to see made available.

Stefaan Claes asked a question about Unicode support within the OS, which seemed to have both Paul and Jack stumped. Paul seeming to suggest that Unicode support is something that should be in applications and not the OS.

Finally, and unrelated to the presentations, I asked Jack about the prospect of updates to the C/C++ development tools and he suggested that they'd been working on improving instruction scheduling and that a major update is timetabled for around about December.

My thanks, as ever (and I sincerely hope I speak for everyone) to the show organisers and the army of volunteers who helped out to make the show run so smoothly.

Links
Show photos from Peter Howkins

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

markee174 (+1.6) 24/10/04 11:35AM	The suggestion that Artworks rendering capabilties might be included in RISC OS as a core feature so it can display Artworks in the same way it can handle Draw and Paint (although obviously you still need Artworks to create and edit) sounded exciting. Paul said he had been asked about adding PDF support but a PDF renderer was unlikely as it would be too large (potentially doubling the size of the RISC OS code).
john 24/10/04 11:54AM	A very interesting report, and without going, this has to be the best way to find out all the details!
hzn (+1.6) 24/10/04 11:58AM	Best news in the text above ist that the Unix Porting Project is looking into the Firefox Browser ! On other platforms, that is Windows and Linux I use Firefox since quite some time (already when it was named Phoenix and then Firebird) and it is in quite a few extents definitively better than Internet Explorer.
hEgelia (+1.6) 24/10/04 12:58PM	Seems like a good show, thanks to a good report. A lot of exciting things in the pipeline. Well cleared up on SIMON is that it does require a bit of hardware - I was hoping there was some secret wizard capable of taking ARM performance on RO to new heights... But still the bigger picture remains hidden. Very cool is VA running on Linux! *In reply to markee174:* It would be a great idea to adopt Artworks vector format as standard in RISC OS. Draw could then become something like an ArtWorks Light... *In reply to hzn:* I agree. It can see certain obstacles in getting it fully ported, but I firmly believe it can be done. Perhaps others can join the converting process? Having Firefix on RO would bring us bang up to date.
john 24/10/04 1:19PM	I'd agree with the firefox thing, but "looking into" is surely a long way from anything useful. Anything better than oregano (at javascript as well as CSS), that isn't as abominable as oregano 2 is fine by me.
jms 24/10/04 2:05PM	Not being a programmer I might have misunderstood the Artworks renderer thing; but I got the feeling it would be part of a move to allow application sprites to be replace by / supplemented with vector graphics images (which could scale to any screen resolution) and allow things like transparent windows & translucent (+rounded!) buttons.
jms (+3.1) 24/10/04 2:22PM	PM and the BBC thing - he was saying that when it comes to choosing a format for HDTV in the UK, the BBC is not excited by MPEG and are searching for (or creating?) some entirely open system that doesn't require any licensing fees. In such an event, RO would be in a good position, he seemed to feel, to benefit from that. Presumably, by implementing any such freely-available codec in RO. He re-iterated his "server under the stairs" vision but clarified it to suggest the RO would be available as a client to it (not the server!). It would show images / emails / films / sounds / documents / etc. I like to think of this as a sort-of "Star Trek" scenario where there's a central server dishing out the same information but presented differently depending how it's accessed through a visual display or audio "communicator". In the "real world" this could be a computer / PDA / STB on a TV / telephone / etc. He also stressed, separately, that RO must become more "interconnectable" to Windows and Macs - not only at a networking level but the ability to understand foreign file formats. Whether this is aspirational or a specific plans wasn't clear. A couple of other things if I remember correctly - hopefully a new Select release early in the new year. SIMON (whatever is actually is) should eventually be publically available. As well as thinking about including the Artworks renderer as a core OS component, he also suggested that RO were looking at some sort of improved filing system and possibly a providing an indexing service too. This would allow much easier searches for files, apparently.
maikl (+1.6) 24/10/04 2:57PM	I don't understand this Home-Clint thing. If there is one area RISC OS is really way behind than it is multimedia. Is there any modern video format that can be displayed on RISC OS except MPEG? We can not watch DVDs, no Video CDs, no DivX, we can't burn DVDs. RISC OS is not able to show PowerPoint-Prsentations, there is no support for RealAudio/Video and there is no Java. Have a look at the Siemens M740 AV that is a clint that can show Pictures/Videos/Audio and record movies if connected to a server. It costs around 200 Pounds. Sorry, I do not see any chance for RISC OS on this area.
martin 24/10/04 3:40PM	I think maikl makes a very good point. If you want to play DVDs go buy the £29.99 offering in Comet. Of course, what we do need is an efficient DVD filing system which is going to be the benefit of CinoDVD and why I'd buy that. Also, more frivilously, I'd love a pop-video juke box, which I've half got with KinoAMP, and am waiting for Cineroma to be able to cope with AVI file packaging. However, it could be dangerous to take on the mass market multimedia expenience because there play the big boys who have vast resources and will indulge in vicious cost cutting as they slug it out to dominate that emerging market over the next couple of years. Of course, if we were out ahead at the start of this battle then, fair enough, go for it. But unless a RISC OS player has quietly crept ahead of the pack I'd advise to avoid getting too involved. It'd be great if RISC OS can offer it as a bonus, but we must not let multimedia become too big a part of what we are about.
TonyStill (+0.1) 24/10/04 5:06PM	Sadly I missed the presentations but the report above, whilst mostly very good news, sounds a couple of alarm bells for me: * Make Artworks file format the default for RISC OS - this is fine except that the Artworks file format is proprietary and known only to CC/MW. One of the strengths of RO in the past has been the open documentation of its standard vector format (which just happens to be a good one, BTW) - allowing all programmers to process it, or create it, as needed. If this change is to go ahead, the format needs to be made public. [Or maybe I've misunderstood this and the intention is just to use it more, in which case the OS will come to rely on a piece of proprietary rendering software instead]. * The "constantly moving target that is the Select API" - exactly what an API should not be. If applications are to make use of the API, it needs to be well defined, fixed and supported long-term. Acorn's legacy has served us well (respect to the guys that sustained it on the very different machine that is Iyonix) and we should continue to work in this way. Just my two pennyworth. And no disrespect to or distrust of Martin Wuerthner or CC implied.
TonyStill (+1.6) 24/10/04 5:09PM	Oh, and I asked Adrian about the pointer on Geminus when the screens are in portrait mode. He said that he just hasn't implemented that bit yet.
markee174 (+1.6) 24/10/04 7:02PM	In reply to TonyStill Paul was talking Artworks as an additional option, so Paint and Draw are still there. It would be an additional feature - effectively the renderer would be built into the OS to offer additional functionality.
bucksboy 24/10/04 7:08PM	maik1: you've hit the nail squarely on the head! The RO desktop market (ROL's main area of responsibility) will dwindle away without a truly capable browser and at least some of the AV functionality you describe. The former in particular is crucial: I can afford an Iyonix, but I can't regard it as a rational purchase given the performance of the current crop of RO browsers (I've got O1, O2 and Netsurf). George
em2ac 24/10/04 8:26PM	*In reply to Wo:* hooo! nice developments! I hope the firefox thing comes about, thats one thing ill be very interested in! (This is writtern in firefox)
hzn (+1.6) 25/10/04 6:02AM	As for the "Select API" / in reply to ToniStill: I sincerely hope that the RISC OS APIs, SWIs, ... will be documented and the documentation will be open to the public and not hidden away like ROL did and does. Hiding the APIs makes sure that the API is not used by those not having subscribed to Select - well that means that that API shouldn't be used at all. Furthermore putting such an API in the open might even persuade the odd user to subscribe to Select - be it due to more apps making use of its features, or due to the fact that the user discovers features.
mrchocky 25/10/04 8:58AM	*In reply to em2ac:* why are you ill? *In reply to john:* Well, "looking into" is someone else's phrase, not mine. However, I've been "looking into" Mozilla/Firefox for some considerable time. The important thing now is that I'm at a stage where the technology has reached a point where it's sensible to talk about building (which is complex itself) and running it on RISC OS.
Sawadee 25/10/04 9:16AM	Mozilla/Firefox If Firefox is ported to RISC OS, what features does it bring that current RISC OS Browsers don't have? I don't know about Firefox, but if someone could clarify why it is worth porting a whole new RISC OS Browser than to update one we have (like Oregano or NetSurf etc.)? The benefit of getting Firefox as I understand is more choices, feature options, competition etc.
fwibbler (+1.6) 25/10/04 9:44AM	It's a very, very capable browser that walks all over current RISC OS offerings. Most importantly, it's open source and so won't suffer the problem that Browse, Fresco and Oregano1 have (company ending development!) Cheers!
Smiler 25/10/04 10:10AM	The primary advantage to Firefox is the Gecko rendering engine - full W3C standards compliance, a 'quirks' mode for rendering poorly written pages, and full JavaScript support. It's likea combination of Netsurf and Oregano. Also, unlike Oregano, it's designed for the desktop, so it's more intuitive in that sense. Other feautres are tabbed browsing, which you really have to use to understand how good it is. There's also industry standard plugin suuport (so you can get Flash, Shockwave, etc. assuming these will work on RISC OS of course) and it's exntentions and themes. The extensions make it highly customisable. It's difficult to not find an extension you're looking for, to fulfill a certain task. Also, most of these are platform independant, as they're coded in xhtml/html/javascript. Or, you could always look here for more info: http://getfirefox.org
Smiler 25/10/04 10:13AM	Sorry, that should be http://getfirefox.com Also, I apologise for the typos in the above comment - I do know how to spell support really!
mrchocky 25/10/04 11:32AM	"Industry standard plugin support, so you get ...". What nonsense; please make a token effort to research this before making such comments. Any RISC OS browser ought to support the RISC OS plugin format. Supporting any other format is a bit pointless (the O2 issues aside) since existing plugins support guess what format. And guess what format future RISC OS plugins will generally use. "Most of them are platform independant (sic)". No, many of them are x86 coded and have no source available (e.g. Macromedia flash). I have no idea why you'd have a Javascript based plugin, since you could just run the code directly in the browser.
jms 25/10/04 11:46AM	Regarding APIs and documentation; Jack agreed it's very important that such things are made available. Paul stated that, because Select is a development environment, that's why the APIs were only released to Select subscribers. I think the idea being that until things are formally released, they're liable to change. One of the two then said that it's a difficult thing to keep the documentation up to date - Acorn had a team of 13 people! A luxury neither Castle nor ROL have. Paul said Select will always be a soft-load of some sort even on an Iyonix (beacuse that would ensure what's in ROM is stable) I would guess that core ROM version public documentation should always be pretty much up to date, but public Select documentation may lag somewhat. This is all from memory and liable to errors in remembering or interpretation!
Smiler 25/10/04 12:10PM	*In reply to mrchocky:* "'Most of them are platform independant (sic)'. No, many of them are x86 coded and have no source available (e.g. Macromedia flash). I have no idea why you'd have a Javascript based plugin, since you could just run the code directly in the browser." Okay, perhaps I didn't make myself very clearly. That was in reference to the browser extensions not plugins. Extensions add extra features to Firefox itself. i.e. mouse gestures, tab preferences, a CSS editor, mouse/keyboard shortcut configurations. These are coded in JavaScript or similar, as they interact with Firefox directly, for which the UI is decribed in XML and CSS. As for the plugins, with the addition of 'netscape' plugin support, it should make future ports of freeware linux plugins a lot easier, as these all interface using the NS plugin interface anyway. Perhaps from there, there could be further devlopment for the plugins to work with existing browsers, such as a translation layer to convert between RISC OS and Netscape and vice versa.
john 25/10/04 12:35PM	What I was trying to say, is looking into is good, but don't expect it next week running well at a decent speed Although you are a magician (and the grammar police so feel free to prove me wrong! At the moment I use oregano mainly (with JS off) and netsurf for stuff that really needs CSS. For javascript I'm a bit stuck unless it's simple stuff oregano handles. I don't think anyone can easily sum up how great it would be to have firefox, the difficulty in making it work well is equally difficult to sum up. So I'll sum it up with "good luck" (Can we have a preview option for aticle comments please?)
martin 25/10/04 1:21PM	John (Can we have a preview option for aticle comments please?) Err.. Like the button marked 'preview' directly below the current last comment ? (snigger, snigger)
AMS (+1.6) 25/10/04 1:46PM	Nice article John ! I unfortunately didn't get a chance to listen into the Jack Lillington/Paul Middleton Q&A, but some of the comments quoted in the article are a tad alarming: PM for example about Unicode being the responsibility of the Application rather than the OS ?? Is that insane or is it just me ? You'll have (potentially) every application having their own way of implementing it. The very minimum RISCOS Ltd should be doing is defining a standard approach for UCS implementation/API usage (so that at least it won't wind up a massive pigs breakfast of conflicting and incompatible approaches). Ideally Unicode support should be in the OS - full stop end of story. The reality probably will be that if the OS doesn't implement it - it simply won't happen. As to documentation (sigh). Well if I go to Castle's Iyonix website I can get documentation on all sorts of API related stuff. I don't even have to own an Iyonix (although as it happens I do). Select, however, is different, you can't get the documentation unless you're part of the scheme and the reason (going from the article above) is because the API keeps changing ???? Surely if it changes that much it's as much a pain for actual Select users too ? Surely if the excuse applies to people generally it would also apply to Select customers (that is unless they like an unpredictable and changing set of APIs that never match their existing documentation). Nope, it just doesn't ring true, sorry..... and if convergence means that that approach is adopted more generally (rather than the more open one you find on the Iyonix site) then I for one will be very dissapointed.
john 25/10/04 2:54PM	Oh not on my screen all I have is Submit your comment. However I'm using the no frills layout (since moderation on that doesn't require javascript, also it's faster) Which brings up back to the original point With firefox I suppose it would all work nicely
john (+3.0) 25/10/04 2:59PM	And having looked, the normal layout makes odd decisions like anything in brackets should be italic and anything in quotes should be green and italic! However it does allow clickable links. Maybe if the italic/green was made to be CSS we could decide for ourselves, given an appropriate browser
philipnet (+1.5) 25/10/04 2:59PM	*In reply to AMS:* A particular developer commented to me that he though the implementation of cut-n-paste in writable icons broke Unicodce support in the WIMP . *In reply to john:* With firefox, it does all work nicely -- "Self-esteem is for everybody. Self-esteem is for everyone. You can dream and be anybody. But self-esteem is how you get it done."
quatermass (+3.0) 25/10/04 3:00PM	Obviously SIMON has used the hardware internal drawing routines from some Linux port and applied them to the Iyonix Nvida and the ViewFinder Rage cards? I was interested to hear PM talk openingly about the new machines which are due out at much lower prices... There are a number of hardware RISC OS companies which are selling their hardware to other markets. You'll get to hear about these publically within a few months I hope. With these will come higher volume production of motherboards and so much lower prices. Imagine a nice new fast RISC OS motherboard for under £200?
1 comment(s) are below your moderation threshold. Login to view them.
Use the forum for more comments on this article