Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

New 800MHz XScale powered processor available

By Chris Williams. Published: 16th Sep 2003, 19:21:53 | Permalink | Printable

IOP331 or IOP315 in Iyonix mark II?

Intel appear to have recently sneaked out a couple of new and interesting XScale powered processors in their IOP range. The processor currently employed in the Castle Iyonix is the IOP321.

The IOP331 has a processor core speed of 800MHz, supports 133MHz 64bit PCI and supports up to 2GB of DDR RAM. The IOP331 is very similar to the Iyonix's IOP321 and is said to be "code compatible" with the IOP321. This means a 32bit RISC OS and third party software need no changes to run on the IOP331, however the pinout of the chip will most probably be different.

IOP315 chipThe IOP315 is more modest with a core processor speed of 733MHz, 133MHz 64bit PCI support and support for up to 12GB of dual ported 200MHz DDR RAM. The IOP315 is actually a two chip combination, bringing together the 80200 and 80314.

The two new chips do seem to show that Intel is still interested in XScale powered processors and enjoys touting the low power nature of the chips and the ARM compatibility. It also shows the range slowly creeping towards the 1GHz boundary which is what we all dearly want.


Intel IOP range
Possible ARM cores for RISC OS
What's an XScale? Thanks to Steffen Huber for first spotting the new devices

Previous: RISC OS mailing lists paralyzed
Next: Midlands show venue destroyed


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Good news for Castle for future developments then. -- Bletchley, Milton Keynes

 is a RISC OS Usersa110 on 16/9/03 7:26PM
[ Reply | Permalink | Report ]

Looks like 800MHz Iyonix might be available for the machine's first birthday. Depends on how quickly CTL can get their order processed. -- Spriteman.

 is a RISC OS UserSpriteman on 16/9/03 7:35PM
[ Reply | Permalink | Report ]

Dare I say it: Could Castle use a processor bus so you can install any XScale processor that's code compatible in the slot? I know this is remarkabley like the RPC. I'm sure Castle could avoid bottle necks and would possibly make any furture Iyonix machines easily upgradable to a 1GHz+ processor, if it ever becomes available. -- Smiler - :D Alex Melhuish

 is a RISC OS UserSmiler on 16/9/03 7:41PM
[ Reply | Permalink | Report ]

Very good news indeed.

The code compatibility is important, although that does not imply the design is pin compatible (so some re-arrangements on the Motherboard might be required).

Hang on it's got freaking 333MHz or 400MHz DDR Ram support (gulp), and DUAL ported at that.

Well spotted Steffen (and nicely written Chris).

Yes it does seem to give Castle options for future developments alright...

-- Annraoi McShane,

 is a RISC OS UserAMS on 16/9/03 7:48PM
[ Reply | Permalink | Report ]

I really do wish that Castle had adopted some sort of Slot like CPU (like the RPC) in the Iyonix. That would have easily allowed upgrades (CPU upgrades) to the machine regardless of the pin-out of the chip.

I wonder how long it will take this development to filter down to actual machines?

 is a RISC OS UserThe Doctor on 16/9/03 10:20PM
[ Reply | Permalink | Report ]

And would have added considerably to the price and the time to market.

-- Peter, drobe.co.uk

 is a RISC OS Usermrchocky on 16/9/03 10:26PM
[ Reply | Permalink | Report ]

I wouldn't have thought this could be made as an upgrade (unless they use some sort of pin adaptor a la 586 upgrades) but possibly a new machine or mobo swap-out?

Doesn't the Omega have faster RAM than the Iyonix or something? I guess this could bridge that gap.....

-- C'mon, mod me down, PUNK!

 is a RISC OS Usersimo on 16/9/03 10:53PM
[ Reply | Permalink | Report ]

The Omega uses slower RAM than the Iyonix (133 MHz SDRAM compared to 200 MHz DDR-RAM), and it already has problems with its Unified Memory Architecture (processor and video battle for the bandwidth).

