Polling/Vector Speed

At the moment I have to use wimp_poll with null events and dis-guard 90% of them

s/dis-guard/discard
HTH

Whilst I do like to support legacy hardware and it is nice to support it, there is no point in looking back.
There’s plenty of new hardware for RISC OS and that is where I think we should all be looking.
IMHO if you want to run virtual or a RISC PC/Iynonix etc. then don’t expect any support in the future.
There is no excuse at all now.

Since both RPCEmu (i.e. virtual) and IYONIX pc are happily running RO5, I see no reason not to support them. They usually are more powerful than a RPi.

If you want to go back as far as supporting RISC OS 3.5 on an ARM610 Risc PC, I don’t know. But if you make the nested WIMP as well as current toolbox modules a precondition, is it really a problem? Nobody expects (should expect…) optimum performance on legacy stuff. But if you are adapting your software to run well on both a RPi and an IGEPv5, that is about the same performance gap than a SA RPC vs. a RPi. Whatever you do will work either way.

20Mbit isn’t that modem speed? I’ve got 120Mbit+ internet feed at home ;-)

No, modem speed is what the free file sharing hosts offer you if you aren’t a paid subscriber. Their generous 50KiB/sec.

My Internet is 2 megabit; I guess I can see why NetSurf whinges if the developers have similar capacity connections, in which case it is rather likely that SD write speed would make the cache a bit useless. However, to pop up the warrning because the SD is slow without taking into account the (lack of) speed of the incoming data sort of suggests a fundamental misunderstanding of what a cache is for! ;-)

Most of the graphics on RSS are tiny,

Yes.

so the bottleneck is going to be image translation rather than anything else.

Certainly. This is one of the limitations of our version of RISC OS – no on-the-fly loading of alien formats like GIF or PNG into a sprite area. Instead it needs to go via a translator of some sort.

But the target device is a pandaboard, so the main aim is to have it running smoothly on that.

Hehehe – aim to get it running smoothly on the Pi. I think that is the slowest of the newer range of machines (’cept for an Iyonix, but the Pi is cheaper and you have one…) and if it works nicely on the Pi, it ought to work nicer on everything else.
To get it working well on one of the fastest devices available is a bit Microsoftish. :-P

So please feel free to ignore this.

Oooh, incoming rant. That’s like a red flag…

Whilst I do like to support legacy hardware and it is nice to support it, there is no point in looking back.

Ah – but…

IMHO if you want to run virtual or a RISC PC/Iynonix etc. then don’t expect any support in the future.
There is no excuse at all now.

While I generally agree with you, I think you will find most people here are generally supportive of the idea of using new hardware, but then you’d be preaching to the converted.

The problem is the ones who are not here – the ones who for some long dusty dumb reason would rather continue with quarter century old hardware than touch “anything Castle has been near”. Yes, I had an email a while back from somebody that was so full of hate you’d think Castle had slaughtered their first born or something.

Here’s the deal – the commercial branch of RISC OS is dead. I really don’t imagine Aaron has the time or ability to take on the maintenance and upkeep of an entire operating system, not to mention the ultimate stupidity of reproducing the effort in porting it to, say, the OMAP range and/or the Pi. So with that in mind, I think it is pretty safe to say that “the other branch” has reached the end of where it is going to go.

What does this leave? The “hated” (by some) open source (mostly) branch. Now, I agree, it is much simpler and is lacking the huge amount of TLC that went into the ROLtd branch. The sensible option is surely to get some of the old developers on board and look to what features of ROLtd version is really wanted in this version and try to work out a plan for making that happen.
I mean – some day those RiscPCs are going to break down. Plus they’re limited and inefficient compared to the modern SoCs. Yesterday I was lazy and I booted RaspBMC on my Pi and watched a bunch of videos. The whole shebang was practically running off a tablet charger and outputting 720P HD to my monitor. Why? Because it was using even less power than doing the same thing with my netbook computer. Modern devices are more capable, more efficient, and a heck of a lot faster. If you don’t have any podule dependencies, it makes sense to transition to a newer device. The problem is, of course, software. But there is a reasonable amount of it – the biggies (Artworks, OvationPro, PhotoDesk…) already work. Some stuff may need to be left, but surely a smooth arranged transition is better than a sudden hardware failure because, oh look, that twenty year old harddisc just doesn’t want to spin up any more…

A little harsh perhaps, but there are a lot of people doing some fantastic work on RISC OS at the moment.

My policy right now is as follows:

Code is written for RISC OS 5.
Unless it has specific requirements that make it incompatible with RISC OS 3.7, it will also be tested on that platform under an emulator.
There is no formal support nor testing for any ROLtd version of RISC OS. This is primarily due to a lack of RISC OS 4.xx, though I would assume that something that works on RISC OS 3.70 and RISC OS 5.2x would also likely work on RISC OS 4.xx.

That said, if old RISC OS has a difficult way of doing something and new RISC OS has a simple way, then it’s the simple way I choose – and if that means compatibility is no longer possible, then too bad. An example here is a module starting a Wimp task. Possible on every version of RISC OS. Simplicity itself on new RISC OS. Rather the opposite beforehand. And, yes, it is going to be the little things that cause the incompatibilities; but like you say, we should be moving forward. If RISC OS 5 offers a better way, then perhaps it should be used with less and less regard for quarter century old hardware?

