What are you doing with RISC OS?

Hi all. I’m pleased to see what appears to be so much activity in the ROOL forums, with all sorts of people doing all sorts of interesting stuff. I think it can be a little difficult for people (me included) to keep track of all the different projects that people have on the boil or the back burner. So I invite people to reply to this post with a quick description of what they are looking into, keeping the language reasonably simple for the benefit of our less technical audience.

Many thanks!

Currently I’m looking into an issue with the SCSI/USB drivers not liking one of the SSDs that R-Comp are selling (or hoping to sell) to their ARMini users.

After that, it’s anyone’s guess, although chances are it’ll be something related to SCSI or USB again.

I’m working on a new version of Filer Action. When that’s done, I plan on fixing some long standing bugs in the Toolbox, and also adding features to gadgets provided by the TextGadgets module.

After that, who knows :) I’d like to encourage some game development for RISC OS – I’ll make sure Popcorn is Beagle compatible and try and get some resources together for people who want to try it out.

I’ll probably also re-re-release TANKS for the new hardware too, I’m sure there’s life left in it yet :D

Just a thought: is it worth people listing (larger, longer term) projects themselves at Cortex-A8 port status? E.g. the VFP in BASIC work by Alan Peters. My recent listing of the Efika MX needed tweaking, so I’m not going to try to add the BASIC stuff myself because I think it needs separating out properly.

When that’s done, I plan on fixing some long standing bugs in the Toolbox, and also adding features to gadgets provided by the TextGadgets module.

If you’re up for Toolbox work, re-implementing ROL’s recent work on ScrollLists to support multiple columns would be helpful!

I plan on fixing some long standing bugs in the Toolbox

But haven’t ROL already done that? And their versions are freely downloadable for use on RO5.

This isn’t really the right place to discuss it, but I don’t see ROL’s modules as the answer. They might have dependencies to other stuff in RO6, for one thing.

I have a “working with bits missing” version of !Printers that has the !Printers+ extra bits in. I have converted it to be a Toolbox App, with a single Icon Bar Icon.
Its on the “back burner” ATM as I need to find a problem pointed out by Martin Wuerthner when an old settings file with lots of printers is loaded.
The Queue window is the main bit missing.

I am working currently to connect my BB xM to the internet using an USB surfstick (Vodafone with O2 prepaid card).

I general it works with two selfwritten modules and Castles PPP from 2001 but it is horrible slow in the moment and it seems that after less than 100000 received bytes something blocks or the response times are increasing to eternity.

Afterwards I shall try to change my FTDI.modul so that it is working with USBDriver 0.50 or later.

Until now one minor bug inside USB variable evaluation detected. I fear there are other bugs in parameter recognition of special field of DeviceFS and USB.

As was suggested above, the TBA development time right now is in BASIC assembler improvements for VFP/SIMD instructions.

This is leading to much debate (in my head at least) about other enhancements that are needed. I’m particularly keen to borrow syntax from VB.NET as it’s sensible and complementary to what we have now in BBC BASIC.

For example DIM name AS datatype to open up lots of data-types, and OPTION option_name to change behaviour such as forcing variable declaration and making declared variables automatically local to methods. New data-types are the backbone of the major enhancements I’ve been contemplating and the ultimate aim would be OO classes and the ability to publish a class library / component / module.

We’ve also discussed a JIT compiler if we did ever re-write the interpreter, and getting the assembler to publish object/debug files in some form to match up with the whole build system.

I won’t go into it all any more here as there is a very long subject, I’ll publish something elsewhere in due course. For now the assembler enhancements are a good start :-)

This is leading to much debate (in my head at least) about other enhancements that are needed to BASIC. I’m particularly keen to borrow syntax from VB.NET as it’s sensible and complementary to what we have now in BBC BASIC.

I know that J. G. Harston is interested in / has been working on feeding BBFW (BBC BASIC For Windows) enhancements into the ROOL BASIC branch. See here. That page is quite out of date, I believe, but I think the project is still reasonably current.

