Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Select low-level emulator in development

Published: 22nd Apr 2007, 02:27:39 | Permalink | Printable

RISC OS 5 given dose of SWI OS_AbortTrap

SelectEmu codeA module which emulates low-level Select features on RISC OS 5 is being developed unofficially, it emerged this week. The software, SelectEmu, implements a few core features found on Select 4 RISC OS 6, including ROL's 'abort trap' interface which is useful for developing drivers and virtual memory systems. A prototype virtual memory package already exists for RISC OS 6 and A9home computers, but is expected to work on both RISC OS 5 and RISC OS 6 with the help of SelectEmu.

NetSurf team member and Iyonix user John-Mark Bell said he developed SelectEmu as part of his latest project called MemCheck; the NetSurf developers hope to use this to track memory leaks and related bugs in their web browser. The utility relies on being able to detect when dodgy software accesses memory it shouldn't, and John-Mark said he reused code written for MemCheck to form SelectEmu. Specifically, the module emulates the OS_AbortTrap and OS_ClaimSWI functionality normally exclusive to ROL's operating system.

The software is currently in testing, but is set to be released under a BSD-based open source license.

A SelectEmu tester said: "This isn't really a case of 'reinventing the wheel' because RISC OS 6 doesn't exist for the Iyonix, so this is the first time these low-level interfaces have appeared on RISC OS 5. John-Mark's motivation for SelectEmu was mainly for MemCheck, and he decided he might as well package it up into a module and match ROL's OS_AbortTrap API.

"There could be interesting times ahead if third-party developers decide to implement useful Select functionality into RISC OS 5 by themselves, especially if RISC OS Open's source code does materialise to help this process along."


ROL's abort trap documentation

Previous: Multimedia-friendly 1GHz XScale launched
Next: ROOL make 'market map' mouse mats


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

I remain disappointed by the lack of co-operation between the two threads of RO development; actually, 'disappointed' is rather too weak a word but never mind.

Assuming that this will continue, the type of development described here is a useful second-best: The ultimate aim goal for the OS is to support application software that lets users achieve their needs for the computer. Anything that converges the facilities available on the two threads of RO helps developers to to address a bigger market more efficiently.

Otherwise, developers will likely target something that looks like RO 4.02 (or maybe older), wasting much of the more recent OS development and giving users an inferior overall product. Which would be a waste. So three (muted) cheers for John-Mark.

 is a RISC OS UserTonyStill on 22/4/07 11:11AM
[ Reply | Permalink | Report ]


Although I sympathise with your sentiments, I think this development is much better than 'second-best'. If this kind of thing can be integrated into an open-source RISC OS 5 (which is the implication of the article), then we're that much closer to having a unified OS with the same feature set and API. John-Mark should be congratulated for his approach, which fills a gap on RISC OS 5 while keeping compatibility with RISC OS 4/6/whatever it's called next week.

Also, Chris is being pretty modest about this Virtual Memory system - isn't this a significant development for RISC OS? I think so! Again, the willingness to provide this functionality on both the rival systems is exactly the progressive, helpful approach we need. Castle/ROL: take note!

Many thanks to Chris and John-Mark for these excellent projects.

 is a RISC OS Userlym on 22/4/07 11:23AM
[ Reply | Permalink | Report ]

The important thing is that where a common approach can be done on both OS flavours. Even with RISC OS 5 going "open" it is unlkely RO6/Select 4 will - so that means that unless ROL really get their skates on the only way some of the low level Select features will appear under an "open" RISC OS is via efforts such as this. This is a genuinely useful development (well done),

 is a RISC OS UserAMS on 22/4/07 11:31AM
[ Reply | Permalink | Report ]

This module should benefit ROL too, if software writers use select features, it will make select more attractive.

I can imagine three streams of RISC OS developing, ROOpen, RO Select and GPL (etc) components.

As long as the APIs are the same and the modules reasonably interchangable this need not pose a problem. Select would have to be the best or it would risk extinction.

Hopefully all the players will see the benefit of going in the same direction.

 is a RISC OS Userjess on 22/4/07 3:09PM
[ Reply | Permalink | Report ]