That is, don’t be incompatible by design, but don’t be held back by a need to be compatible.¹

¹ Disclaimer: I can say that – I don’t write software to sell. Those who write software to sell will have a tougher decision to make as one doesn’t normally cut out a swathe² of their potential market without a lot of consideration.

² Any developers willing to put a percentage to sales to older RISC OS vs new RISC OS? If the older system represents less than 10% of the market, that’s a different consideration than if it is half and half…

Agree with all of the above.
My definition of smooth would mean “ohhh! wow that’s amazing”.
But I think your definately right the Pi has to be the benchmark.
I’m interested in writing things that may persuade people to migrate onto newer hardware and off windows (not sure if that is even possible, or I can do it, but it’s an aim/dream – we’ve all got to have one!)

I’ve got 4 spare discs for my RISC PC, just in case…

Time to delete another chunk of code and rewrite it…sigh!

My definition of smooth would mean “ohhh! wow that’s amazing”.

I’ve been using Windows too long. My benchmark definition of “smooth” is somewhat lower. Doesn’t make the system jittery? Doesn’t sit on an hourglass? Then it is smooth.

I’m interested in writing things that may persuade people to migrate onto newer hardware and off windows (not sure if that is even possible, or I can do it, but it’s an aim/dream – we’ve all got to have one!)

Good aim/dream, but the reason I use Windows is because there are some things RISC OS just can’t do.given the simplicity of RISC OS, sometimes I wonder if writing some sort of “Linux wrapper” to run Linux programs under RISC OS mightn’t be the simplest way to get things onto RISC OS? ;-) I would say that’s my dream, but unfortunately the sanity filter in my head is dropping road cones and flashing yellow lamps all over the place.

I’ve got 4 spare discs for my RISC PC, just in case…

And a PSU and… ?

Good luck with the rewrite(s). The ones that bug me are when I drop in some “temporary” code to get something working, and then when I rewrite it with proper (thought out) code……the temp code worked better. Pffft! Some people call code a form of art, and creating art is often painful. Anybody that listens to my attempts with the piano would surely agree…

Here’s the deal – the commercial branch of RISC OS is dead.

I’ve only been here since getting a Pi, but from everything I’ve seen, I agree with you. Wikipedia tells me that 6 hasn’t been updated since 2009, and as you point out it doesn’t work with any modern hardware. I’d go as far as questioning why 6.20 is listed as a “latest release” on the Wikipedia page; is anyone brave enough to remove it? :)

For my definition of smooth, if you look at newsuk. That isn’t smooth, it’s OK – but it’s too slow and is jittery on icon display.
It should load instantly and graphical icons updated rather than drawn on the fly, with the user virtually unaware of anything happening.
It can be done, I know exactly how to do it – it just requires time and a lot of thought on how to structure it.
Long car journey’s to work have fixed the thought part :-(

I’ve already replaced my PSU, well ahead of it breaking. But once it dies, it dies.
But the RISC PC is a good example, NewsUK is barely usable on the RISC PC. It takes 10 seconds to run on my pandaboard to load the main news, last time I checked it takes around 2 minutes to load on a RISC PC.
I think I can get it down to around 5 seconds on a pandaboard and possibly around a minute on a RISC PC

Well off topic continuing on the d4r thread

It takes 10 seconds to run on my pandaboard to load the main news, last time I checked it takes around 2 minutes to load on a RISC PC.

Ouch!

I think the question here might be how to make a slow thing appear to be fast. This is why I suggested loading in the RSS data and then fetching the images in the background and on demand. I have just looked at Google’s News app with my phone set to EDGE (tediously slow!) and after a bit of spinning, the story links appeared with empty grey squares for the images. A little while later, it draw all of the visible icons. However if I scroll down, there are more grey squares until those icons have been fetched.

I think there is going to be unavoidable delays if you are fetching dozens of objects from numerous sites. The balancing act will be in how to make it seem like it is fast.
Have you considered parallel downloading? For example if you have eight categories, downloading 2 or 3 feeds at the same time.

I’ll go look for NewsUK this evening and give it a whirl.

The problem on the RISC PC is changefsi I think. My plan is to give an option of what to use.
There is the internal RISC OS jpg translator, changefsi or imagemagick.

Very late reply to Rick. What you need is:

DIM x% 7
x%!4 = 4
SYS "Socket_Getsockopt", sock%, &FFFF, &1002, x%, x% + 4

i.e. the length has to be pointed to.

As to why I’ve responded after more than 6 years: I wanted to use SWI Socket_Getsockopt in a little bit of test code, and I couldn’t find the SWI documented anywhere – just the C interface. My Internet search for “SYS Socket_Getsockopt” returned only one hit, Rick’s original posting. But that, plus a bit of putting two and two together, gave me a working result. And I hope the result may help someone, someday.

Edit: At least, I hope the code above works. I used it with SO_TYPE (&1008) rather than &1002.