I made a SparkFS compression benchmark where the Omega in 1600x1200 (TrueColour) was 15% slower than in 640x400 (16 colours). And this is with a comparatively bandwidth saving StrongARM, which can only consume 66 MB/s (from around 800 MB/s real world bandwith on the Omega). Now consider a bandwidth hungry modern ARM processor inside the Omega.

Full Iyonix vs. Omega details along with real world benchmarks on my website soon.


 is a RISC OS Userhubersn on 16/9/03 11:24PM
[ Reply | Permalink | Report ]

Talk about a possible "CPU slot" is really not sensible if you look at the facts.

The new IOP331 has a PCI bridge on chip, which means the PCI bridge of the Iyonix could be omitted. IOP331 does not only support DDR400 RAM, it *needs* it (at least the 800 MHz variant if I read the docs correctly) - Iyonix-used RAM would be no longer compatible.

The local bus which IIRC is used for the podule slots in the Iyonix has changed considerably.

The pinout is totally different. The necessary surroundings including the bootstrapping from the OS would need to be different.

All in all, in the fast moving world of non-pin compatible ARM variants, it is no longer sensible to produce something like an "open processor bus". Designing a new motherboard is a lot easier than figuring out a scalable, processor independant bus protocol. You would need to abstract so much that it would take an infinite amount of time to get it right.

Anyway, it is interesting to see that the 80200 (which was planned to be used in the Omega) seems to be a dead end, and Intel concentrates on highly integrated devices for their IO processor stuff.


 is a RISC OS Userhubersn on 16/9/03 11:32PM
[ Reply | Permalink | Report ]

Thanks for that information Steffen, I see your points. Looking forward to seeing the bench tests of both machines as well. Cheers!

 is a RISC OS UserThe Doctor on 17/9/03 9:20AM
[ Reply | Permalink | Report ]

This is very interesting. But look at the power consumption: "Typical power consumption of 7.5 watts (500 MHz)" thats massive! The StrongARM draws 0.9W at 200Mhz. Clearly Intel is doing what it likes to do and ramping up the power drain. Actually thats a little unfair, apparently the SA only takes 0.3W at 160Mhz, so clearly there is not a linear relationship. Maybe in a few years we'll have ARMs drawing hundreds of Watts, like the nascent pentiums.

I'm also a bit confused by this: Local Bus Width: Intel® IOP331 I/O Processor Chipset: 8/16 Bits (66 MHz) Intel® IOP321 I/O Processor Chipset: 32 Bits (up to 100 MHz)

What is this local bus? Whatever it is, it seems to be slower and narrower than the current Iyonix

 is a RISC OS UserLoris on 17/9/03 9:23AM
[ Reply | Permalink | Report ]

The IOP's local bus is an additional method to connect things to the processor. In contrast to PCI, this is a "generic" bus, which has advantages if you want to connect non-PCI stuff. I am not sure why Intel have changed the specification for that local bus so dramatically, but 16bits/66 MHz still provides more than enough bandwidth to cater for podules.

As I said before, IIRC that local bus is used in the Iyonix for the podule slots. I could be wrong however, my TRM has not been delivered yet.

Considering the power consumption: keep in mind that the IOP331 does a lot more than a StrongARM. It contains a complete PCI bridge, a DDR RAM controller, caches and buffers for PCI interaction...it is a complete "system on a chip", while the StrongARM was comparably simple and contains only the processor.


 is a RISC OS Userhubersn on 17/9/03 10:21AM
[ Reply | Permalink | Report ]

My comment about the maximum RAM bandwidth used by the StrongARM is obviously wrong. The StrongARM (at least the 110 variant used in Risc PCs and the Omega) has an external bus of 66 MHz and 32bit, leading to a maximum bandwidth consumption of 264 MB/s. The XScale 80200 processor (planned to use for the Omega) has an external bus of 100 MHz and 64bit, i.e. max. 800 MB/s.


 is a RISC OS Userhubersn on 17/9/03 10:31AM
[ Reply | Permalink | Report ]

I think that everyone seems to have forgotten that Castle stated that the processor would be on the MB, because by the time another Processor would be out, most of the board would need replacing to use all of the features, this would also mean that Risc OS would not suffer from the 10 year wait from the lauch of the RiscPC to get a newer better architechture

 is a RISC OS Userem2ac on 17/9/03 1:50PM