I do agree with lym, AMS and jess that this is useful. Indeed, if the two RO threads are to remain divorced then it is the right thing to do. What appalls me is the waste in doing these things twice when we're so short of developments in the first place. I'm afraid I was just depressed by it all this morning :-(

 is a RISC OS UserTonyStill on 22/4/07 9:29PM
[ Reply | Permalink | Report ]

As I've always said, there is almost no feature in Select that can't be implemented by a soft loadable module taking advantage of the fact that RISC OS allows nearly every API to be enhanced via the software vectors.

If Select features are needed by developers they will eventually tire of waiting for ROL and implement them. This can be done right now with an extension module, and when RO5 is opened source the code can be integrated in a neater manner.

The only draw back to this is the wasted time on duplicating development effort, but that is infinitely better than the wasted time waiting for ROL to do anything.

 is a RISC OS Userdruck on 23/4/07 1:28PM
[ Reply | Permalink | Report ]

I implemented some SWIs for claiming OS SWI calls in a module called DebugTools. This is to be released in the Batch One sources (hopefully).

Ideally, I'd like to see that used on RO5 because it's a more useful API than the ROL one (you can claim, release or add to SWIs in the same way that software vectors work).

Of course, that wouldn't address the issue that there would then be two different APIs.

 is a RISC OS Userriscosopen on 23/4/07 6:55PM
[ Reply | Permalink | Report ]


Cleverer people than me will no doubt make the decision, but I generally think that API compatibility trumps almost everything else. So often 'the best' has been the enemy of 'the good' with RISC OS - looking for the perfect solution while a good one exists. I'd be in favour of sticking with ROL's APIs wherever possible, even if they're not absolutely optimal: we need to heal the wounds, man :)

 is a RISC OS Userlym on 23/4/07 7:38PM
[ Reply | Permalink | Report ]

Can someone point me to the APIs for the ROL versions of the OS SWI claiming calls? It's possible that both could co-exist (the API I did has currently unused flag bits in it for just this sort of thing).

 is a RISC OS Userriscosopen on 24/4/07 1:30AM
[ Reply | Permalink | Report ]

riscosopen: Not me - I've no idea what ROL's API for those are (you'll note in the screenshot above that the export of SWI claiming stuff is conditionalised in SelectEmu). I have no intention of making my implementation accessible outside of SelectEmu unless and until it matches ROL's API.

 is a RISC OS Userjmb on 24/4/07 10:04AM
[ Reply | Permalink | Report ]

I've written up my knowledge of ROL's OS_ClaimOSSWI API at: [link]

 is a RISC OS Usercaliston2 on 24/4/07 1:53PM
[ Reply | Permalink | Report ]

I've remembered the context now. I actually wrote it up for the StrongHelp manual a year or two ago, and confirmed the details with a RISC OS Ltd staffer. That being said, it's very much an internal interface and so subject to change (which is why there's no public documentation on it).

 is a RISC OS Usercaliston2 on 24/4/07 3:29PM
[ Reply | Permalink | Report ]

Caliston2: perhaps I could have been clearer ;) It's the calling conventions of the handler code I have no knowledge of; the rest, as you've referenced, has been floating around csa.p for some time.

 is a RISC OS Userjmb on 24/4/07 7:47PM
[ Reply | Permalink | Report ]

Is the Virtual Memory thing supposed to work on Adjust? Because it states Select4 RISC OS 6?

I have tried it (out of boredom) and it seems to work but (i'd imagine) of course kills any other app that is running other than the test.

It looks good though! :@)

 is a RISC OS Userem2ac on 25/4/07 11:28AM
[ 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

  • Cross platform development
    Building RISC OS Programs on Windows
     47 comments, latest by EasyKees on 07/10/04 8:05PM. Published: 24 Sep 2004

  • Random article

  • ARM 'security hole' is ofla cousin
    One man's exploit is another's .ofla.ofla.ofla
     9 comments, latest by bavison on 25/4/07 10:44PM. Published: 24 Apr 2007

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Drobe seems to be a clearing house for rumour and gossip"
    Page generated in 0.153 seconds.