There are problems with PCI and PCI chipsets. Various press magazines have listed problems like card/interface incompatibility, timing problems, disk data corruption and (in the case of intel's i820 and i840 chipsets) random reboots/failure to boot.

These are not trivial problems, and the benefit we get is just two cards a 100 BaseT and (perhaps) some SCSI card someways down the road. The downside may be unstable systems, corruptions to disk data or general instability. Incidentally the Imago has no PCI has 100 Base-T and will have UDMA-66 (in which case UW SCSI is not noticeably faster) and a memory system faster than AGP x4 so what advantage PCI then ?

As Lee says given information it is possible to write drivers for PCI devices, but the problem is data is not always available, or is subject to NDA or licensing restrictions. No information-No Drivers that's they way of the world I am afraid.

For example is there a driver for Creatives Encore DVD card for Linux (NO) and if that's the case for PC's running a more common OS than RISC OS with legions of coders I can't imagine it happening on RiscOS either. How many graphics cards are there that run on the Apple PowerMac (which has PCI) very few, now if thats the case on quite commonly used hardware what chance of drivers for later cards on Acorn style machines.

In addition PCI also is not under our control, what happens when the world switches to PCI-X, will RISC OS machine manufacturers get the chipsets and information early enough to keep up with the PC competition - I think not ! Even if they did their smaller engineering staff numbers and budgets would retard development of RISC OS hardware running the new standard.

Its better to set your OWN standards at least then you pay no royalties to anyone, you set the highest standards (rather than just opt for a lowest common denominator) and you can take existing Acorn hardware manufacturers (such as Powertec and the like) with you, at least they are aware of your platform (are Creative, Adaptec or Matrox ?).

Suggestions for higher speed busses would include wider 64 or 128 bit busses and moderate clock rates (32MHz or above), multi-master with arbitration or possibly even asynchronous busses (so as the technology improves speeds can be upped transparently). Alternatively digital crossbar switching busses could be used (expensive though).

Whatever technology emerges there is no reason why a "bridge" circuit could not be added to allow (older) podule or PCI technology to be used as well as native stuff.

All I am saying is PCI is not the cure to all problems, it will introduce some headaches for Acorn software writers and will provide too few benefits to justify the increase in computer prices and problems with stability it may well raise.

Paolo: the new motherboards have had the new processors plugged in.

No actually there is old processors on the new boards, someone of us did see a new strongarm running? i am sure not also because INTAL didn't start a large production so till now it cost could be very hight on a commercial computers, till now i saw only trial boards ....

Simply speaking, won't this leave RISCOS Ltd with a fully 32bit OS of which they have to make suitable (maybe adding more things) for the desktop? Pace are showing increasing interest in RISCOS Ltd and I can tell you now that things are about to get underway again after this period of no-engineers status!

Imagine how much faster a 1ghz StrongARM will be compared to any PC! Especially if Millepede used them in Imago eventually. And why not? That sort of power is ideally suited to their market.

Here's to 1gig RiscPCs...

A 1Ghz StrongARM in a brand new RISC OS computer, RISC OS 5 ....

Come on RiscStation, take up the challenge! It would certainly add some punch to the range, and a high-end computer wouldn't necessarily damage RS Lite etc sales too much.

And while they're at it, a 1Ghz SA laptop please

Who will do that?

ROR

As for having no boards to support the new chip, the word "new" explains this. How can we have boards and an OS to support something that isn't yet released? Give it a little time. As I said, the RISC OS companies have no choice do they, unless they fancy going out of business.

Personally, I'm going to start saving the pennies now...

Conciseness required now.

'Yes' or 'No' - d'you reckon these chips will be in a RISC OS machine anytime soon?

(well, you wanted concise)

From memory I think there are supposed to be around 50 improvements including an improved network stack (it had better include DHCP) and, would you believe it, disk fixing software (hmmm).

However from a developers point of view I'm under the impression that it is supposed to support the 32bit API so people can start porting applications. This would hopefully ensure the transition to RISC OS 5 is relatively smooth for supported applications. Dunno what's planned for older apps, if anything at all. I guess the point of 4.5 is to ensure there is actually software that will run on version 5. It seems reasonable to me, although I can't see how they could justify charging another 120 quid for it. Then again I'm pretty sure it's supposed to be soft-loadable.

Seriously, XML support would be handy - I wanna start playing with WML and SVG under my fave OS, not this nasty Windows stuff!

But there's no need to write off the RiscPC (after all, it's still a good brandname) - a new motherboard could see SA2 in a RiscPC sometime.

Anyway, maybe we're all needlessly overspeculating here...

BTW, this thread appeared to have been closed; perhaps Tim should put a reason why it was closed (same as editing a post) as I still think there's life left in it

I thought it was just broken...

