| |
Omega Update |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Richard Walker |
Message #88301, posted at 21:46, 5/2/2001 |
| Unregistered user
|
And this is completely MicroDigital's fault for not using off-the-shelf chips. They are facing similar problems to Acorn with IOMD and VIDC - and Millipede will probably face the same.
If only RISCOS Ltd., MicroDigital, RiscStation, Castle and Millipede had actually sat down together and planned how they would get RISC OS to support off-the-shelf equipment - i.e. what hardware and who pays for it - then this wouldn't be a problem.
Never mind, it makes my StrongARM Risc PC seem 'almost top of the range' for a bit longer! :-)
|
| |
 [ Log in to reply ] |
| |
|
Rob Kendrick |
Message #88302, posted at 16:14, 6/2/2001, in reply to message #88301 |
| Unregistered user
|
What off-the-shelf chips are there that are compatible with the IOMD and VIDC, apart from the IOMD and the VIDC? Perhaps you should spend the time and effort developing one so you can sell it to MD, Castle and RiskStation? |
| |
[ Log in to reply ] |
| |
|
Sendu Bala |
Message #88303, posted at 17:13, 6/2/2001, in reply to message #88302 |
| Unregistered user
|
Indeed. You can't blame MD for this if the problem really is as claimed. Blame ROL for a IOMD/VIDC dependent RISC OS.
Unless of course their custom chipset isn't related to RISC OS compatibility issues, in which case they're imbeciles ;) |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #88304, posted at 18:23, 6/2/2001, in reply to message #88303 |
| Unregistered user
|
As I said, the hardware manufacturers (like MicroDigital) should be working WITH RISCOS Ltd. to get a version of RISC OS which doesn't rely on these chips.
At the moment, it looks like the hadware manufacturers are happy to blame RISCOS Ltd., and make their own (inferior) hardware VIDC/IOMD compatible (like Omega), or use super-low-performance kit (7500FE in RS7500 boxes).
It's not good. :-(
|
| |
[ Log in to reply ] |
| |
|
Annraoi |
Message #88305, posted at 19:09, 6/2/2001, in reply to message #88304 |
| Unregistered user
|
Oddly enough VIDC/IOMD dependance is not the real problem. The problem is NOT UPDATING THE VIDC/IOMD at frequent enough intervals.
In fact RISC OS machines outperform for their clock rate considering (once higher bandwidth links are made to main RAM (SDRAM or faster) then performance will no longer be a problem.
MD can't be faulted for choosing to implement updated variants of IOMD and VIDC - its the quickest way of getting a NEW RISC OS computer on the market without having to wait for Hardware independance (I would suggest faster (but compatible) VIDCs are the way to go as ARM9 and 10 will have PowerVR built in for 3D anyway). |
| |
[ Log in to reply ] |
| |
|
cbcbcb |
Message #88306, posted at 00:15, 7/2/2001, in reply to message #88305 |
| Unregistered user
|
No, some manufacturers will build chips containing an ARM9 or ARM10 core, and also a PowerVR 3D accelerator, and probably a lot of other gubbins.
99% of ARM9 and ARM10 based chips will not have PowerVR. |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #88307, posted at 10:48, 7/2/2001, in reply to message #88306 |
| Unregistered user
|
The RISC OS VIDC/IOMD dependance *is* the problem. If it were not for that, it would be easy to use other hardware.
It isn't feasible to built IOMD/VIDC hardware any more, and it hasn't been since 95/96. It's just too expensive, and will always be inferior to what the big manufacturers come out with.
Oh, and as cbcbcb pointed out, an ARM9 or ARM10 won't have a PowerVR 3D chipset built in. Get real!
|
| |
[ Log in to reply ] |
| |
|
Sendu Bala |
Message #88308, posted at 08:46, 8/2/2001, in reply to message #88307 |
| Unregistered user
|
Get real? Someone will be producing ARM10s with PowerVR cores in them (or is that what you don't believe?), so I see no reason why MD wouldn't use these ones instead of normal ARM10s from elsewhere.
So as far as the computer buyers will be concerned, ARM10s _will_ have PowerVR cores. |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #88309, posted at 13:50, 8/2/2001, in reply to message #88308 |
| Unregistered user
|
Some OEMs will use embed the PowerVR, just like they embed other stuff. Do you think they will want to sell a couple of thousand chips to MicroDigital? I don't. Oh, and Acorn always used the 'vanilla' chips.
|
| |
[ Log in to reply ] |
| |
|
Michael Stubbs |
Message #88310, posted at 15:52, 8/2/2001, in reply to message #88309 |
| Unregistered user
|
The Acorn propriety chips are *not* a problem. Richard, you are full of you-know-what and, I suspect, do not know what you are talking about.
What is wrong with propriety hardware? With propriety hardware we can have superior speed, quality etc etc. Let's not forget that the hardware is just as important as RISC OS. It just needs updating, which is what, to a certain extent, MD and Millipede (and probably Castle) are doing.
The more hardware independence we get, the more drivers we need, the more like Windoze it is going to get. At the moment, we have no need for drivers for a video card - even podules do not require drivers, as they are onboard the cards anyway. |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #88311, posted at 18:14, 8/2/2001, in reply to message #88310 |
| Unregistered user
|
Michael,
'Non-standard' chips ARE a problem. Why do you think Phoebe was so expensive? Why was it not saved?
Also, MicroDigital, as clever as they may be, cannot produce hardware which is superior to that produced by the major manufacturers. Look at Simtec's CATS board - it's a stunning board, whch makes use of 'standard' chips. What a pity that RISC OS won't run on it.
I bet that if you compared the price of a CATS board to a MicroDigital Omega board, you would find a big difference.
Non-standard chips just mean paying MORE money for LESS performance.
|
| |
[ Log in to reply ] |
| |
|
Annraoi |
Message #88312, posted at 20:17, 8/2/2001, in reply to message #88311 |
| Unregistered user
|
In 1987 the standard of the PC world was the 386DX clocked at 33MHz and it was half the speed of the ARM2 clocked at 4MHz (as timed by PCW) now (i) which was the industry standard chip and (ii) which was faster. Later we had standard 386s that couldn't multiply, 486's that executed instructions out of order from their cache (oops) Pentiums that couldn't divide and PCI chipsets that randomly scrambled stuff on the way to/from your hard disk.
The Intel i840 chipset (a standard) and its associated MTH memory controller couldn't be made boot, the P-III 1.13GHz was withdrawn because it was unreliable, the P-4 1.4GHz is slower than chips clocked slower than it (including some P-III's).
Going with standards gets you BLAND that's all. The MD design and the Imago design both have some VIDC/IOMD like features in their custom circuits. The only problem with the VIDC and IOMD was their bandwidth had not been improved. This is changing, the Imago for example has a memory bandwidth of over 1.6GBytes/sec (better than current PCs) and it is basically using a VIDC/IOMD over a 100MHz 128 bit wide bus.
It is manifestly obvious that if you want variety and advantage you sometimes need to go off the beaten path - after all the standard may be a Ford Fiesta but I'd rather drive a Ferrari. |
| |
[ Log in to reply ] |
| |
|
Annraoi |
Message #88313, posted at 20:25, 8/2/2001, in reply to message #88312 |
| Unregistered user
|
Another thing is that Pace have stated they want to use PowerVR in their set-top boxes (basically RiscOS computers). ARM have licensed PowerVR for the ARM10 and 9 and have stated it will be included where licensees require it.
I am sure that ARM are going to push this technology big time and just because Acorn used "vanilla" chips does not mean the new RISC OS hardware manufacturers are bound to do them same does it ? |
| |
[ Log in to reply ] |
| |
|
Annraoi |
Message #88314, posted at 20:26, 8/2/2001, in reply to message #88313 |
| Unregistered user
|
Another thing is that Pace have stated they want to use PowerVR in their set-top boxes (basically RiscOS computers). ARM have licensed PowerVR for the ARM10 and 9 and have stated it will be included where licensees require it.
I am sure that ARM are going to push this technology big time and just because Acorn used "vanilla" chips does not mean the new RISC OS hardware manufacturers are bound to do the same does it ? |
| |
[ Log in to reply ] |
| |
|
mark quint |
Message #88315, posted at 22:28, 8/2/2001, in reply to message #88314 |
| Unregistered user
|
you notice that all the big screw-ups used are Intel's fault :)
how is it that the smaller companies that are constantly trying to be suppressed by Intel alway manage to get it right, but still not kick Intel off the spot?? :(
Ahh well, perhaps AMDs got something up their sleeve. :)
|
| |
[ Log in to reply ] |
| |
|
William Black |
Message #88316, posted at 01:04, 9/2/2001, in reply to message #88315 |
| Unregistered user
|
I have thought in the past that it would be rather good if the RISC OS hardware manufacturers used a chip manufactured by someone such as AMD or VIA out of sheer principle of not using Intel ;-)
However, if XScale is the best, so be it. Erm, I was going to say at least there would be no supply problems but then again, Intel can't keep PIIIs in good supply ;-) |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #88317, posted at 08:25, 9/2/2001, in reply to message #88316 |
| Unregistered user
|
Annraoi,
I'm not talking about processors. In fact, we could consider them for a moment, if you like... the ARM processors don't have anything like the raw computing power of 'proper' desktop processors, like the x86 or Alpha.
Despite that, I'm not suggesting that we should move away from ARM processors. I think they are quite cool, and RISC OS (and it's apps) are WAY too tied to the ARM anyway! :-)
Also, don't talk about bugs in hardware. It's perfectly normal. There are bugs most of the StrongARM chips which sit in Risc PCs, and there are bugs in the Risc PC motherboard (and/or SA card) itself. Oh, and remember the first generation PC card ASIC?
The problems with VIDC and IOMD are not simply down to lack of speed. Yes, it's a big problem, but so is the MASSIVE cost involved in designing and producing replacements. Oh, and not to mention the delays in manufacturing... do you know why Omega is late?
Where do you get those figures for Imago?
William,
As you say at the start of your post, it IS indeed a good idea to use mejor chips from people like VIA, ALI, Intel etc. I'm not suggesting using non-ARM processors... just use standard graphics controller cards, memory controllers, and I/O controllers. Simple.
Custom chips are making our systems more expensive and offer less performance.
|
| |
[ Log in to reply ] |
| |
|
Richard Possnett |
Message #88318, posted at 16:27, 9/2/2001, in reply to message #88317 |
| Unregistered user
|
And how, exactly, is a small company like ROL meant to fix the problem of RISC OS relying on custom chips?! Although the viewfinder appeared to be a partial fix, it still had bottlenecks.
Mr Walker, you are just being stupid. RISC OS is so heavily tied to unusual hardware that it would take too much in the way of resources to change it. |
| |
[ Log in to reply ] |
| |
|
Lee Johnston |
Message #88319, posted at 17:29, 9/2/2001, in reply to message #88318 |
| Unregistered user
|
I'm going to have to agree with Rich on some of this.
I agree that if RISC OS cannot at least be modified to support different hardware (custom or not) then it's dead in the water. How many people here think RISC OS will be able to exploit an ARM10 with integrated PowerVR? I'll bet it'd fall over straight away because there is no way that the PowerVR is directly compatible with the VIDC.
How this would be achieved is simple (in theory). Instead of tying the code to one graphics chip you create a driver interface offering an abstraction of the underlying graphics hardware. Hardware manufacturers (NOT Pace or RISC OS Ltd) then write drivers which implement this abstraction on their hardware. The result is that the hardware can be swapped with relatively hassle and without upsetting RISC OS or its applications. Creating such an abstraction does NOT result in a performance overhead that would be worth measuring. Finally on this point Windows and linux show the way to go in this area. The problem with Windows is that MS (as they have admitted) did not provide a rigid enough specification for writing drivers. This is a mistake RISC OS Ltd and Pace need to avoid.
The only bottlenecks I see with ViewFinder are down to the podule bus and not ViewFinder itself. If ViewFinder could sit on a fast or dedicated bus then I bet it would seriously fly. The fact that it works as well as it does demonstrates that it can't be a huge job to remove RISC OS' dependency on the VIDC.
However I don't agree that custom hardware is a bad thing provided that the costs and delays incurred by using it are outweighed by some other factor (significantly better performance in desktops, lower power consumption in mobile devices etc etc).
Finally a plea. The atmosphere on here is starting to get somewhat vitriolic. Can we please avoid personal attacks? Also if you're going to make a (potentially controversial) comment please back it up with reasons, technical or otherwise. I for one am beginning to get the impression that people are speculating wildly based on press releases that don't directly concern RISC OS without giving a thought as to what is / would be actually involved.
|
| |
[ Log in to reply ] |
| |
|
ams |
Message #88320, posted at 19:23, 9/2/2001, in reply to message #88319 |
| Unregistered user
|
Agreed there is no need for vitriol, after all we all want to see RISC OS and platforms that run it succeed - the issue is how is this to be acchieved.
In response to Richard Walkers query, the bus speed of the Imago is based on their published specification (namely 128 bits wide at 100MHz which equates to 1.6GBytes/sec (128 bits=16 Bytes; 16 Bytes x 100MHz = 1600MBytes/sec (around 1.6GBytes/sec)). They also state that they "hope" to have it run at 128MHz at release - that would translate at an even more impressive 2048MBytes/sec (2GBytes/sec). In fact either performance is AHEAD of most currently available PCs (ones with DDR can just match it 1.6GB/Sec figure but these are not widely available yet) and at least twice as fast as the Omega.
The ultimate problem with "hardware independance" is a cost in flat out performance and a worrying potential for incompatibility. The cost in converting RISC OS to 32 bit hardware independance is probably no less expensive than producing an up to date VIDC/IOMD replacement(s). All that changes is that RISC OS foot the bill rather than Castle/Millipede/RS et al. |
| |
[ Log in to reply ] |
| |
|
Marco |
Message #88321, posted at 22:37, 9/2/2001, in reply to message #88320 |
| Unregistered user
|
Hmm,
I wonder if modifying ROS is as easy as:
#ifdef _VIDC_
/* do something */
#elsif
/* do something else */
I guess not :-)
Hmm, but about efficiency of a system: the most efficiency you can get out of software and hardware combos is if you make _everything_ propriety.. which means your OS is written on the hardware.. that's the optimal choice for efficiency.. but the maintainability and life-span is completely different story.. if something changes.. it's a _big_ effort to modify the rest.
We can keep on speculating, but I guess it's all just wait-and-see. |
| |
[ Log in to reply ] |
| |
|
Lee Johnston |
Message #88322, posted at 12:04, 10/2/2001, in reply to message #88321 |
| Unregistered user
|
I don't understand this obsession with "ultimate" efficiency. We're not even getting it now. Only applications / games written in pure ARM assembler going directly to the hardware can hope achieve the maximum possible performance and I'll bet the few that are written like this don't achieve it. We're looking at 400Mhz+ (ARM10, XScale) processors in future so is it really worth worrying about the odd cycle or two here and there? If it is then RISC OS will forever be in the situation it's in now and applications will continue to take an age to appear. We can also throw away our C compilers while we're at it.
I agree with An's comments about potential incompatabilities but again that only happens because specifications aren't rigid enough. If hardware works to a complete specification there is no room for interpretation hence this shouldn't be a problem.
Finally Marcos comment on altering RISC OS. You shouldn't even need to conditionally compile the code. RISC OS shouldn't make assumptions about the underlying hardware beyond a defined specification. Then it just accesses all the drivers in a uniform way.
Right now though, despite various peoples misgivings, I just want to see (and buy) some new hardware. 8)
|
| |
[ Log in to reply ] |
| |
|
Richard James C. But |
Message #88323, posted at 12:25, 10/2/2001, in reply to message #88322 |
| Unregistered user
|
I have three definite sources that would indicate that RISC OS is going independent :
1. If anybody in the Acorn Community apart from me downloaded the 32-bit RO modules from riscos.com, they would of read the "32bitintro" file, it states :-
Also bear in mind that most future systems are unlikely to use IOMD/VIDC compatible peripherals. Use OS calls rather than attempting direct hardware access.
2. I asked Paul Middleton of ROL about RO4.5 and his answer was :-
There is no fixed date for future releases of RISC OS versions. This is primarily due to the very rapid changes that are occurring in chips and machines that are suitable for RISC OS use.
3. In 1996, Acorn decided to make a StrongARM RiscPC with a new version of RO. Acorn didn't make profit that year but still undertook the task of updating RiscOS. I don't know about 2000 for ROL but indications seem good for a profitable year.
Acorn new that some applications wouldn't work with the SA, but did it anyway. There now five years old and Castle are still happily selling SA RPC's. If Acorn hadn’t used the SA, we would still be using 610's and 710's 8-(
If RiscOS 5 is going to be 32-bit, ROL should dump the IOMD, MEMC and VIDC while totally re-writing RiscOS.
I understand that some apps will not work under a non-VIDC etc. system but some apps didn't work with the SA either.
I also know that developing a totally custom system is best, but the market and profits are not big enough to keep making new chips.
Windoze has drivers for everything and that what makes is so crap.
And finally, I read this in Computer Shopper, "The only thing that Microsoft will ever make that doesn’t suck is"<What do you think> , they say it should be "a vaccum cleaner" 8-)
|
| |
[ Log in to reply ] |
| |
|
Lee Johnston |
Message #88324, posted at 13:54, 10/2/2001, in reply to message #88323 |
| Unregistered user
|
What would totally rewriting RISC OS achieve? The effort involved in rewriting the kernel and all the support modules would be huge and the benefits would be what? Maybe it could be rewritten in a higher level language for ease of maintenance but this isn't what people appear to want because it'd be less efficient.
I don't see why having drivers for everything is what makes Windows crap. How many more times am I going to have to say this? A driver system adds relatively little overhead for the benefits that can be gained. If drivers are properly specified and the specification is adhered to then incompatabilities should not be a problem. The driver concept isn't the reason you get conflicts on Windows, it's the lack of a rigid specification for writing them. No one claims that the use of drivers in linux is a bad idea. Even RISC OS uses drivers. The difference is that they're part of the firmware of the podule cards as opposed to installed on the host machines hard disk. How many people have replaced RISC OS' keyboard driver I wonder. I bet Cerilicia and Stuart Tyrell at least provide alternative drivers to make their keyboards work.
Finally concerning computer shopppers comment, this is just rubbish. Ok so a lot of MS software is bad but if you actually get the chance to examine some of the ideas and even technology underlying their systems I think you'll be more than surprised. MS have a reputation which may well be justified but not everything that comes out of there is rubbish.
|
| |
[ Log in to reply ] |
| |
|
Richard James C. But |
Message #88325, posted at 18:14, 10/2/2001, in reply to message #88324 |
| Unregistered user
|
A few things though: -
1. To make RISC OS 32-Bit all ARM code will have to be re-wrote, or at least adjust the &8000 to &80000 and the removal of some R's from commands.
2. "Microsoft have a good reputation" ? . The only reason that Microsoft is so popular ( 90% ) is that IBM chose them for the original PC. ( Indeed, they also asked Gary Kidiall to make a version of CM/P for the PC but he was testing his plane at the time.
Also, all windows ( with the exception of 2000 and Whistler ) run on the old DOS kernel, the same kernel used back in 1981.
Anybody ever been bothered to actually examine Windows boot. It copies its files from the HDD to the VM ( also on the HDD ).
What was ment by the modules is that if RISC OS is totally independent, there will be drivers for everything ( making the whole system slower ).
"No one claims that the use of drivers in linux is a bad idea". What ?. USB drivers are in kernel 2.4 only and ,although Corel are trying, hardware support for Linux is moderate ( admittedly, only very old and very new hardware is not supported ).
If RISC OS was to be totally independent, it would be competing with Mac OS, Linux and Windoze. It wouldn't stand a chance.
Finally, I only mentioned the Computer Shopper bit just to see what the feedback would be, appreciated. |
| |
[ Log in to reply ] |
| |
|
Richard James C. But |
Message #88326, posted at 18:16, 10/2/2001, in reply to message #88325 |
| Unregistered user
|
This sould be at the top of my last posting :-
As Lee pointed out, I forgot that this is my understanding and opinion only.
|
| |
[ Log in to reply ] |
| |
|
Lee Johnston |
Message #88327, posted at 20:05, 10/2/2001, in reply to message #88326 |
| Unregistered user
|
Ok, my understanding on the situation is
1) Not true. For the most part the problems are to do with function calls; specifically the way flags are preserved and returned across function calls in 26bit mode is not the same in 32bit mode. AIUI what this effectively means is that almost all ARM code will run but you can no longer rely on flags being preserved. The easy way of solving this problem is for Pace to say "function calls and SWIs no longer preserve the flags". Ok this breaks an awful lot of software but it would basically give us 32 bit RISC OS. The fact is that pretty much all ARM code software is going to break anyway as the flags are no longer in the program counter in 32 bit mode so Pace may just decide to do this.
2) I never said MS had a good reputation. I said that perhaps they had a reputation they deserved (seems to be a bad one from my viewpoint) but you cannot deny that some really hot technology has come out of that place. Maybe Joe Public doesn't get to see it but there is stuff that RISC OS users and developers can only dream about, some of which could really give winCE an edge, and, let's face it, winCE is directly competing in potential RISC OS markets.
BTW NT isn't based on the old 9x kernel either. 2000 and whistler are based on the NT kernel.
3) Linux and drivers. If linux didn't support hardware abstractions and drivers it wouldn't run on all those video cards. USB is something new. Hardware support may be moderate but it's distinctly better than RISC OS and companies are waking up to it as being a viable platform. This couldn't happen without proper driver abstractions.
Do people actually realise what a driver is? In RISC OS it probably isn't going to be much more than a vector of addresses which calls are directed through. The trick is to specify the driver interface at a level that is powerful enough so you don't have to make lots of little calls while still retaining a level of flexibility.
Imagine for a moment ViewFinder on a fast bus and the RISC OS sprite calls redirected through a vector to take advantage of the hardware blitting. The speed increase would be immense. For the performance overhead of a few cycles of going through a vector you've gained a plotting performance increase of some significant factor. While this could be done with an OS tied to custom chips you lose so much. At the very least new versions of the custom chips either have to be backwards compatible (look where that's got Intel with the x86 architecture) or you have to upgrade your OS to get access to the new chips. As I've said elsewhere, if the benefits outweigh the drawbacks then custom chips are great. Sadly this doesn't appear to be the case. Imago has incredible performance but PC cards will catch up and also offer extras like 2D/3D acceleration (which I believe Imago won't offer).
RISC OS is never going to be hardware dependent like other OS' because it will always be tied to the ARM processor. It isn't trying to compete with Win2k or linux or MacOS (although it would be nice). However Pace have their eye on STBs and possibly embedded markets. There is a high level of hardware heterogeneity in these fields. RISC OS IS going to have to compete against the likes of Epoc and winCE, both of which trounce it completely in terms of hardware support. Neither of them are particularly big or slow either.
Finally consider the question that if all the hardware is based around one set of custom chips why do we need three hardware manufacturers? They have to differentiate their products somehow but if they've all got the same video, sound and memory performance how will they do that?
|
| |
[ Log in to reply ] |
| |
|
Richard James C. But |
Message #88328, posted at 09:58, 11/2/2001, in reply to message #88327 |
| Unregistered user
|
Again, I must state that this only my view of events.
Thanks very much for replying to my postings Lee.
The Acorn community has to move forward, we are trailing PC's currently in speed and up-to-date equipment.
I believe that the RiscPC system does have a good future ahead but eventually ( like ever other computer ) it will become redundant because of the motherboard running at only 16Mhz and even if the ordinary people ever get a chance to install the Imago into their machines, There would be more problems with PSU's and others.
This is where the future starts.
I believe that the 7500FPE and the SA110 are redundant. ( a lot wouldn't though ).
I'm not asking for a move to PowerPC or x86 CPU's but a move to ARM10 or even the XScale. ( I would rather the ARM10 ).
I also believe that producing portables with the 7500FPE is a good move because if you want raw power, use your desktop but the 7500 is fully capable of running a RISC OS machine ; and if the burden of graphics was to me replaced my MD's Lightning, the performance would be quiet fast.
Ever though people are whaling about compatibility, RISC OS needs to move forward, fast.
I think that off the shelf chips to replace the VIDC,MEMC and IOMD should be used and so what if some apps won't work without a VIDC, they can change.
I know some of that was controversial and would welcome discussions ( but not arguments, please ) on any of it. |
| |
[ Log in to reply ] |
| |
|
Annraoi |
Message #88329, posted at 16:10, 11/2/2001, in reply to message #88328 |
| Unregistered user
|
What off the shelf chips ?
Intels i840 chipset with the dud MTH perhaps ?
Let's get real folks there is a lot of hardware dependance built into RISC OS, to fish it out will take a lot of time (note time=money). I'd argue that it might cost more to fish out the VIDC and IOMD code and replace it with a more "abstracted" model than to simply redesign the VIDC and IOMD in VHDL and then update the hardware design as needed to use faster memory over wider busses which is what's really required.
Small runs of hardware implemented on FPGA (programmable gate array chips) can be done once the formal spec is available (in VHDL or other hardware description language) all that is needed is for machine manufacturers to agree to the precise spec.
Some degree of backward compatibility will be required with existing code (probably with a speed penalty) will be needed as many of the software manufacturers will not update their code for compatibility with a new architecture (never mind 32 bit). Newer 32 bit code can run faster because it does not require "helper" code to run.
As to 2D and 3D acceleration MOST CODE can run around 4 times faster if you just take out the memory bandwidth limits currently in place (and that's with the EXISTING StrongARM), if you use the double bus width and near double clock speed of ARM10/xScale then further improvements can be made. The beauty is all your existing code continues to work (or with very minor changes).
Manufacturers can differentiate their products by adding a "superset" of additional functions, such as the AV bus (on the Imago), nothing in what I've said precludes added value features all it does is specify the MINIMUM that all hardware must supply. Any "fiddling" with the basic core specification runs the risk of incompatibilities of the sort that plague the PC and precisely the sort of thing we can do without
|
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #88330, posted at 08:46, 12/2/2001, in reply to message #88329 |
| Unregistered user
|
Annraoi,
Don't mention the i840 - that's just silly. And mentioning hardware bugs is just daft - Acorn machines have also had hardware bugs, you know, it's pefectly normal.
For a superb use of off-the-shelf chips, please see http://www.simtec.co.uk and click 'SA110 evaluation board'. This is CATS. It's basically something that looks like a typical PC motherboard, but takes an ARM processor (instead of an x86).
CATS has been around since, erm, 1997, I think. It's got a specification about equal to (better than?) Phoebe would have had, and is AVAILABLE NOW. It has been running NetBSD for ages.
Guess where the problem is? RISC OS. It won't work on such hardware.
I would like to see RISC OS with a good driver model, and then Simtec could get the CATS hardware supported, and we might see 'Evolution'...
As for 2D/3D acceleration - Omega will have nothing like the graphics speed of the curent mid/high-end AGP solutions. What is your solution to that?
|
| |
[ Log in to reply ] |
| |
| Pages (2): 1
> >|
|
