RISC OS Direct live launch at SW Show

It’s on its website! Is it my fault? :)

First, that’s not how copyright works.
Second, the logical place to highlight an issue that might be a possible mistake is an email to the author, not a “hey guys, freebie!” on a public forum.

I never give the address.

You gave a massive hint as to where on the site, and, come on…
Quick poll: How many people here either know his URL or have it bookmarked?

Yes, but with SD cards, it will probably be an huge improvement in term of speed.

Speed of reading weighed against time decompressing (and shifting memory around as it would likely need temporary blocks in RMA).

I can imagine that something that loads entire files or GBPB’s big chunks may benefit.
On the other hand, something that does byte access and/or random access will likely suffer miserably.
Indeed, it may be that for random access, the OS has to either cache entire files or decompress it from the beginning each time to translate between the compressed data and where the pointer is supposed to be in the uncompressed data.

and posted a copy of a hacked and de-licenced copy

Mmm, I’m aware that a hacked de-dongled copy of the original DTP package was doing the rounds about a week after release; which prettymuch backs up my pet theory that complicated copy protection is a pain in the ass for legitimate users and essentially useless against pirates. A copy came my way so I loaded it, tried it, decided I still preferred Ovation ¹ and deleted it.

The generous response from CC was far more than I expected.

Having had a far worse response from a developer in the PC world ² back in the mid ’90s, which basically accused me of piracy for reporting that a keygen for a shareware product was being supplied by a shareware disc library, my general approach now is to just keep my mouth shut.

Replies to go to another topic as this is no longer announcing nor RISC OS Direct…

¹ Is it just me, or was the CC 3D icon stuff in RISC OS 2 NOT an improvement? Sure, RO2 looked crap, and the “icon background flickers a weird colour like cyan” method of highlight was laughably bad, but they pretty much sussed it for RISC OS 3 and made far improved icons and everything looked much better. CC products (using ABI) still looked rubbish.

² Goddamn American of the “sue everything in sight” variety; won’t have had a leg to stand on but it’s a bother I could have done without.

Been done. Computer Concepts CFS. It had a small amount of application on floppy discs where compressing stuff allowed it to be loaded more quickly, but it wasn’t so useful on harddiscs where space was plentiful and the on-the-fly compression added small delays.

The biggest problem with CFS was that it operated on a file-by-file basis instead of creating “archives” like ArcFS and Spark. This resulted in worse compression and more wasted space on floppies because of the minimum size every file occupied. So everyone used ArcFS until SparkFS with its superior ZIP deflation came along. I still remember recompressing stuff for the Acorn file area of a friend’s BBS because ZIP deflation was so much better.

That was not my impression and Andrew seemed to have the same impression.

And you’re both wrong. I spent several thousand of Euro to free things for the RISC OS community (including ABC). So I’ll not rip things now. But the fact to give it for free without saying it, is the reason why I say “I believe it would not be too difficult…”. And I believe I’m right.

But, of course, my capacity to invest (a lot of) money for RISC OS things is not obvious. So my apologies.

My suggestion to engineer a similar facility into the RO source which might be the same code or something similar. The phraseology I used was aimed mainly at Andrew – assuming he has time to devote to discussing such things with David.

I think the same.
It’s done.
Stay tuned.

Quick poll: How many people here either know his URL or have it bookmarked?

I do, and I’m not the cleverest RISC OS user here.
Jeffrey, David, You, are.

Speed of reading weighed against time decompressing (and shifting memory around as it would likely need temporary blocks in RMA).

SD VS A73@1.5 GHz.
There is no question here.

Replies to go to another topic as this is no longer announcing nor RISC OS Direct…

Perhaps yes. As we’ll perhaps have good news soon.

The biggest problem with CFS was that it operated on a file-by-file basis instead of creating “archives” like ArcFS and Spark. This resulted in worse compression and more wasted space on floppies because of the minimum size every file occupied.

I understand. Here, the idea is not to gain space, but to gain speed. The question is, if a file is 200 byte, but the sector 1 K, does it read 1K or 200 byte?

If it’s 200, we will see the difference. I transform thin clients in Windows 7 PC. And believe me, the NTFS compression boost the computer so much… just because old flash drives were crappy, and CPU power is here.

Anyway, you’re all right.
https://www.riscosopen.org/forum/forums/2/topics/15063

David F – I didn’t mean to have a go at you over the SparkFS thing, just that I thought the RISC OS Direct thread wasn’t the place for such discussions. It’s so easy to go off topic!

I do agree about compression benefiting SD-based systems though. It is something we’re likely to have to solve for Iris, because we’re seeing load times north of 20seconds on SD systems, of which more than half is “SD penalty” vs SATA drives. What I’m not sure of is whether this would be best built into the OS, or into SharedObjectManager which handles loading of shared libraries.

To be fair, David Pilling has offered to help with browser dev, but only on a casual basis as he has little free time. Perhaps this kind of optimisation might be something for us to discuss.

You, are.

Cough. No. I’m no Sprow or memo…

because we’re seeing load times north of 20seconds on SD systems

Ah, good point. Some programs require loading vast amounts of stuff.

What I’m not sure of is whether this would be best built into the OS, or into SharedObjectManager which handles loading of shared libraries.

It’s obvious – pick one:

• Solve the problem for one specific use case.
• Solve the problem for everyone.

Into the OS, no question. It’ll probably be a little harder making an API as opposed to adding an extension to SOM, however the next time something needs to load a large amount of data, the ability will be there.

Cough. No. I’m no Sprow or memo…

Auro-incorrect time?

Anyway, way better than the likes of me.

Yup. The joy of writing messages on a mobile phone. At least RISC OS doesn’t change what one writes to be what it thinks you meant…

David F – I didn’t mean to have a go at you over the SparkFS thing, just that I thought the RISC OS Direct thread wasn’t the place for such discussions. It’s so easy to go off topic!

That why I did set up a new thread for this.

Hello,
great initiative! And, although with a bit delay, I did my bit to help spreading this news and shared the video-tutorials on my blog that is also published on Apple News and re-shared on LinkedIn, hope this helps spreading it a bit more.

Hope this is ok, cheers and great job so far!