[ Reply | Permalink | Report ]

So will this make it into the Omega as well? -- Andrew Harmsworth, Cambridge. www.gcse.com owner and author

 is a RISC OS Userharmsy on 17/9/03 4:45PM
[ Reply | Permalink | Report ]

As always with the Omega - anything is possible.

Whether anything happens ... well that's another matter. -- Spriteman.

 is a RISC OS UserSpriteman on 17/9/03 5:37PM
[ Reply | Permalink | Report ]

Spriteman> It burns fibble's eyes

To be fair I don't know how MD *could* be expected to allow for something like IOP331. Their xScale expansion slot will no doubt have allowed for an ARM style processor and its range of data/address and control signals. IOP331 goes beyond that in that it provides a PCI bridge, DDR RAM controller, 8/16bit local bus and so on.

Then there's the software aspect, if the Omega is using the 331's memory controller and PCI bridge then (inevitably) RISC OS 4.XX (which is not hardware abstracted) would need to be sizeably altered (remember the MD systems intent is to make it's hardware look like a RPC to RISC OS so that RISC OS can work with it).

So I'd say the existing Omega motherboard wouldn't support it and would need to be replaced (FPGA's can't work around the abscence of 331 required pads or tracks on the motherboard !!!!). And then there's RISC OS 4.XX/Select which won't hack it either.

-- Annraoi

 is a RISC OS UserAMS on 17/9/03 6:48PM
[ Reply | Permalink | Report ]

In reply to AMS:

TBH I don't know what I'm talking about here, but that hasn't stopped anyone else. So, here goes:

I doubt the Omega /needs/ any of the extra functions the IOP331 or similar provide. After all, it is currently using a plain, old StrongARM processor rather than any system-a-chip doohicky. I suspect it would be possible to use the IOP chip without using these extra functions. What effects this would have on processor card design or anything else - I don't know. -- Spriteman.

 is a RISC OS UserSpriteman on 17/9/03 7:06PM
[ Reply | Permalink | Report ]

But it needs DDR RAM to work, that is supported by the IOP331's memory controller - but *not* by anything on the Omega motherboard.

Having a machine with working memory is cool I find ;)

-- Annraoi McShane,

 is a RISC OS UserAMS on 17/9/03 7:17PM
[ Reply | Permalink | Report ]

em2ac said "Castle stated that the [Iyonix] processor would be on the motherboard, because by the time another processor would be out, most of the board would need replacing to use all of the features"

Quite right. Given what's been written about IOP331 supporting 333MHz or 400MHz RAM (as against 200MHz on the current Iyonix, 133MHz on the current Omega where available, "16MHz" on all non-Kinetic Risc PCs), it would be well worth Castle's while redesigning the motherboard to support this. That's even if a different pinout doesn't require it anyway!

And if they go that far, they might as well update a fair proportion of the other facilities as well. A total redesign of this nature takes a long time (just look at the time gaps between equivalent Acorn systems).

So an Iyonix 2 isn't anywhere in the visible future, I'm afraid.

But these chip developments certainly give encouraging signs that Castle/Tematic's choice of chip for the Iyonix is very far indeed from a dead end.


 is a RISC OS Userdgs on 17/9/03 7:36PM
[ Reply | Permalink | Report ]

Intel only announced the IOP321 in February 2002 and we had the Iyonix Q4 that same year. Do you really think CTL are going to take years to tweak the motherboard? -- Spriteman.

 is a RISC OS UserSpriteman on 18/9/03 11:57AM
[ Reply | Permalink | Report ]

Do you really think developers had no visibility of processors before they're announced? :-) <FX: taps his 733Mhz XScale box here>

 is a RISC OS Userimj on 18/9/03 2:06PM
[ Reply | Permalink | Report ]

Spriteman - this is not entirely a question of whether they "can" as whether it is yet financially viable to do so. In other words, has the existing machine generated enough income to make a successor a viable proposition? And would a new varient with a "bit" faster processor and RAM result in new sales that would not happen otherwise? Of course, other markets may open up with improved specs, so that may well drive things forward, but one suspects that each such project would need to be financially viable, as well as technically so...

 is a RISC OS Userarawnsley on 18/9/03 2:11PM
