fylfot (+1.6)
14/7/04 11:09PM |
Very good news indeed.
Everyone deserves a hug, I think. |
imj 
14/7/04 11:14PM |
Wohoo! |
jonesd98
14/7/04 11:23PM |
w00t! |
Revin Kevin
15/7/04 1:03AM |
Good news indeed by the looks of things. |
cynic (+1.6)
15/7/04 7:53AM |
Is this ROL's version of 'sense' or Castle's?
Sense would not be complete capitulation by either side but a carefully negotiated settlement that shares the IPR, the work and the revenue in both directions.
Time will tell. |
bucksboy
15/7/04 8:05AM |
I'm glad ROL are carrying on: I use Select and it's a good product. But let's not forget that the Iyonix is the only new native hardware we've seen in significant quantities since the collapse of Acorn, and Castle is the only company in the market that appears to have both the resources and a plan for future development. Let's hope they're getting something out of this settlement as well.
George |
martin (+1.6)
15/7/04 8:35AM |
Well, it is to Castle's credit (as the player seeming to be calling the shots) if they have listened in part to what virtually everyone is telling them regarding the catastrophic effect this dispute would have if it dragged on.
I find myself agreeing with the sentiments expressed by cynic and bucksboy. We need a firm fix on the issues that is to all parties liking and not something that's going to see them flaring up again in the future.
If all of this does end up with a "house in order" then maybe RISC OS can yet emerge from this dispute all the stronger. |
hexa0503 (+1.6)
15/7/04 8:35AM |
Hmm I think if I were running ROL I would have had written already an Iyonix-ready version of Select for the time when there may be agreement with Castle over sharing the income from it. But you do need agreement on sharing core software. But maybe the players do not think in long-term plans. Or Castle maybe have their own "Select". Speculation in the absence of fact. |
egel (+1.6)
15/7/04 9:33AM |
And MicroDigital is the (only) company in the market that didn't panic. At least they have shown that they can control their nerves. Maybe their plan was to be the third dog which gets the bone. Let's hope they're getting something out of this settlement as well. |
imj
15/7/04 10:20AM |
In reply to martin:
"Castle's credit" ... "have listened". I don't see it that way. ROL had continually disputed the legality of CTL's claims. Perhaps CTL just realised they were plain wrong. Take a moment to see it from both ways. This whole debacle has been a total mess and a waste of a huge pot of cash, time, effort, patience and goodwill by all parties unfortunately. Thank goodness there appears to be some light down the tunnel and we can get on with building things for the future. AIUI, Huge lumps of Select are "32bit ready" and with the Merlin request list looking just like the Select feature list, it does make sense for Castle to work with ROL and get Select on Iyonix - some of those Select features such as realtime IFR plotting and alphablending would really be something on the Iyonix horsepower. |
speccyverse
15/7/04 12:55PM |
reply to egel:
RiscStation did not panic either. |
hzn
15/7/04 12:56PM |
Good news, indeed - the good news being that things seem to have been agreed upon/settled.
To martin (8:35 AM):
As far as I understood Castle they didn't intend to kill ROL but wanted their IPR honoured correctly and a sensible agreement with ROL. Shutting down ROL was, as far as I understood (yes, I repeat myself but on purpose!) was the last solution if nothing else would work.
In reply to hexa0503:
Who wants an IYONIX ready Select? That would be no good idea since Castle has a 32 bit RISC OS kernel and the much needed hardware abstration which they will stick to for their desktop and embedded systems so that there is no need to have another kernel and with that keep the two-RISC OSses-situation alive. Adapting the Select features to RISC OS 5 is something worth doing though.
In reply to egel:
Castle blamed RISC OS to violaite their license and wanted those parts rectified. Perhaps the products of MicroDigital were covered by that license, that is were and are authorised products. That would explain why MicroDigital didn't have to panic. Perhaps they can now get the 32 bit RISC OS 5 - Castle did state that they wanted VirtualAcorn and MicroDigital to move to RISC OS 5.
To martin (10:20AM):
Indeed. It does make sende to get Select features on the IYONIX.
|
imj
15/7/04 1:07PM |
In reply to hzn:
What on earth is the point of trying to mangle RISC OS 5 in to Virtual Acorn? Vast lumps (I'd suggest "most") of the emulator would need to be rewritten to make it look like and Iyonix, for what benefit? RISC OS 5 doesn't bring ANYTHING to the table for use on an emulator, and is undeniably less featured than RISC OS Adjust. CTL only wanted RO5 on there because it was theirs and they'd then get a revenue stream and could control it, not because it was technically a better idea. |
blahsnr
15/7/04 1:13PM |
hzn
Cool! We'll soon have the opportunity to pay for Select 'improvements' a second time  |
nunfetishist
15/7/04 1:20PM |
speccyverse: When was the last time RiscStation sold anything, though? Have you seen how recently their website was updated? |
monkeyson
15/7/04 1:25PM |
"What on earth is the point of trying to mangle RISC OS 5 in to Virtual Acorn? Vast lumps (I'd suggest "most") of the emulator would need to be rewritten to make it look like and Iyonix, for what benefit?"
I'd guess they would aim for "Virtual RISC OS" rather than "Virtual Iyonix" - one of the advantages of RO5 is that it isn't so constrained by the hardware it expects. So you could have an emulator HAL, and rather than waste processor time emulating the old video and memory chips you could interface with the host OS and hardware more directly. |
AMS
15/7/04 1:44PM |
In reply to Monkeyson:
Why does the thought of Castle becoming a Windows Re-seller feel as bad as when ROL did it ? The only marginal (and I mean *marginal*) advantage to Castle doing it is that some of that revenue might help support real modern ARM based RISC OS hardware (something that ROL's solid support of Microsoft Windows and emulation does not).
As to Castle actually doing it there is no practical reason why they couldn't, the nVIDIA drivers built into RO5 would probably map down well onto a similarly equipped PC and the HAL might (marginally) make it easier to port to VA. Also the Iyonix hardware is more like a PC than an emulated RiscPC is (an RO5 based VA might perform better). That having been said it doesn't much matter who supplies the nails that are hammered into RISC OS's coffin does it ?
Kind Regards
Annraoi |
drjones69
15/7/04 1:54PM |
I'm probably gonna get modded down to buggery for this, but...
But how is this a good result?? Do I (we?) now have the chance to watch ROL stumble around for another 5 years, developing at snails pace and watching the rest of the IT world race every further ahead - this could have a been the turning point - Castle in control, ROL reeling (I should take up tabloid journalism!) - but everyone seems to have stepped back from the brink to return a tried and trusted status quo. Hopefully the contents of the recent meetings when available will clear up what has actually happened when they're available.
Still at least the (only, imho) good thing is that companies licensing RISC OS are back in action.
Regards,
Ryan |
JWCR
15/7/04 2:23PM |
In reply to drjones69:
ROL needs to be kept going as a legal entity, so that the AMS can continue to sell legally licenced products until something better comes along. For instance Virtual Iyonix or RISC OS5 for the Omega, or even RISC OS 5.1 with all the useful features of Select ported to it. |
bucksboy (+1.6)
15/7/04 2:41PM |
In reply to drjones69:
I don't agree that 'Castle in control' would necessarily have been a desirable outcome: it would have been back to Acorn times under a different badge, and we all know how that ended up. Diversity of opinion, ideas and development paths is good for the platform IMO. ROL, APDL, STD, R-Comp and others have made many valuable contributions and will go on doing so, I hope.
George
George |
hzn
15/7/04 2:42PM |
In reply to imj:
One of the interesting benefits of RISC OS 5 is the HAL. With that a more direct and thus better screen driver can surely be written and the emulation of other old Acorn hardware can be removed which can probably make the virtual machine more efficient.
As for RISC OS 5 being less featured as you even write "undeniably": I'm not sure about that. Select has the odd more visible feature but RISC OS 5 has features Select does not offer.
In reply to drjones99:
That's why I wrote "Good news, indeed - the good news being that things seem to have been agreed upon/settled." |
imj
15/7/04 3:13PM |
CTL's idea of "HAL" is ridiculously overrated. For "HAL" read "PCI Interface". It's not a whole HAL for the OS. Way, way from it. There's a whole shedload of ways to accelerate RISC OS anyway - a simple hook in to the horizontal line-draw routine primitive (which I believe ViewFinder may do??) will accelerate all PLOT and Draw module operations massively. Same for sprites - you just write a new module that provides the same API but talks to your accelerated hardware. Don't underestimate how modular RISC OS already is in many areas!  |
not_ginger_matt
15/7/04 4:27PM |
Accelerating sprites is a very bad example, as ViewFinder shows with what it can accelerate. Because the sprite colour depth and the screen colour depth do not need to match, and similarly for the palette, it is very unlikely that any graphics card will provide quite what RISC OS would need.
As for optimising the horizontal line drawing code via the graphics card, this is also unlikely to yield any optimisation - in fact it would probably degrade performance due to the overhead of actually calling the graphics card for each scanline of a shape. Rectangle fills and copies, however, are a totally different story.
Personally, I'd like to see the current RISC OS sprite format deprecated and a replacement implemented that removes a lot of the complications that the current format allows (dropping palettes, aspect ratios and different colour depths would simplify things a lot). Let's face it, if we had a nice compressed format that was decompressed upon loading you'd only lose memory when loaded, you could make it allow more than 12 characters in the name (which would make things better for applications that use long filenames) and you could have an arbituary format specifically designed to allow graphics cards to accellerate them.
Unfortunately, dropping palettes and screen mode information would break a lot of code that outputs to sprite. Not to mention the fact that the ability of the OS to draw things to screen any quicker is a lot less important to me than OS development on threading, pre-emptive multitasking or even just the ability to have native alpha-blended sprites on anything other than RISC OS Select so it can actually be used by application writers.
Whilst clever code is good, code that gets used is better. |
JGZimmerle
15/7/04 4:36PM |
Thats why MD chose to develop their own GPU to tailor the acceleration functions to RISC OS. |
thesnark
15/7/04 5:14PM |
In reply to not_ginger_matt:
you appear to be advocating a more primative sprite format simply to pander to what current graphics cards can accelerate, something that I find quite extraordinary. The OpenGL architecture review board has not (and will never) decide to drop those API features that are less often accelerated by graphics cards. To take another analogy I suppose you think that complex maths operations not directly supported by ARM's FPA should be dropped from the instruction set? |
hubersn
15/7/04 5:15PM |
Is this specifically tailored graphics acceleration available right after the release of USB capability which shortly follows the XScale/ARMTwister duo which in turn is only slightly delayed because of the Ethernet and RAM problems and the development of the spectacular Lynx Internet Suite? |
thesnark
15/7/04 5:31PM |
In reply to imj:
Castle's thinking behind the current thinness of the HAL is set out quite clearly in this document:
http://www.iyonix.com/32bit/HAL.shtml
This document fails to support your idea of the HAL as a "PCI interface", being mostly concerned with functionality formerly tied to IOMD. The real PCI interface in RISC OS 5 is elsewhere, as I'm sure you know. Note also the sentence beginning "The bulk of device driver implementation remains in RISC OS modules". Clearly it was not designed as "a whole HAL for the OS", and with good reason.
In short, the engineers behind RISC OS 5 have clearly put a lot of thought into the design of the HAL and I suspect your criticism of it to be founded more upon your low opinion of Castle than anything else. |
imj
15/7/04 6:46PM |
not_ginger_matt> You wholly underestimate the reality of the situation. Timings have BEEN DONE which show just what a whopping acceleration you get from changing the line draw function. As for comparing the bits of sprites stuff that JK bothered to support with ViewFinder, that's just silly. He was restricted to what would be worth pushing over the podule bus. You're not thinking straight in the slightest. |
thesnark
15/7/04 7:31PM |
In reply to imj:
In retrospect I see that you may have meant
something along the lines of 'People ridiculously
overrate CTL's idea of "HAL" ' - which would
make more sense in the context of your reply to
hzn than the presence of a limited HAL being an
intrinsically bad idea in itself. I do agree
that people commonly underestimate the
capacity for hardware independence already
present in the design of RISC OS. |
| 1 comment(s) are below your moderation threshold. Login to view them. |
| Use the forum for more comments on this article |
"Yes, RISCOS Ltd is most definitely continuing to exist," confirmed Paul Middleton, 