Re. Xscale, I plan to just <tonyblair> wait & see </tonyblair>

If some good stuff makes it to the market that's worth buying, I will buy it.

OK, so I'm just a wimp, but Paolo, can't you make just a little more use of the [RETURN] key in such long posts? Please?

ROR

There's a "close thread" option to make sure no-one can add to the discussion (at least if you have admin priveleges); I'm guessing someone must have hit it by mistake

Not me.

but luckily there's also an "undo" option

There is?

There's a "close thread" option to make sure no-one can add to the discussion (at least if you have admin priveleges); I'm guessing someone must have hit it by mistake

Not me.

I hope it wasn't me

In reply to Paolo's long (but always interesting) comments....

Mesa isn't the UNIX version of OpenGL, it's an OpenGL LIKE API. As far as I'm aware Mesa hasn't been tested for conformance agains the OpenGL standard. Then again with Silicon Graphics Open Sourcing as much of OpenGL as they can (they don't actually own all of it) there was a comment on their website about working with the Mesa team to create a unified open source version.

Also Mesa is huge. This is not a criticism of the people writing it and Dave Boddies port but I do wonder if we would be better off starting with a MiniGL driver like you get on the PC and expanding from there.

I also agree with Paolos stance on PCI. It may not be the greatest expansion system on the planet but there are an awful lot of cards available for it, and it isn't going away in a hurry. However judging by the way the market is growing, USB is something we definitely need and its good to see it. Can we now see the programmers interface please?

Putting RISC OS in Flash RAM makes sense (providing it can still be locked against virus attack). Wasn't this RISC OS Ltds original intention anyway? However discovering the processor and making the best use of it can be a lot of work. While it's neat in theory you will always be one iteration behind - even Microsofts Compilers don't support things like AMDs 3D Now yet. Perhaps we should just port TAOS

RISC OS as a server platform? At the very, very least we need proper memory protection before this can really be considered. Also, as someone who is discovering the hard way how much trickier it is to write networking code on RISC OS than Linux or Windows (due to lack of pre-emptive multitasking and multithreading) I'm not sure whether it's really suited for this. Yes you can hang off the Internet event but it requires a different approach to writing the code and, as I've said many times, the effort required can be too much. Unless there is a real requirement to move into server markets I would say leave Linux to slug it out with NT / 2k and look elsewhere.

[Edited by johnstlr at 10:09, 5/11/2000]

I agree with Annraoi that we shouldn't expect a raft of cheap PCI cards to be available and that developers will be producing drivers for a much smaller market. However this has to be offset by the fact that

a) PCI cards are MUCH cheaper than podules. Ok so the cost of developing drivers will offset this but paying over £100 for a 10Mb / Sec Ethernet podule is beyond justification. If it was 100Mb then I'd be more willing to consider it.

b) Because you don't need to design the hardware, just write the drivers, this in theory opens driver writing up to anyone with the time, knowledge and who can be bothered. Ok it might not be easy getting specifications for the cards out of manufacturers, but if you can show them that it will not cost them anything and they may sell more hardware they might be more forthcoming. Paolo has already demonstrated that he can write drivers with his ISDN driver but this is no good if the hardware isn't available to start with. As for the more complex cards yes this is a problem and I don't have an answer to it.

Onto Paolo - the CRs do help mate

I'm still not convinced about a RISC OS server system but then that's partially because of things that are still lacking in the OS. With memory protection it might be a possibility. It would be easier with pre-emptive multitasking and multithreading but I don't think we're going to see either of those (or at least not for a very long time).

No I don't think we need 14 different versions of RISC OS but you do end up with an OS that can run on the lowest common denominator rather than taking advantage of new features. Alternatively perhaps we need a reflective, open and adaptable operating system but I'm going to stop now before this turns into a lecture on reflective software

1) Like also Annraoi said other than the SIMD istruction there is the system bus (and at Operating system level it is very important) specially when you talk about the OMEGA and the two processors, i really don't know how they can use on one machine two processor with different technology, different voltage, different clock, different system bus and also the new SA use the FP like a plug-in so it need some particoular featuring for use it... we will see but i have a lot of doubts about this

2) The only way for resolve the 26 bits problem (for me) is a 26 bits satellite kernel for mask the old call traslating it at 32 bits (with the missing string part) like Windows do, but maybe i am in a wrong way...

3) The two different FP units will make a lot of problems on the future system because (my opinion) i think that is better to write an VFP module (Virtual Floatting Point Module) that will manage an interface between the Application and the hardware level (NSA FP, ARM10 FP, FPEmulator)

4) Pipeline etc... well with the new system bus how it will function (with also cache etc...) till the memory?

5) V5 and HEX yes they have both the same but the Operating system have to manage the hardware, i still think that things like DMA and system bus will make a lot of problems