[ Reply | Permalink | Report ]

imj> Ok, I'll go for the bait. So what 733MHz XScale box would that be then ;)

-- Annraoi

 is a RISC OS UserAMS on 19/9/03 11:27AM
[ Reply | Permalink | Report ]


I'm sure he means an X-Box!


 is a RISC OS UserNeilWB on 19/9/03 12:15PM
[ Reply | Permalink | Report ]

I'm vaguely interested in an iyonix, a small increase isn't going to sway me, but, say, a 2GHz one would likely do so. Select on iyonix would also be likely to sway me. Bascially I'm not paying 1300 /and/ lose Select, for such a small (3x) IMHO increase. 10x or 20x would be significant for me though. Select compatibility is more important to me than speed, therefore I still have a RPC :)

 is a RISC OS Userjohn on 19/9/03 12:43PM
[ Reply | Permalink | Report ]

In reply to arawnsley:

Yes, you are completely correct. This is undoubtably why Acorn usually had such a time gap between models. However, one thing worth considering is that the upgrade would be more similar to the RiscPC600 > RiscPC700 upgrade than the A4x0/1 > A5000. (Yes, I understand it's not a simple processor card swap).

In reply to imj:

Yes, of course developers get access to the goodies in advance. But perhaps that means CTL have had the specs for months now and have a motherboard design done ;-) </not really serious>

-- Spriteman.

 is a RISC OS UserSpriteman on 19/9/03 12:55PM
[ Reply | Permalink | Report ]

As Andrew says, I have doubts that developing a new iyonix MoBoard makes sense in terms of return on investment. I doubt that Castle could produce a replacement package that would of interest to most existing Iyonix owners at a sensible price. For my money, the machine is fast enough as it is for what I do.

But there is another possible reason Castle might do it, and that is obscelescence. Intel presumably see the 331 as a replacement for the 321, so perhaps the 321 will become obsolete, forcing Castle to move on if they want to continue to sell Iyonixes.

Martin -- Martin Dixon, LEICESTER

 is a RISC OS Usermrtd on 19/9/03 1:15PM
[ Reply | Permalink | Report ]

The documentation on the IOP331 indicates the steppings are "engineering samples" and the documents are dated in September, so it's highly unlikely anyone in Castle (or most other places outside Intel) have seen 'em yet, let alone designed a motherboard to take them.

It'll probably happen in time, just not quite yet.....

-- Annraoi

 is a RISC OS UserAMS on 19/9/03 3:29PM
[ Reply | Permalink | Report ]

Actually, if the new 331 based Iyonix was a laptop, it would probably do rather well!

Martin -- Martin Dixon, LEICESTER

 is a RISC OS Usermrtd on 19/9/03 8:19PM
[ Reply | Permalink | Report ]

Just wanted to point out that most of the speculation relating to the Omega in this thread is simply wrong. But I don't have time to go through the same arguments we had a few months ago again, so I'll leave it at that.

 is a RISC OS UserJGZimmerle on 20/09/03 10:19PM
[ Reply | Permalink | Report ]

BTW, 200MHz SDR-SDRAM is much faster than 100MHz DDR-SDRAM (as used by the IOP321, also called DDR200 for marketing reasons). The Omega's RAM controller is implemented in a FPGA wich can be clocked up to 320MHz. So if the Omega should really run into bandwidth problems on the RAM interface because of new prozessors, there is always the option of exchanging or overclocking the RAM.

 is a RISC OS UserJGZimmerle on 21/09/03 11:36AM
[ Reply | Permalink | Report ]

But IMHO it is more likely that the Omega would employ some caching and/or buffering techniques to avoid such a situation.

 is a RISC OS UserJGZimmerle on 21/09/03 11:40AM
[ Reply | Permalink | Report ]

New processors in the Omega?

I thought MicroDigital had already announced an X-Scale upgrade for the Omega, complete with pricing, more than three years ago?