I think it would be great if you got in touch with him to see if any collaboration could be engineered, or at least to avoid the doubling up of effort! Good luck!

I know that J. G. Harston is interested in / has been working on feeding BBFW (BBC BASIC For Windows) enhancements into the ROOL BASIC branch. See here.

Thanks. That site looks rather like a started but not finished project as it’s a couple of years old. The list of enhancements isn’t all that major but still might be useful. I’ll take a look at the source code to see what’s been done.

Anyone who has knowledge of the BASIC source is most welcome to send me some information on how it works so I can save time trying to figure it all out!

J. G. Harston

There’s his Adding BBFW functionality to ARM BASIC thread too, just in case you’ve not already seen it.

I’m currently in the “back burner” category. I’m planning on developing a wireless driver for the IGEPv2 in the future.

I have been working on developing my FPGA skills with the view to producing a RISC OS system on a chip at some point (way in the future). Probably never be allowed to release it due to ARM licensing.

I’m working on an application to allow RISC OS, and indeed the other files on the SD/SDHC/MMC card, to be reflashed in place. When that’s complete, I will extract the appropriate pieces from the application and make the “CMOS RAM” writable.

Queued up for next projects: Bluetooth, and DisplayLink USB video.

I’ve been thinking about letting some of my vast accumulation of cruft out into the wild.

• !!Deepkeys should probably be standard
• AA5 TskBasic* and AA6 TaskApp should probably be standard
• I’d like to make the Monitor module standard, if only to have a documented way of getting the gamma of the monitor
• VectorExtend solves the Service Call abuse problem properly (if anyone ever writes any new modules) amongst other things
• Many BBC Basic extensions and bugfixes including the original OO syntax
• The auto mask tracing that allowed PDriverPS to support masked deep sprites via clippath
• A tweak to !Printers to make it aware of host printers when under emulation
• Freeway/ShareFS hackery
• Nicer exception handlers that allow you to Do Something About It
• IconMover: Iconbar icon rearrangement by dragging with Ctrl-Shift-Alt
• FilerColor: Path-contextual colouring for Filer window backgrounds
• Filer enhancements such as different colour icons for different drives, icons that show whether the drive is Shared

Oh yeah, is MessageTrans fixed yet so that it definitely doesn’t stiff the whole OS when an app releases the RMA block but doesn’t close the MessageTrans file? Silly design.

Right now:

• A tweak to the Wimp to allow interaction with Filer windows while dragging

*Why the heck do we still have eight character file types? Obsolete RO2-era service call aside there’s no reason for it.

Many BBC Basic extensions and bugfixes including the original OO syntax

I’d be interested in finding out more about this, particularly anything to do with OO as we’re (kind of) looking into this at the moment.

@nemo: many of these sound as if they could be really useful, if they can be made generally available in RO5.

However, I think the Basic improvements would be particularly worthwhile. Why? Because if they were GENERALLY available (ie for RO4, 5 & 6) they would enable developers to take advantage of them. This would make the use of the new Basic spread … which would enable more developers to take advantage of them. The effect of this would be a small step to bring RO4, 5 & 6 back into conformity again, and perhaps to help foster more common software. One can but hope.

One major advantage if the changes could be integrated into the ROOL software is that it would help to reduce the amount of development effort wasted on re-implementing them. Development time is precious, and better spent on new changes.

So, please PLEASE try to let ROOL have as many of your changes as possible (as long as they are generally acceptable, anyway!).

Just my 2p’th.

Many BBC Basic extensions and bugfixes including the original OO syntax

Just cross-linking to nemo’s post in the BBFW functionality in RISC OS BASIC thread. It mentions a lot of speed-related enhancements with I think sound very interesting.

As I pointed out before, it seems like at least three independant parties are now working on or considering working on substantial BASIC enhancements: nemo, Alan Peters (as posted above), J. G. Harston (about whom I posted above). Would be great if you guys were all in touch so that efforts aren’t duplicated.