6) About network card and video cards... i think that this hardware will take a lot of advantages from SIMD istruction and also IDE interface and SCSI, but also MIDI and AUDIO CARDS so are you sure that to not more time it will not be used? (and also MULTIMEDIA actual is a big trainer of the computer business)

7) CHIP SET (DON'T FORGET IT! :-) the chip set of NSA will be different from the CHIP SET of ARM10 this mean also different bios so the system MUST be "optimized" for two different platform like Linux or Windows are, also if the system will not use the FP or the SIMD istructions...

but we will see :-)

[Edited by Matrix at 08:53, 8/11/2000]

I must admit I am intrigued (excited even?) by ARMs Java Extensions. At the rate we're going this might be the only way in which we actually get Java. This is not a shot at Peter Naullis (of Chockcino fame) because I understand he is very busy and I can only guess at how complex the software is. However 2 yrs ago I was going to do my current work in Java on Phoebe. Now I'm on Windows and COM - sad innit (although admittedly that's partially because we had to drop Java support from the platform I'm using).

A 26 bits satellite kernel which just catches the illegal calls isn't applicable in our case. The reason it works on Windows is because all you are doing is catching calls to the Win32 API. However in our case the way some of the ARM code instructions are interpreted has changed. This isn't something that is easy to trap. Short of modifying the affected apps (so we can say goodbye to Artworks etc) emulation would appear to be the only solution.

Of course perhaps now everyone will start coding in C....oh hold on a minute the Norcroft compiler won't work on the new processors either. 8(

VFPE? A bit over the top eh? Surely all we need is to standardise the FP calls and write a module which translates the calls to the appropriate hardware.

But please don't call it a 26bits emulator because you all know that it will only mask the 26 bits old callings (the registry etc.. will be the same otherwise the processor are not compatible )

So i think (and also the wimp2 premptive multitask module demostrate in past) that is possible made like a "26bits old firmware" that will let the new processors "intepret" the old 26bits istructions but only in the "syntax" not useing a procedure for re-generate all the istruction in 32 bits.

For the FPE i mean exactly what Annoraoi said, we just have the module but RISC OS Ltd need to rewrite it for the new low level FPU that we will have...

For Java istructions.... well why not build the same as the SIMD istructions? so Lee the system will need to undestand what processor is on the board for emulate the right code and use the real code when it is present... well at this point come back on my post for the new system istallation and see that it is not so far from the future reality... (my opinion of course...)

1) I published the "driver" for ISDN modems like Zyxel TA 128 on the forum topics about ISDN... so just from now you can buy and ISDN modem and it will work with a RiscPC, for it configuration you need to use windows for use the original configuration program also if i am working arround a front-end ISDN driver for RISC OS... (this days i have to much work so ...)

2) if you use and ISDN (in dual mode) you can have till 112 kbps, actually ADSL talk arround 640 kbps but we have to see the most of the servers let it work like a bit more fater ISDN so for now "all is under control" for RISC OS

3) The future? well RISC OS is still under developing so it will have all the software necessary i am sure of this

For the USB etc... i agree with you, but internet drivers are not so protected it is also possible to make some ports or rewriteing from Linux so it will not be so difficult... (i hope eheheh )

for this reason i think that an "emulation" is not the best solution it will take a lot of processor resources and it will need a particoular new structure of the system because the old programs have to run in a complete "protected-mode" where them can not use nothing of the computer in a direct way...

I want remember that about the code also PCPro not emulate x86 code, it is only an "interface" between the 486 (or the 586) and the memory or peripherials, adressed by RISC OS and ARM processor.

The emulation concept in PCPro software is only about the HD Partition, that is a file, or about memory management etc... for standard peripherials like RS 232, PCPro let you use it directly, like with SCSI interfaces etc...

A Complete emulation , in my opinion, is not required and also not usefull; in that way we will not have easy tools for translate the software and also a bad "interactivity" by old applications with the new system, and old applications will not take a lot of benefits from the new hardware.

Like Lee said under C or C++ it will be "easy" this is the same also with a BBC Basic compiler (the future 32 bits compilers of course) but for the Assembly code it is different, and also we have to wait tools like the FPEmulator for see if it will support the new FP, more programs make calls to it so there is not only the 26 bits problem for translate on the new architecture the software.

[Edited by Matrix at 09:35, 13/11/2000]

i guess to combat the 26bit problem, wouldnt it be easier to emulate the 26bit processor on the Xscale proccessor (its not like there's much processor requirements anyway for much 26bit apps)

hmmmmm, i cant see Lemmings if emulated in 26bit mode bringing an XScale or ARM10 to its knees

but of course there's the irony of it all - if RiscOS was big enough then they would have happily made the XScale backwards compatable
, but now we're relying on these new technologies to make Risc OS go mainstream, and of course belong where it should