If they haven't even managed to deliver that to end users yet, how long would the *next* upgrade take? Six years from now?

Incidentally, have they got ethernet working yet?


 is a RISC OS Userdgs on 21/09/03 1:07PM
[ Reply | Permalink | Report ]

Omega schmomega. It's not real. MD produced a few boards that didn't work properly and are now just too scared and too deep in debt to 'customers' to admit it. That's my bet, anyway. Zimmerele can blabber on all he likes about the supposed specs of fantasy/sample computers, but until they're in proper production, it doesn't mean a damn! (Just as much as me saying I've got a 733Mhz XScale here, in a mp4 video recorder we're developing at work, while interesting, doesn't /really/ mean anything to the masses).

 is a RISC OS Userimj on 21/09/03 2:24PM
[ Reply | Permalink | Report ]


Regarding the RAM, the MD website says they're using 133MHz SDRAM, while Iyonix uses 200MHz DDR-SDRAM (it is called 200MHz because it uses both rising and falling clocks to access memory, the clock is 100MHz but both edges are used hence the 200 figure).

I'd disagree with your basic comment about MD RAM being faster than Iyonix RAM (in PC's where DDR and SDRAM were compared yes the performance improvement wasn't 2 to 1 as the RAM types would suggest, it was much less than this - but that having been said DDR RAM is still on average FASTER than SDRAM).

I'd also point out that the StrongARM makes poorer use of the available bandwidth as it's bus speed is 66MHz while the xScale (IOP321) has a 100MHz bus speed.

As to fitting an IOP331 to an omega board (if that is what the latest claim is) I just don't see *how* you could do that without (effectively) redesigning the motherboard. The IOP331 has it's own memory controller (replacing the Omega Northbridge), has it's own PCI bridge and probably a whole rake of additional control and data lines the xScale MD designed the motherboard for did not have.

The best MD could do with the existing design would be some sort of "Kinetic" style card with DDR RAM on the processor board along with the processor and some "glue" logic. This would mean the I/O performance would be similar to (or worse than) the existing design - the processor performance would be better. How this would make any sense (as others have pointed out) when MD are already committed to an xScale processor, for which the motherboard and ArmTwister were designed for, is beyond me.

Get the xScale out at 1GHz and that will probably still do the trick guys, any extra bits IOP331 does provide the Omega motherboard couldn't cope with anyway (e.g., the motherboard PCI sockets for one are 32bit not 64 so couldn't support the full 133MHz/64Bit PCI-X of 331 anyway). DDR RAM Being the other...



 is a RISC OS UserAMS on 21/09/03 4:12PM
[ Reply | Permalink | Report ]

So, where can I get this 200 MHz SDR-SDRAM? In typical PC shops (which also means: cheap enough to buy), the fastest SDRAM fitting the RAM sockets inside the Omega is PC133, which is exactly the 133 MHz SDRAM which *already* causes bandwidth problems and the "non-VRAM Risc PC" type effect on processing speed.

The PC market has decided to go for DDR-RAM. The Omega's RAM socket is incompatible to this type of RAM, no matter how often you reprogram the FPGA.

The current Omega has to use simple SDRAM, which is generally only available as 133 MHz types. Which means that it is a dead end concerning upping the bandwidth. Which means that the proposed XScale upgrade is not as fast as it could be unless you use your Omega at 640x480 in two colours.

As to your comment wrt relative speeds between SDR and DDR RAM - you are correct that latency is higher on "200 MHz DDR" compared to the mythical "200 MHz SDR" version, but the burst transfer rate is exactly the same. Since both the StrongARM and the XScales use burst transfers to fill their cache lines, I can't forsee a big performance gain for the SDR variant.

Anyway, MicroDigital, after finally delivering a computer 3 years after announcing that it is ready, should concentrate on comparably simple things likegetting networking and USB out, perhaps along with the XScale upgrade, instead of wasting time on caching and buffering techniques.

 is a RISC OS Userhubersn on 21/09/03 5:02PM
[ Reply | Permalink | Report ]

