Universal data exchange module

That said, FFS… Can’t we manage to promote our platform in a positive way

Good job there is an Introduction to RISC OS Cloverleaf
on Youtube that is more positive and focuses on RISC OS.

Even better I can watch it on RISC OS thanks to Chris Gransden and Raik Fischer to mention just a couple involved in getting all the components to work in true RISC OS style.

Just need the in browser route to be supported now but you can download individual components to make it work which at least gives us the ability till then.

Every day I see emails from ‘professional services’ people like web designers, SEO specialists and app developers touting their services and products.

Ditto, but they usually appear on Yahoo! or orange.fr (which is interesting given that I don’t give out the Orange address, it’s used only for the riscos.fr mailing list and a place where my blog code sends comment notifications).

Christine’s message used my domain email. ;-)

If it comes from a gmail/outlook/hotmail/yahoo email domain I bin them instantly without reading them as I see it as unprofessional.

If it comes from a domain, it would be binned. I don’t mind being contacted in return to something I’ve asked about, or being contacted about things that are relative; but spamming me with random emails trying to sell me irrelevant rubbish is a pretty decent way to ensure that your address (or entire domain) gets added to the spam filter. No, I don’t need new trainers, a cock ring, or somebody to write my essays for me.

It doesn’t take much to get a personal/commercial domain

Uhh….? riscoscloverleaf.com
Most hosts offer varying degrees of email support. Just point the MX record at it, if it hasn’t already been set up.
Depending on the level of hosting, you may have one email address and numberous aliases (that’s why my domain has) or a number of mailboxes. The latter is the way forwards if there are numerous people who will require their own contacts (as in this example).

But, yes, using personal GMail isn’t… confidence inspiring.

I wanted to pop over to Key Systems GMBH to see what sort of hosting packages they offer (or gawp at the screen with my eyes glazed over as my German is practically non-existant) but Cloudflare (surprise!) helpfully returned an error 520 and “blamed other man”.

and front that onto a gmail or whatever account in the background.

Do NOT do this.
There’s this little thing called GDPR and passing people’s messages to American corporations known for peeking at people’s messages isn’t going to win any friends (never mind the legality of it).
Just buy a hosting package with email…

more for anonymising purchases and enquiries on web forms.

Ditto. Mine are via Yahoo! and use the format “heyrickmail-(somewordhere)@yahoo…” where the word is often something that relates to the site in question. Thus, if I were to suddenly get a lot of spam from heyrickmail-netflix (for example – it’s a fake address, I use a different one with Netflix!) then I’d know the origin of the spam.

But, yes, when one looks anywhere online, it is okay to have a “wanadoo.fr” or “@gmail.com” if that person is a roofer, chimney cleaner, or person who can mow gardens.
But if IT/tech is their forte, then using a third party host/service as their contact/site is a big point against them. There’s a computer repair place in town. Their website is companyname.pagesperso-orange.fr. Yes, the little bit of webspace that Orange offers their subscribers (it might support “up to 6GB” but doesn’t even offer php; and you can have “up to six sites” using their site creator tool, or only one site if you want to roll your own HTML.
But, their ISP’s “homepage” collection? Great job convincing me that they have a clue…

I also have no intention of joining any social media (data harvesting) site.

My problem with Facebook isn’t so much the rampant collection of user’s data as much as the fact that it has the potential to be extremely harmful.
https://www.theguardian.com/technology/2020/aug/19/facebook-funnelling-readers-towards-covid-misinformation-study
That following the likes of Cambridge Analytica (and all the other stories) mean that I’m not going anywhere near it. “Facebook considered harmful” is my attitude.

Erm, didn’t Select have this years back, probably over a decade now.

ImageFS, wasn’t it? I mentioned that earlier in the thread. ;-)

I am sure what the legal implications would be to do a rewrite against the same API

We live on the sane side of the ocean. APIs are not “protected”.

It would seem to be more sensible than to reinvent a wheel?