@Martin

a small step to bring RO4, 5 & 6 back into conformity again, and perhaps to help foster more common software. One can but hope.

I have never supported ROL in any way. Their approach has always been the very opposite of what you quite rightly suggest.

When Acorn introduced major functionality in a new version of RO, they provided compatibility modules so authors could use those new features without locking out users with older versions. ROL pursued the exact opposite policy in the mistaken belief it would help their commercial success. All it does is force authors to avoid that functionality.

This is something I addressed with VectorExtend. One of the things it does is make it very much easier to add missing functionality, as it provides vectorisation (on demand) of every single SWI. Therefore instead of having to provide an entire module to add one new SWI, one can write a much smaller compatibility module that only implements that SWI, to whatever extent is necessary.

This is something I addressed with VectorExtend.

@nemo, is VectorExtend available anywhere on the web? I couldn’t see it on your website. I’d be interested to read more about it…

I have never supported ROL in any way.

That was not the reason for my suggestion. I was suggesting that a commonly available (improved) Basic would help to support RISC OS developers and hence users. Who have both suffered from the silly split.

I do have a vested interest: I am trying to support RISC OS by maintaining (and hopefully improving) a well-known 30,000 line Basic program.

I suppose one approach would be to make the BASIC module softloadable, with a new major version number. This would allow applications utilising the newer BASIC to RMensure it. Since it would be available as a standalone download from RISC OS Open, and presumably freely distributable, it would make a suitable system resource. The only problem I forsee is that running tasks might well be relying on a previous version, effectively pulling the rug from under their feet.

Another approach might be to call this BASIC7 or something, with a different filetype etc. That said, I’m not sure it would be particularly user-friendly to have two different versions of BASIC running simultaneously.

Object-orientated Basic is a breaking change and a new version number would be expected, except the Basic V/Basic VI silliness has already stuffed that.

My build is currently called OOBASIC, so programs can “OOBASIC QUIT <Obey$Dir>.!RunImage”.

is VectorExtend available anywhere on the web?

Apparently not. I will dig it out as it has a number of great features:

• OS Vectors extended from 48 to 4096 (to fix ServiceCall abuse)
• Allocatable User Vectors (millions of them)
• Dynamically allocated User Vectors (millions of them)
• Automatic SWI vectors for OS and Modules (vectorisation on demand)
• Prioritisation of claimants (to avoid the “!!DeepKeys” naming nonsense)
• OS_DeLink/ReLinkApplication bug fix
• All backwards compatible, module works on RO2+ (!)

VectorExtend divides the vector number (ie R0 in OS_Claim) into three fields:

• b31-24 Priority (signed)
• b17 SWI
• b23-0 Vector number (except b17 as above)

So, OS_Claiming vector number &xxFFFFFF returns a dynamically allocated vector number in R0. OS_Claiming vector number XOS_Module (for example) automatically vectorises OS_Module, so you can add reason code implementations. OS_Claiming vector number XSomeModule_SomeSWI vectorises all SWIs of SomeModule.

etc etc

Getting this thread back on topic, my todo list currently looks something like this:

1. Add a new HAL device so that Tank’s GPIO module can identify the board type/revision.
2. Update the switcher/task manager so that the info window will display the ROM build date instead of the fixed date it currently displays (Jan 2010)
3. Add USB CD support, by extending/developing the work that Steffen Huber has already done.
4. Write a SmartReflex driver so that the BeagleBoard-xM/ARMini can (finally) run at 1GHz

In parallel I’m also working on some big kernel changes to allow zero page to be moved from its current location to somewhere more secure. Apart from making RISC OS more crash-proof it’s also helping to track down lots of other bugs which have been going unnoticed for years. There’s an OMAP ROM image over here which brave/curious people can try out. But since there’s a lot of things left on my todo list for this, and it could stand to break a lot of existing programs, it’ll be a few months at least before ordinary Iyonix/OMAP ROM builds will be using the code.