I don't know where the idea to use the IOP331 in the Omega came from, but I too think that it does not make a lot of sence. What people have to understand however, is that the CPU expansion slot in the Omega is not restricted to the xScale. It is a generic high-bandwidth connection wich can be used for all sorts of things. MD have already mentioned the possibilities of the Halla (1.2 GHz ARM10) and a very powerful FPA. An since the interface is implemented in the FPGA, there is no need for expensive ASICs or similar glue-logic on the expansion board, because the interface inside the FPGA on the motherboard can be changed with a simple firmware update.

 is a RISC OS UserJGZimmerle on 21/09/03 6:45PM
[ Reply | Permalink | Report ]

In the current Omegas there is no bandwidth problem with the SDRAMs. There are a number of fields where things are still being optimised, wich is one of the reasons why we get firmware updates every few weeks. The memory controller is one of these areas, but this does not mean there is a bandwidth shortage with the SDRAMs themselves.

 is a RISC OS UserJGZimmerle on 21/09/03 7:45PM
[ Reply | Permalink | Report ]

BTW, I find the continual refreshing of the pages on drobe quite annoying, because I loose the message I have written every time. :-(

 is a RISC OS UserJGZimmerle on 21/09/03 7:46PM
[ Reply | Permalink | Report ]

Anyway, the performance-benefit by using SDR-SDRAM are quite big, when memory accesses are to non-successive memory areas. So when several burst-transfers to diferent areas of the RAM are taking place, you get much better performance when using SDR-SDRAM than with DDR-SDRAM.

 is a RISC OS UserJGZimmerle on 21/09/03 7:53PM
[ Reply | Permalink | Report ]

Yes, I too would like to get networking and USB ASAP, but unfourtunately for things like faster CPUs you have to "waste time" on caching and buffering techniques.

 is a RISC OS UserJGZimmerle on 21/09/03 7:56PM
[ Reply | Permalink | Report ]

Julian, you don't have answered my question: where can I buy that 200 MHz SDR-SDRAM from? I know that there once were PC150 DIMMs available for our beloved overclockers, but looking at the websites of companies like Kingston and Infineon, I only see PC133 being available - no sign of the mythical PC200 anywhere. And PC150 is nearly double the price of PC133, while e.g. DDR400 is only slightly more expensive than DDR266.

And indeed, my SparkFS benchmark has proven the bandwidth problem in current Omegas - 15% performance gain when reducing my screenmode to 640x480@16 colours. Or do you have another explanation for that speed difference?

You are also confused by memory access on modern CPUs and their consequences for RAM access patterns. Even if I request only a single byte from memory, a whole cache line is filled, resulting in a burst access. While "200 MHz" DDR takes the same time for the first access cycle than 100 MHz SDR, it is two times as fast for subsequent access cycles to satisfy the cache line fill access.

You know, there *are* reasons why PCs use DDR in favour of SDR these days.

Anyway, if MD really are currently wasting their time implementing buffers and caches for yet-to-be-released processor cards, it is a big shame - their customers are waiting for much more important stuff, which e.g. was promised for "end of August" (networking).

 is a RISC OS Userhubersn on 22/09/03 1:51PM
[ Reply | Permalink | Report ]


"where can I buy that 200 MHz SDR-SDRAM from?" I did answer that. See above. I won't look up some URL for you, though, since these days they are quite hard (but not impossible) to find. IIRC Samsung used to make 225MHz ones.

"And PC150 is nearly double the price of PC133"

Well, prices are a different matter. I am quite prepared to pay a little extra for high quality components, especially when they offer a speed advantage. :-)

"Or do you have another explanation for that speed difference?"

There are a great many diffrent possible reasons for this. I suggest you report this to David Prosser of MicroDigital, since he is the only one who can figure out what is the true reason.

"You are also confused by memory access on modern CPUs and their consequences for RAM access patterns."

Maybe you should read my posts more carefully. I was talking about a situation when several burst-transfers from different memory areas are taking place.

"if MD really are currently wasting their time implementing buffers and caches for yet-to-be-released processor cards, it is a big shame"

I you want to know what exactly they are working on just now, I sugest you ask them. I only talk to David Prosser about once a month.