Depends. If we’re going to design something from scratch on a system that doesn’t run the old incarnation, there’s not necessarily any specific need to stick to the same API. That doesn’t mean ignore it, as the thinking and ironing out of wrinkles has already been done. However if it is hard to get info on, incomplete, or whatever… then it’s not a case of “this or nothing”.

Priority is image formats but other data types should be also included like:

I’m not sure if putting everything together as a “jack of all trades” convertor is a good idea. Each data type is distinct and has numerous requirements that don’t apply to the others. For example, how does “width”, “height”, “colour depth”, and “decode this line of pixels” apply to audio formats? How does “sample rate” and “mono/stereo” apply to images?
They are not the same, and shouldn’t be treated as being the same.

That isn’t to say there can’t be a sort-of-unified API, that is actually provided by different modules (with specifics for the data types) but overall behaves in a fairly similar manner.

So I would like that a module is included in RISC OS that all programmers can use to access images (load and save).

Yes. It would make sense to have a controller module that can accept a number of plug-in modules to provide handling for specific formats (not unlike how HTTP/AcornSSL and URL interact). I think it would probably suffice to support “converting X to sprite” and “converting sprite to Y”. That means that PNG to BMP would go via a sprite intermediary, but working on X→Y just over-complicates things. Sprites can cope with CYMK and such, even if the OS routines aren’t quite there yet.

Image files: brightness, saturation, gamma. etc.

No. That would be better handled by a separate module that can modify sprites (it probably best belongs as a part of SpriteExtend?) not part of the loader/saver. It’s good to provide, but don’t overcomplicate.

The mimimum would be five SWIs:

1. I want to load this sort of image, can something do it?
2. I want to load this file, can anything handle it?
3. I want to save a sprite as this sort of image, can something do it?
4. Call to load an image (creates a sprite)
5. Call to save an image (from sprite input)

Obviously it’ll be more complicated in reality, as the colour depths would need to be defined, plus knowing how much buffer space is needed to hold the output, plus setting up options like interlacing and quality and colour subsampling.

BTW, the difference between the first two calls is that the first one you say “16 colour GIF” or whatever, while the second one you just point at a file and the module will have everything look at it to see if anything recognises it from the header(s).

So the program just must call that library to offer additional basic processing features to the user.

The problem with libraries is that they aren’t usable from BASIC. That’s why the useful stuff is a module that provides SWIs.

The question is if we create a new module or use for example ChangeFSI as the base.

Don’t use ChangeFSI. It’s slow. Turn off all the image tweaking and load a full sized photo into ChangeFSI.
Now try SwiftJPEG or PrivateEye.

Image: my backdrop. 1600×1200 JPEG.

SwiftJPEG – loads instantly.
PrivateEye – loads instantly, can be converted to sprite (with no discernable delay).
ChangeFSI – takes ~5 seconds to load and convert to sprite.

Andrew McCarthy
Also I’d propose a module that did filename and file path translation from/to other systems (Windows, Linux, …) might also be useful to developers.

There is a module that does it and we will have it in our Cloverleaf Distribution. But I forgot the name…Raik knows it.

Chris Hughes
Can you afford the autoCAD licence fees for this for vector files?

No so….

Chris Hughes
I think we can do most of the Audio ones as well.

I am not aware of a sound file conversion module, which doesn‘t mean it doesn‘t exist. If yes then please let me know which one is it. Maybe Jason Tribbeck has some code also to load audio files as he has written Sonor.

Chris Hughes
Ok the 3D stuff no we don’t have anything as far as I know, but can RISC OS actually do any of that stuff?

That is one my goals to get 3D GPU support for RISC OS and from there is only a footstep to anything that has to do with 3D.

Chris Hughes
If you restrict your idea to only those computers with NEON CPU you cut off a large chuck of users.

It should be no problem to write the code independent from the computer hardware. So it should check if NEON support is available. NEON support is also second step only as also that code must be written first. BUt there might be some people around that would like to have fun with that I guess.

