Comments on Roadmap

64-bit disc addressing

Am I right in thinking that the api is implemented, but doesn’t work beyond 32 bits?

64-bit file pointers

This means support for files bigger than 2GB? This presumably means a new API, if so, then could that new API be designed for non blocking I/O?

Add BZ2 and LZMA imagefs support (sponsor SparkFS?)

Could applications (and !boot) be archives?

Toolbox API up to par with ROL version

Also the imagefilerender API

Full media stack (hey, I can wish)

Geexbox is being ported to the BeagleBoard, will this help? (apart from dual booting the device.)

Integrate theme configuration into disc image

Either change the default theme to a nice modern one, or a retro space saving one (with the modern one replacing it in boot)

Larger RAM disc support

Could memphis3 be used? (It also moves scrap, which is good for CF users)

New FileCore format for huge modern discs

Would this be an existing open format?

Things I think have been missed:

Packaging. (it would be nice to have a packager and disk formatter in ROM and be able to build an entire system with a just network connection)

Security. Update the lock system to administrator and user modes. Restrict filer booting.

Boot improvements. Change location and separate parts that need writing to by user. (eg for Live CD)

Improved task manager/killer. (Alt-break to bring up a task manager like windows has, ctrl-break to ask if you want to reboot or try task manager)

64-bit disc addressing

Am I right in thinking that the api is implemented, but doesn’t work beyond 32 bits?

I believe that’s the case, yes. I’ve never actually looked at the code to make sure, though!

64-bit file pointers

This means support for files bigger than 2GB?

Yes.

This presumably means a new API, if so, then could that new API be designed for non blocking I/O?

Yes, this could be the perfect chance to design an API that supports non-blocking I/O.

Add BZ2 and LZMA imagefs support (sponsor SparkFS?)

Could applications (and !boot) be archives?

I don’t see why not. Although I’m not sure how much of a benefit it would give, since RISC OS doesn’t suffer from the software bloat that Windows or Linux does (or not yet, at least).

Full media stack (hey, I can wish)

Geexbox is being ported to the BeagleBoard, will this help? (apart from dual booting the device.)

Not really, no. All the real problems are within RISC OS itself, e.g. the lack of non-blocking file I/O, lack of any real threading, lack of CMT in the Wimp, the lack of VFP/NEON support in our current compilers, etc. Plus we’d need to design suitable APIs so that codecs can be shared between media players, and so that media players can make use of hardware YUV overlays where possible, etc.

Once we’ve sorted out those issues, getting our hands on suitable codecs is actually very easy. E.g. we’ve already got an ffmpeg port, which contains code for a shed load of different codecs. Once we have VFP/NEON support in the RISC OS port of GCC it would probably be pretty trivial to create a simple standalone ffmpeg-based media player (although other issues listed above like lack of non-blocking file I/O may still cause performance issues)

Larger RAM disc support

Could memphis3 be used? (It also moves scrap, which is good for CF users)

Memphis uses a dynamic area, doesn’t it? That isn’t the best way of doing things since it eats into the logical address space, as outlined by Ben in this post. So when I added that entry to the list I was envisaging that it would be done in the way Ben described – move the RAM disc to the application slot, and preferably update DMAManager to support memory-to-memory DMA to allow data to be copied in and out without having to page in memory all the time.

In fact, if there was a way of claiming physical RAM pages without mapping them into logical space, then the act of DMA’ing data to/from those pages would be practically indistinguishable from the act of DMA’ing to/from a hard disc. This could simplify things since we wouldn’t have to mess around with mapping the RAM disc into and out of the application space all the time. (And the ability to claim physical RAM pages without mapping them in is definitely something we’ll need at some point – we’ll need it for hardware display rotation on OMAP, or for giving the DSP its own private memory, etc.)

New FileCore format for huge modern discs

Would this be an existing open format?

We could go down that route… but I didn’t add that entry to the list, so I can’t really comment :)

Improved task manager/killer. (Alt-break to bring up a task manager like windows has, ctrl-break to ask if you want to reboot or try task manager)

Yes!

I know ROL have made some changes to RISC OS Select/6 to make it easier for the OS to identify what programs/modules have produced an error. It could be worth following their lead and implementing a similar system ourselves. Hopefully some of this will come naturally if we add proper process/task support to the kernel.

Yes, this could be the perfect chance to design an API that supports non-blocking I/O.

I guess there would have to be a module that maps this API onto the old one for filesystems (and OS versions) that don’t support it. (Big files could be saved as a folder of sub 2GB files). There would presumablby be no performance advantage possible by mapping the new API to the old for old systems.

Could applications (and !boot) be archives? I don’t see why not. Although I’m not sure how much of a benefit it would give, since RISC OS doesn’t suffer from the software bloat that Windows or Linux does (or not yet, at least).

It’s not really filesize I was thinking of, more protecting the filetyping and filenames. It would mean, for example, that an old style FAT or ADFS filesystem could be used as the drive format.

we’d need to design suitable APIs so that codecs can be shared between media players

Isn’t this what replay was for, or is it too far out of date?

like lack of non-blocking file I/O may still cause performance issues