"which e.g. was promised for "end of August" (networking)"

Promised? I can not remember any promises. I can remember them making an astimation of how long they thought it might take. However I can understand you impatience, I am waiting for the network drivers, too. The serial-port PPP link to my RiscPC is quite slow. :-(

 is a RISC OS UserJGZimmerle on 22/09/03 8:09PM
[ Reply | Permalink | Report ]

An XScale cache line is 32 bytes. Taking a simplistic view on memory access, let us compare the things that are available *now* (PC133 vs. DDR200).

- first access: DDR200 is 25% slower - subsequent accesses: PC133 is 34% slower

Now think about the access pattern to find out which RAM is faster.

I now had a look at the Samsung semiconductor website. It is true that there once were single SDRAM chips that are capable of delivering up to 325 MHz - however, they only exist today as part number suffixes, not as real chips. The fastest they now seem to have, and only in the 64 MBit range (which means you would need 32 chips for a single 256 MB SDRAM DIMM), are 250 MHz/CL4, so hardly earth shattering compared to the readily available DDR400-500 parts.

Anyway, MicroDigital would have to produce their own DIMMs. We can only guess what those DIMMs would cost, if even mass-produced PC150 DIMMs are double the price of PC133. I am not sure if anyone would be prepared to pay for this, just because the wrong technology was used. If we ever learned a lesson, it is to take advantage of the cheap parts available from the PC market. After all, we don't still use Bus mouses and Acorn style keyboards because the technology was so much better.


 is a RISC OS Userhubersn on 23/09/03 10:59AM
[ Reply | Permalink | Report ]

What about putting 1, 2 or 4 of these new processors on a PCI board with some of that fast memory so both the Iyonix, the Omega and a PC can use it.

 is a RISC OS UserJaco on 26/09/03 10:45PM
[ Reply | Permalink | Report ]

Dont get too excited about the 333DDR/400DDRII memory interface of the IOP331. The IOP range are designed as additional processors to take away the overhead of controlling PCI-X devices and to stream the data in to memory. Therefor while the memory control on the chip can talk to fast memory it does not mean it can saturate the memory bus with requests from the processor, as full desktop processors can.

The key point in the specification is that the internal bus of the XScale core is only 266MHz (increased from 200MHz on the IOP321 used in the Iyonix) this means its theoretical memory bandwidth utilisation is lower than that of the memory controlller, and much lower in practice.

Whilst an IOP331 would be faster than the IOP321 it would only be likely to give 33% better processor and memory performance. Whilst I'd like to see an even quicker Iyonix, it might be better for Castle to wait for an IOP variant clocked over 1GHz, to give a much bigger performance boost in return for the considerable work of redisgning the motherboard.

Cheers ---Dave

 is a RISC OS Userdruck on 28/09/03 3:11PM
[ Reply | Permalink | Report ]

Hi Dave,

you are of course correct, but using DDR400 would give roughly the same latency as the mythical SDR200 RAM, and even with the IOP331's restriction to 266 MHz, it would give superior throughput.

The work to redesign the motherboard is indeed considerable, but the possible return (e.g. providing PCI Express for the very latest graphic cards, saving the standard PCI bridge, getting significantly more RAM bandwidth, over 30% higher clock speed) may be enough to warrant it.

But this is of course a long way to go, so buy your IYONIX pc now.

 is a RISC OS Userhubersn on 30/09/03 12:44AM
[ Reply | Permalink | Report ]

I think Dave already has one :-)

 is a RISC OS Userdgs on 30/09/03 2:02PM
[ Reply | Permalink | Report ]

I know, the comment was aimed at the general public of course ;-)

 is a RISC OS Userhubersn on 30/09/03 4:41PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Using SDL natively
    Neil White makes his move
     2 comments, latest by nex on 17/10/04 10:52AM. Published: 6 Oct 2004

  • Random article

  • Graphics tablets from Photodesk Ltd.

     Discuss this. Published: 2 Mar 2001

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Your fellow contributor to Drobe seems to have a personal dislike of anything that does not come from Castle"
    Page generated in 0.4336 seconds.