Chris Hughes
I would far rather the existing bounties were completed as a first important step to move RISC OS forward. Invest in them first.

If we get enough funding we probably will fund all open bounties of ROOL. But this conversion module is independent to all that as nobody was planing to do it.

Chris Hughes
RISC OS 6

I am going to try to talk to RISCOS Ltd. and find out if any possibilities to take over any of their achievements.
But that not only depends on if they agree but also how much they want for it. Most of the RISC OS 6 stuff looks for me nice to have but not essential like WIFI, Bluetooth or NVMe support.
If not then any member of the RISC OS community don‘t need to mention it anymore (like in every discussion) as this is the last chance. RISC OS 5 is the future RISC OS 6 history! :-)

Doug Webb
There are but this is about implementing it as a standard OS function aka Select/RO6.
It is then supported in the OS and does not come down to if that app is manitained or not.
Also if it is a OS function one would expect a standardised API to access the functionality and make it available to any programme though if there is an existing API that looks good then just bring that in to the OS.

You got it!

Steve Pamplin
Unless I’m mistaken GIMP is a GPL code item and as such the code couldn’t be used as part of the OS.

GIMP will not be part of the OS but we might check the GPL license. Licenses sounds like fun!
Ah Chris Hughes gave some details later on about GPL.

Rick Murray
Isn’t this idea basically ImageFS?

I googled for ImageFS but nohting came up….

Chris HughesCloverleaf RISC OS. Christine Faith Lopez

Off topic… but yes she works for us in the marketing of the crowdfunding and Facebook page https://www.facebook.com/RISCOSCloverleaf
Seems some stuff still needs to be optimised…
Yes I can understand why you get suspicious when you get an email from a country that is not related to the project but this internet world now….
Also they use casual language that might look also suspicious. We will give her another email address.

Grahame Parish
I suppose we’d be looking at something like a Shared Image Processing Library and a Shared Audio Processing Library, both with softloadable supporting modules to add new functionality/file type support to make them extendable.

Is that Linux stuff or RISC OS stuff?

got it now! (how quotes work..)

ImageFS, wasn’t it? I mentioned that earlier in the thread. ;-)

No. Image File Renderer maybe? It was part of the OS. InageFS was a commercial product for RISC OS 3.

!

+1

I am amazed that with all these suggestions no one has done their homework and identified Image File Renderer as exactly what we want. That is not ImageFS.

@ Chris Hughes

Ok the 3D stuff no we don’t have anything as far as I know, but can RISC OS actually do any of that stuff?

There was a Mesa 3D libs port for RISC OS 3.x, it has been maintained for a while. For who has no idea what that means Mesa is an implementation of OpenGL which is the de-facto standard in terms of 3D libraries, however the RISC OS port was for an old Mesa release.

There seems to be also a more recent one and someone also ported or partially ported Vulkan drivers to RISC OS, but there is no source available (AFAIK) so far, so cannot tell the state of these new ports.

@ Stefan

That is one my goals to get 3D GPU support for RISC OS and from there is only a footstep to anything that has to do with 3D.

That is a great news, however the graphic stack should be seen as 3D Library ( as above Mesa, OpenGL, whatever) → GPU accelerated driver (if I understand your words correctly this is what you want to achieve).

My personal recommendation for all the APIs you want to add to RISC is to go use standard APIs (either port them OR re-create them) this will make it easier to port existing software to RISC OS. If you instead go for designing your own API that may be better (or not), but certainly it will make life more difficult to who wants to port applications or games to RISC OS.

As a differentiation point for the OS you could focus on the Kernel development and a better WIMP for example, while porting standardised APIs for sound, graphics and DRIVERS (which is another important and missing bits). This way you would still have an OS that is not Linux or macOS, but that at the same time allows a faster process to port code which is also vital to have the OS survive in a market focused on the end user.

Just my 0.5c

I googled for ImageFS but nohting came up….