As far as I can see this one is the real show stopper for decent multimedia.

Memphis uses a dynamic area, doesn’t it? That isn’t the best way of doing things since it eats into the logical address space

In which case, would it behave similarly to it? I.e only consume RAM as needed? Also a RAM based scrap is nice. Also could it optionally spool to disk when RAM is short?

New FileCore format for huge modern discs Would this be an existing open format? We could go down that route

Would UDF be a suitable candidate? (It works on Windows, and would also solve so DVD reading issues)

Thinking a bit differently, why do we need a RAM disc? On any machine that has hard/flash disc, wouldn’t it make more sense to use unpaged RAM to act as a disc cache? So the majority of accesses would come out of the RAM cache, without having to touch disc. Disc would only be used if it ran out of RAM space. That way all file accesses would benefit, not just ones targeted at the RAM disc. Such a thing could be done at the block level to avoid having to mess with FileCore. Any time anything wants to claim RAM, the cache is just reduced in size.

You might be worried about cache being ‘contaminated’ by accesses to other files which you didn’t care about so much (imagine running a compile while writing a CD ISO image – the CD blocks might trample the contents of the cache). In which case you could just mark some volumes as cacheable and others as uncacheable. The area could be wiped on boot, so that it gave the same behaviour of a RAM disc.

Thinking a bit differently, why do we need a RAM disc?

I like a RAM disk, because I don’t want temporary files saved, and I might want to run from a medium with limited writes or even a read only medium.

wouldn’t it make more sense to use unpaged RAM to act as a disc cache?

However, wouldn’t your system be able to act as a real RAM disk? (by having the Temp FS optionally unable to write to disk)

Compressed ROM images

 Huffman coding (256 entry histogram) -> 3460466, saving 17%
 RLE -> 4040755, saving 3%
 GIF (LZW) -> 2949259, saving 30%
 Squash -> 2817215, saving 33%

There would need to be a little fiddling in the HAL because there are some ‘CallOSM’ before the jump to the OS. Alternatively, the module chain could be squashed and the kernel left decompressed, Sprow.

preemptive multitasking

An excellent achievement though NetSurf is¹, would PMT possibly help with the (technical) viability of a future Opera port? (Note that the "couple of million users" requirement was made by someone no longer working for Opera!)

¹ *Dons flame-protective suit*

This thread has some interesting information on PMT

https://www.riscosopen.org/forum/forums/5/topics/428

I see SparkFS appears in the roadmap. Someone should have told me that you value bzip2 and lzma so hightly and I might have done them.

On cramming more into ROM. I note that I was paid by Acorn to write ShrinkWrap to allow them to do this on the Network Computer. Probably ROOL own this, and I’d be quite happy to hand over the sources.

As to “can applications be archives”, yes they can if you have SparkFS loaded. There is a little bit of ticky tacky (the “ImageFSFix” module) that fools RISC OS into thinking an archive starting with a ! is a folder starting with a !. Acorn were not keen to build that functionality into RISC OS.

"[ROOL] will also be making a significant announcement ahead of the show on how members of the RISC OS community, and even those outside the community, can contribute directly to the development in areas of RISC OS that they feel are important."

We wait in anticipation! Could this be the proposed bounty system?

How will the target amounts of bounties be decided and where will they be shown? (The current RISC OS Open administration bounty/poll doesn’t give this info, but is that where it’ll go?) And might it be worth specifying a calendar (or fiscal?) year for such ongoing cost bounties?

[Edit: And where is it intended for new bounty proposals to be discussed? Initiating such discussions at Bounties appears to be precluded by the description of “Discussion of items in the bounty list.”]

Best to start a thread in the Bounties group. You’re taking forum descriptions too literally! :-)

Thanks. I just didn’t want to be the first person to start a new proposal in the wrong place!

As for target amounts for bounties, I would say this: hang on until we’ve written the associated (wiki) page explaining all about how the bounties system will work… :)

We wait in anticipation!

This was all tied in with the Planned web site down time, wasn’t it? While the Bounties page explains things, did I miss the “significant announcement” somewhere? I can’t find anything on the newsgroups either. Of course, TIB covered it (in a manner of speaking) on 1st April.

An official announcement/press release should get picked up by some mainstream websites, possibly encouraging further donations/discussion/bounty hunters.

Aye, an official announcement would be good, especially for people who weren’t able to catch your talk at the Wakefield show.

We’re planning on putting together a formal announcement, including lots of useful info about the thinking behind the scheme, and then publishing that in as many places as we can. One thing that’s been holding this up is the fact that we have to resolve internally what the last few bounties are going to be in the first batch of things published on the site. What we’ve got up there right now is just the first few – I’d like to have another four or five. This is tricky because we’ve hit the point where the things we want on there aren’t so easily self-contained and/or don’t have such a clear end point. Both of those factors are very important for defining a bounty – after all, we need to agree with any claimant about when they can be paid!

Keep watching this space…

…for the sake of archives, here’s the announcement.

I’ve made a couple of changes in light of recent comments, with the intention of providing an up-to-date list for any newcomers. Someone please feel free to correct any errors/omissions.