Now, is that because Google tries to be helpful and thinks you meant to type “images”, or is that because “recently” in RISC OS terms predates the era of “everything on the web”? ;-)

It is reviewed here on page 30: https://armclub.org.uk/eureka/issue18.html

No. Image File Renderer maybe? It was part of the OS.

Yeah, you’re right. I was probably getting confused as I’m sure Select had ImageFS as one of its bundled thingies.

Gerph to the rescue: http://gerph.org/riscos/ramble/graphics-conversions2.html

Stefan, there’s your API. Implement that.

@ Rick Murray
OK I am onto it to check about Justin and his Image converter.

In response to Chris Johns and Steve Drain

am amazed that with all these suggestions no one has done their homework and identified Image File Renderer as exactly what we want

Keep up at the back, :-) ,as this was mentioned up the thread on the first page.

As I said it is a shame the ROL image file renderer
stuff isn’t available as it is one of the things I miss about Select that just gave it a better overall feel.

Grahame Parish
I suppose we’d be looking at something like a Shared Image Processing Library and a Shared Audio Processing Library, both with softloadable supporting modules to add new functionality/file type support to make them extendible.

Is that Linux stuff or RISC OS stuff?

RISC OS – As in SharedCLibrary, there could be an extendible SharedImageLib and SharedAudioLib?

RISC OS – As in SharedCLibrary, there could be an extendible SharedImageLib and SharedAudioLib?

Copying the SCL concept doesn’t sound like a good idea. You’d be better off creating a standard SWI-based(?) RISC OS interface for it… which I believe might already have been done once before.

OK I am onto it to check about Justin and his Image converter.

It’s part of RISC OS 4/6. Which brings us on to…

I am going to try to talk to RISCOS Ltd. and find out if any possibilities to take over any of their achievements. But that not only depends on if they agree but also how much they want for it.

I don’t want top stop you doing stuff, but there’s “history” here, and RISC OS Developments were already talking to people, I believe. Maybe talk to Richard and Andrew before you go direct, just to see what (if anything) is currently happening. Too many cooks, and all that.

If we’re going to design something from scratch on a system that doesn’t run the old incarnation, there’s not necessarily any specific need to stick to the same API.

If you do keep the old API, even if you reimplement it from scratch, then any software from 20 years ago which used it stands more of a chance of working on RO5 with less work than if you follow the “not invented here” approach.

Keep up at the back, :-)

Ouch! But it did not have capitals, Sir. ;-)

Chris Hughes I think we can do most of the Audio ones as well.

I am not aware of a sound file conversion module, which doesn‘t mean it doesn‘t exist. If yes then please let me know which one is it.

If I remember correctly MusicMan from R-Comp can convert a fair few audio formats. Plus someone else has done something to do with the various trackers.

I am going to try to talk to RISCOS Ltd. and find out if any possibilities to take over any of their achievements. But that not only depends on if they agree but also how much they want for it.

I suggest you talk to RISCOS Developments rather then approaching RISCOS Ltd since they have already been talking to them.

Good job there is an Introduction to RISC OS Cloverleaf
on Youtube that is more positive and focuses on RISC OS.

Am I the only one who has noticed the slow screen update in this video. At several points, it’s painful to see the screen redraw in slow time. The worst example is a few seconds after 9 minutes into the video where it’s obvious that the processor is struggling.

I suspect that the video was captured on Windows/Linux/MacOS running RPCEmu with a modified version of RISC OS Direct. Perhaps the screen resolution and/or colour depth could have been better chosen. Whatever the reason, it doesn’t do RISC OS any favours.

It pains me to appear unduly critical but I can’t be the only one to have been disappointed by this aspect of the video which otherwise presents a good overview of RISC OS in its 12-minute running time.

Yes it was a little distracting in parts and hopefully it can be fixed for next time as the rest of the content was good.

@John McCartney
I suspect that the video was captured on Windows/Linux/MacOS running RPCEmu with a modified version of RISC OS Direct. Perhaps the screen resolution and/or colour depth could have been better chosen. Whatever the reason, it doesn’t do RISC OS any favours.

Yes the reason for the slow update is that the background was JPEG format. It must be sprite format then it is quiet fast. The Pinboard should be improved that it converts any JPEG to sprite format at loading time. And yes it was done on RPCEmu. But good news is that Tom Williamson will do next days a new one so that should be solved then.

But good news is that Tom Williamson will do next days a new one so that should be solved then.

That’s good news Stefan. Thanks for letting us all know that it won’t be left as it is.

Whatever the reason, it doesn’t do RISC OS any favours.

Valid marketing point.

For my coming videos,I use an overclocked Pi4, with a hardware capture video device.
Even Iris is (almost) fast on it :)

I have still problems to switch to 50Hz mode (important for games). Group1 modes only give me black screen.
Perhaps I should try with hdmi_ignore_edid=0xa5000080.

@ John

Am I the only one who has noticed the slow screen update in this video.

No, we all noticed that. They used a JPEG background, which causes slow redraw at the moment. I immediately informed Cloverleaf team when I saw the first version of the video, but it was too late I guess.

BTW, thanks Stefan for the reply to my suggestion on youtube :)

Whatever the reason, it doesn’t do RISC OS any favours.

Agreed, but let’s not forget there are also RISC OS Direct videos that are very very well made and informative on a lot of things. There are right now 4 videos and they cover a lot of RISC OS features and configuration as well as possibilities, so I don’t think RISC OS is doomed by a JPEG backdrop :)

I think Cloverleaf project will definitely bring something good in the mix, so personally I am positive about it.

IMHO:

While videos are good and helpful, I totally agree with Steve Fryatt when he says let’s not fool ourself on what RISC OS can and cannot do right now.

So, until RISC OS will not show “something special” to the non-historical RISC OS users, there won’t be many people seeking for these videos. Right now RISC OS it’s just an OS to have fun with, and for people like me also a nostalgia thing of my youth.

However, Stefan F. is definitely onto something when he tries to collect info on the missing APIs/features that may improve RISC OS. And a project to actually find funds to fund professional development (and not a part-time/weekend thing as it is now) of some of the missing pieces is definitely a good and welcome thing.

@Chris Hughes
MusicMan from R-Comp can convert a fair few audio formats.

Thanks for the hint. I will ask Andrew about it.

@Paolo Fabio Zaino
That is a great news, however the graphic stack should be seen as 3D Library ( as above Mesa, OpenGL, whatever) → GPU accelerated driver (if I understand your words correctly this is what you want to achieve).
My personal recommendation for all the APIs you want to add to RISC is to go use standard APIs (either port them OR re-create them) this will make it easier to port existing software to RISC OS.

Yes use existing API is right but only works for 2D stuff like draw lines or move screen content as 3D doesn’t exist and I guess also no video SWI’s.
But before all that we need to decode the video drivers as ARM doesn’t give any programmer information how to use their GPUs.

But before all that we need to decode the video drivers

Many years ago I devised a ridiculous idea.
A “Linux loader” that faked enough of a typical Linux kernel that a driver blob such as that may load, start up, and be used.
I wonder if there is still some merit in that idea?

as ARM doesn’t give any programmer information how to use their GPUs.

That’s quite common, unfortunately.For three reasons.

Firstly, stuff like that is crawling with patents, company secrets, intellectual property, and whatever other nonsense they can come up with to make themselves better than the rest.

Secondly, knowing how the driver works can tell you a lot about how the hardware works. Information that might be useful to the competition.

Finally, there are a lot of crap patents out there (mostly in the US). If your driver is a closed source binary blob with a “using this means you agree to not hack it” type licence, then it’s hard to be trolled when there’s little real way of taking the driver apart to see how it works. But if the source code is made public, the trolls will crawl out of the woodwork to say “I own the patent on addition, pay me”. Since it’s the lawyers that get rich from that nonsense, it is not going to change in a hurry.

@ Stefan Fröhling

Yes use existing API is right but only works for 2D stuff like draw lines or move screen content as 3D doesn’t exist and I guess also no video SWI’s.

Ok, so trying to understand here:

As 3D Graphic API RISC OS had the Mesa/OpenGL port (of the old Mesa drivers). So you mean it doesn’t exists in RISC OS as distributed with the OS itself?

But before all that we need to decode the video drivers as ARM doesn’t give any programmer information how to use their GPUs.

Which type of “decoding” do you mean?

Generally, at user-level graphic programs (on other OSes) uses libraries like Vulkan and OpenGL (Unix-like, Windows and macOS world), DirectX (Windows world only) or Metal (macOS world only). This libraries are both a Specification and an implementation of the specification.

Such libraries are (to put it in extremely simplistic terms) “hybrid” APIs (a bit like SharedCLib if you want) that offers user-space “front/end” as well as lower level “back/end” (please note: “all-in-one”) in order to accelerate the overall graphic processing.

In other words OpenGL (as an example) works as a “medium” between the data that you have processed in the CPU with your program and the GPU itself (so, to send data from the CPU to the GPU, in an extremely simplified description).

Once the data has reached the GPU it goes through some form of “rendering” pipeline. All GPUs more or less abstract the same “layers”. For example, in the case of a game, such layers are “Geometry, Vertex, Tessellation and Fragment” shaders which are all “programs” that exists in the GPU as firmware or blob (or whatever term you want to use). Obviously a GPU offers also registers, bulk memory for the data we are talking about and I/O channels.

Now, to make the story short, the OpenGL driver (of the example) can be a sort of open source form (which I am sorry to disappoint someone, but in that case it uses the OS primitives and so doesn’t really uses the HW acceleration offered by the GPU unless the manufacturer of such GPU as expressly allowed that, Rick is correct that certain things there are protected by patents) or it can be proprietary (aka designed by the GPU manufacturer) and to talk with OpenGL front/end specification (or even implement the entire OpenGL stack). In the case of proprietary (for example AMD, NVidia etc.) it does uses all the HW acceleration and you cannot implement it by yourself or “decode” it.

So, if you are referring to the Open Source form please have a look at Mesa for RISC OS (which is a 3D API that already exists for RISC OS). Someone claimed also a partial implementation of some Vulkan part, but I have no idea to which extent.

Link for the Khronos Library (aka “Vulkan”) port to RISC OS Raspberry Pi: https://www.riscosports.co.uk/raspberrypi/

Link for the most recent OpenGL/Mesa 3D API port to RISC OS: https://www.riscosports.co.uk/opengl/

If you instead are referring to the close source driver, then you as Cloverleaf Company (or RComp or RISC OS Developments for that matter) have to engage with the HW manufacturer and ask them to either build the driver for your OS or eventually have some info to implement some form of acceleration on their GPUs (but the latter usually ends up into minimal implementations that are capable of accelerating only 2D stacks like for example WIMP redrawing as practical example). 3D Graphics always end up in having to use their code for the shaders and pipeline control as described above.

If you look at the Khronos modules above you’ll find a big and clear Copyright notice in the zip file.

Anyway, apologies for the long comment, but I am honestly struggling to understand and I hope it’s ok to ask for clarifications.

@Rick Murray
A “Linux loader” that faked enough of a typical Linux kernel that a driver blob such as that may load, start up, and be used.

Emulate a Linux environment would be plan B. The advantage would be that it will be possible to easily adopt other chipsets with new GPUs. But probaly slower and significantly more memory hungry.

@Paolo Zaino
About 3D I mean that in RISCOS we don’t have native 3D SWI calls, only 2D vector calls.
OpenGL, Vulkan, Mesa are high level 3D libraries. What we need is the hardware access to the GPU.
It would be interesting how someone got it done to get some hardware GPU support for the Raspberry 3. Who was it?