Dual core 1.2GHz Xscale touted by Intel

Published: 23rd Aug 2006, 02:00:11 | Permalink | Printable

Core blimey guv'nor

A new dual-core 1.2GHz XScale processor is expected to be showcased at this autumn's Intel embedded roadshow. The conference, due to run in North America from September to November, will include exclusive talks on a high performance Xscale processor in the Intel storage group - a reference to the IOP342 device, which is from the same 32bit ARM-compatible family as the 600MHz IOP321 in the Castle Iyonix.

The new Xscale reportedly features up to two cores that can each run at 1.2GHz or 800MHz, plus an independent 512MB level 2 cache, PCI-X and PCI-Express interfaces, and 1MB of internal RAM. It can happily access up to 2GB of 533MHz DDR2 RAM, and has some additional serial and I2C ports.

The chip is aimed at embedded products and kit for storing large quantities of data reliably across several hard discs; while one core is dealing with real-time information, the other core could be performing more intensive calculations, which is a boon for audio and video processing applications.

Intel recently flogged its mobile Xscale platform to telecom corporation Marvell, a deal which is currently awaiting the rubber stamp from US regulators. At the time, no mention of the IOP family was made by either party, leading to fears from contacts within the industry that it had been dropped like a hot potato - although today's noises from Intel would appear to prove otherwise.

• Late last year, Intel and ARM had a little tussle over who was going to bring out the first gigahertz-barrier breaking ARM-compatible core first.

Links

Intel Embedded Solutions Conference website - anyone who goes will be plastered with NDAs
Dual-core processing explained Marvell suits discuss Xscale buy out

Previous: New Iyonixes shipping with Nvidia FX52 cards
Next: RISC OS 4 caught on Mac OS X

Discussion

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

Several questions spring to mind: How feasible will it be to utilise these in a RISC OS desktop environment? How soon will the chips be available? How long before they make it to our market if the answer to Q1 is positive? Here is hoping the answers to all questions lead to a positive outcome for RISC OS.

rmac on 23/8/06 3:20AM
[ Reply | Permalink | Report ]

Hmm. Tastey! I'm sure you could devise an API to farm-off time-consuming tasks to the second core... of course, your software would then have to allow multitasking to continue while it waits for the results.

7thsoftware on 23/8/06 3:30AM
[ Reply | Permalink | Report ]

Particularly attractive is the fact that this would be a worthwhile upgrade even if one of the cores were left idle (as it probably would be at first). That gives it a chance to achieve a large enough installed base to make the necessary software enhancements viable.

gdshaw on 23/8/06 5:30AM
[ Reply | Permalink | Report ]

so how old is the ARM11MP ? (ok synthesised multi core, but in the market a lot longer than anybody elses multi core options). [link] Just odd that we all get excited over a paltry two cores now. Must be the 1GHz thing that is news here ;o)

lostamarble on 23/8/06 7:50AM
[ Reply | Permalink | Report ]

Wow, great news! Dual Core, 512MB L2, DDR2 RAM, PCI-Express... if an Iyonix II was released tomorrow we'd finally be reasonably close to the x86 pack. The disappointing thing is that by the time an RO machine actually gets to market with these specs, they will (again) be old hat. Still, a good development if the RO market can make use of it.

Is this processor actually available in large quantities yet? When ARM announces a new chip it normally takes 3 years or so to make it to market.

timephoenix on 23/8/06 8:59AM
[ Reply | Permalink | Report ]

I'd love a 512MB L2 cache in my processor. bet it's really only 512K though

piemmm on 23/8/06 9:12AM
[ Reply | Permalink | Report ]

So, how much redesign would the Iyonix need to use this chip?

Gulli on 23/8/06 9:13AM
[ Reply | Permalink | Report ]

piemmm: Who'd need main memory with 512M L2?

tribbles2 on 23/8/06 9:20AM
[ Reply | Permalink | Report ]

@timephoenix: How would we be reasonably close to the x86 pack? A single-core ARM offers about half the integer performance of a AMD or Intel x86 single-core at the same clockspeed. I guess the same is true for dual-core versions. Current dual-core x86 offer clock speeds of up to 3.8GHz. That makes current x86s about six times as fast as this future ARM for integer performance. But this ARM will probably once again have no FPU and no general-purpose SIMD extensions, making it abysmally slow in comparison for many applications.

For storage controllers a cache of 512MB might actually be quite useful (my current ICP Vortex SCSI controller has 256MB RAM on it), so I would not rule it out that this chip might actually support 512MB external 2nd level cache.

JGZimmerle on 23/8/06 9:44AM
[ Reply | Permalink | Report ]

If the IOP342 contains all the peripheral features of the current chip, which it seems to, then only there would only need to be a redisgn for the differing package layout, plus of course any other changes such as an updated southbridge which would be needed. The seperate flash to hold the ROM could be deleted as it has 32MB on board.

The 1.2GHz clock speed increment combined with the Level 2 (undoubtedly only 512K) would give a substantial speed boost over the IOP321. The 1MB of internal memory could be used to hold critical parts of the OS for further performance gains. This just may hit the 3x tipping point for Castle to consider an Iyonix Mk2.

Thats only considering single core perforamance of course, as currently RISC OS has no facilities to make use of multiple processors. How to utilise the 2nd core would be the big question, symetric multi-processing is obviously not feasible with a CMT OS model, but farming out certain operations which could run in parallel such as I/O handling, graphics rendering and sound synthesis would be possible.

It unlikely Castle would have the resouces to serious tack this, so it would be the ideal case for open sourcing some/all of the OS, as it would allow developers to tack managable chunks of work. As long as the OS establishes a frame work for mutlicore use, operations could be migrated over from the primary processor in a piecemeal fashion.

druck on 23/8/06 9:59AM
[ Reply | Permalink | Report ]

Regardless of whether RISC OS would use the second core, if the XScale is clocked at 1.2GHz it will be a good jump up in performance.

knutson on 23/8/06 10:00AM
[ Reply | Permalink | Report ]

This looks promising indeed

highlandcattle on 23/8/06 10:07AM
[ Reply | Permalink | Report ]

For handling the second core, I wonder if the API for Simtec's Hydra card could be adapted/adopted. The Hydra multi-processor card for the Risc PC did go into production a decade or so ago, though the StrongARM came along soon afterwards and pretty much eclipsed it in terms of potential performance gains. I'm not sure how much (if any) software was actually updated to take advantage of the Hydra.

RichardHallas on 23/8/06 10:10AM
[ Reply | Permalink | Report ]

JGZimmerle: Oh dear, I really did make a mash of that last post in my pre-work haste. What I really meant to say is that at least we would be *making ground* on the x86 pack, particularly in the area of supporting modern PCI-X expansion and DDR2 RAM and a limited performance improvement (certainly not matching, by any means). When simple tasks on the Iyonix such as burning a DVD takes 80 minutes, I'm willing to take anything!

"Who'd need main memory with 512M L2?" Aaah, that day will come one day, I guess

timephoenix on 23/8/06 12:02PM
[ Reply | Permalink | Report ]

A cache can not be used as a replacement for main memory.

I think the most important new feature of the new chip (apart from higher clock-speed) is the PCIe-support. This would finally enable us to use modern GPUs and fast, low-latency transfers from the GPU to the CPU.

JGZimmerle on 23/8/06 2:03PM
[ Reply | Permalink | Report ]

The reason that burning a DVD takes 80 minutes on an IYONIX is that CD devices are talked to via PIO mode 0. If this was upgraded to UDMA33, we would be on par with x86 PC performance. Remember the massive performance boost when HD access was UDMA'ed back in 2003?

Steffen

hubersn on 23/8/06 2:15PM
[ Reply | Permalink | Report ]

Forgive me, but it's been a while since I looked at CPU architecture but why can't you use cache,at least for the most part, in place of system RAM?

Things are a little foggy but I seem to recall that instructions and data are loaded into RAM then the required instructions and data are loaded into cache and only knocked out of cache when something else needs the space ( determined by some algorithm ). If there is no need to replace the data / instructions, then why is it not possible to run at least a basic system with cache only?

What sort of data can only reside in RAM and if it has to be in RAM is there a problem with it in cache or does the CPU bypass cache completely? Or is it that the OS would require a drastic rewrite to achieve such a thing?

snapper on 23/8/06 4:43PM
[ Reply | Permalink | Report ]

snapper: ask that on the newsgroups, its too involved to enter in to in comments.

druck on 23/8/06 5:03PM
[ Reply | Permalink | Report ]

RichardHallas: Or the second core (first) just as FPU

egel on 23/8/06 5:07PM
[ Reply | Permalink | Report ]

Data that needs to be accessible to I/O hardware such as DMA controllers might need to reside in main memory as opposed to L1/L2 cache, it depends upon the architecture. Likewise, for some systems you can just use cache memory as a replacement for main memory. In fact the XScale core used in the Iyonix allows you to do exactly that. You need to write some special code to allocate the cache lines to the addresses you want your 'pseudo-RAM' and then lock those lines in the cache. Hey presto, very fast RAM that makes all other memory accesses that little bit slower by reducing the amount of cache space available to them

adrianl on 23/8/06 5:10PM
[ Reply | Permalink | Report ]

Thanks fo that

snapper on 23/8/06 5:27PM
[ Reply | Permalink | Report ]

If you look at the details here [link],1876,RID%253D0%2526CID%253D30175%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526LID%253D32235%2526BID%253DDF2%2526CTP%253DTRV,00.html, not only does it confirm that the L2 cache is 512 MB (not 512 kB) as some have speculated, but this is per core. In other words, there is 1 GB of on-chip RAM. It also explicitly mentions the possibility of using this in place of external RAM in some applications.

dms on 23/8/06 5:41PM
[ Reply | Permalink | Report ]

OK - the information in the link I just posted may be wrong, because although it does talk about dual 512MB L2 caches, it then talks about 1MB of on-chip memory. This may be the original source of confusion.

dms on 23/8/06 5:44PM
[ Reply | Permalink | Report ]

The referenced web site talks about upto two cores and mentions one or two so it looks like one will be able to buy single core chips which would solve what to do with the xtra core and Risc OS

Jwoody on 23/8/06 8:05PM
[ Reply | Permalink | Report ]

I think the 512MB 2nd-level cache would probably be off-chip.

JGZimmerle on 23/8/06 9:53PM
[ Reply | Permalink | Report ]

In reply to egel: "Or the second core (first) just as FPU"

If you mean via a modified FPEmulator I think any theoretical benefits would be non-existant in practice. Farming off individual instructions from one core to another identical core is pointless. Even if you let the first core continue while the second completes a calculation, the amount of useful integer code the first core could complete before it stalls due to a data dependancy is likely to be less than the overheads in getting the two CPUs to talk to each other in the first place. Even if they communicate entirely on-chip.

To benefit properly from a dual core CPU in RISC OS, apps will need to be multi-threaded and processing split between the two cores by some kind of threading system designed specifically for that purpose. If the code contains floating point calculations, both cores will have to either use FPEmulator or a floating point library.

Cogs on 24/8/06 12:20AM
[ Reply | Permalink | Report ]

Again good news.

With a larger 512KB cache and 1MB of on chip RAM (not to mention higher clock speed) I could forsee the performance being better than x3 times the Iyonix CPU's performance. As to using the second processor I am sure that some tasks could be "offloaded" to it. Even if that were *not* the case - just having *one* CPU at 1.2GHz with that extra cache would still make it worthwhile doing.

Not so bad for a family of chips some pundits pronounced as dead is it ? :-)

AMS on 24/8/06 4:17PM
[ Reply | Permalink | Report ]

Gosh, this would be nice! My problem is that my nearly decade old (although seriously upgraded) SA RPC is more than enough for my needs. A 1GHz Iyonix would change my mind there...

harmsy on 24/8/06 5:59PM
[ Reply | Permalink | Report ]

If at some point the OS will be changed to take the benefits of the dual core we could go a step further and put more than one processor on a board.

As I understand ARM based processors are not expensive so why not use that?

Jaco on 25/8/06 3:50PM
[ Reply | Permalink | Report ]

Is there someone around who knows what the new 1.2 GHz XScale CPU will cost?

Gollum on 25/8/06 4:28PM
[ Reply | Permalink | Report ]

I think the best we can all realistically hope for is for a major player in the consumer market to create a device that uses this chip, and someone ports RO to utilise the device. I cannot see anyone making a native RO box within the next 24 months.

nx

nx on 25/08/06 5:04PM
[ Reply | Permalink | Report ]

nx>"I cannot see anyone making a native RO box within the next 24 months. "

I wouldn't necessarily disagree with that, but you can never tell it could be sooner. As I said elsewhere if the manufacturer *just* coded for *one* of the processors (in other words take the 1.2GHz clock, large L2 Cache, DDR2 support etc.,) and take that *as is* you'd get a pretty sizeable improvement in performance. Over time RO could be changed to, if not doing some form of multiprocessing, at least having the second CPU "help" doing time consuming tasks (Multimedia, disk I/O; some graphics stuff etc.,).

One of the links went to an article that suggested that the processor could use *different* OS'es in both processors (how about RISC OS *and* ARM Linux ?). That might also be a sales point and might appeal to both Linux fans and RISC OS users too.

AMS on 25/08/06 6:26PM
[ Reply | Permalink | Report ]

"Over time RO could be changed to, if not doing some form of multiprocessing, at least having the second CPU "help" doing time consuming tasks (Multimedia, disk I/O; some graphics stuff etc.,). "

Disk I/O is synchronous and blocking having a second CPU does not help unless you can get on with stuff whilst the I/O happens. Not a trivial change for Risc OS.

Graphics - Well I thought the GPU in Iyonix was there to do that.

Personally I don't see any point having a second core unless you have PMT and trying to change Risc OS to that will just break to much and be too big an effort.

Jwoody on 25/08/06 7:54PM
[ Reply | Permalink | Report ]

Jwoody>Ok point taken, as to the graphics perhaps there are computational tasks that might be "speeded up" by having a dedicated processor dedicated to them (like Fontcache filling, computing transforms for Draw (or for Draw strokes, bezier curve computation and so on). As I understand it a lot of the functionality of the GPU in the nVidia card is subject to NDA and may not be readily available to RO developers like Castle - it may be possible to ship some of the load to the second 342 processor - and yes I know this would require some changes to the Draw/Font modules - but if the 2nd processor is doing nothing else and if the task can be "split" in such a way that this approach is viable then why not ?

If the whole proposition is a "non-runner" we'd still be gaining a single processor perhaps x3 times faster than the existing Iyonix one so that in itself may be enough of a reason for a switch anyway and yet leave the possibility (even if remote) for further enhancements that can use the 2nd processor in some fashion.

AMS on 30/08/06 8:18PM
[ Reply | Permalink | Report ]

"but if the 2nd processor is doing nothing else and if the task can be "split" in such a way that this approach is viable then why not ? "

One of the problems as I see it is that a dual core running just Risc OS as it is will be slower than Risc OS running on a single core. Probably 90-95% of the speed. So you have to off load at least 5-10% just to stand still.

Like I said before I think it would be better just to accept that dual core and CMT just don't go together and accept the improvements in the single core case.

Jwoody on 30/08/06 8:53PM
[ Reply | Permalink | Report ]

Takimg up a point AMS made about running two operating systems. If this is possible could we not have ARM Linux running on one processor with applications on RISCOS taking advantage of some of the features missing in RISCOS AKA Uniprint, UniScan etc. That way we might get say a video application running in a "Window" on RISCOS that is actually running on the ARM Linux port a bit. Perhaps it is also a way to run X86 code as well. Any way not being technically up in this area it I don't know but it would be good if it could.

bluenose on 30/08/06 9:37PM
[ Reply | Permalink | Report ]

I still think that an adaptation of the Hydra API would be our best shot at utilising additional cores. For current RISC OS software (including the Firefox port) we would have plenty processing power with just one core of the new chip. New applications, wich require more processing power, could utilise the adapted Hydra API.

JGZimmerle on 30/08/06 10:24PM
[ Reply | Permalink | Report ]

By the way where does the 3x performance for a single core come from. I thought the Iyonix was 600Mhz and this new Intel chip is 1200Mhz. That if my maths is correct is maximum 2x performance assuming you hit no other bottlenecks. Nobody has mentioned high speed memory/font bus so I would have thought the relative cost of cache misses would go up and hence you would be less than 2x. Okay a new Graphics card will speed things up, but I thought the numbers were less than 100% so where does the 3x come from. Other than Castle stating that a new machine would have to run 3x for them to be interested.

Jwoody on 31/08/06 12:55AM
[ Reply | Permalink | Report ]

Go back and read the comments from the beginning.

druck on 31/08/06 1:52PM
[ Reply | Permalink | Report ]

"We" have no control over and no means to achieve any advance of RISC OS as a platform - only Castle have that ability and perhaps other select companies with RISC OS knowledge.

Either Castle is going to release a new native machine or, like MacOS X before it, RISC OS will have to be ported to the x86 architecture, whether that be commercially or as open source.

None of this is going to happen of course. What is the point of making new RISC OS machines or porting the OS? There are no developers left! Cerilica - gone. David Pilling - gone. Computer Concepts - gone. Clares - gone. That's not to mention all the companies from the early-and-mid-nineties. In fact, only MW Software still develops a major, non-specialist application for RISC OS, I think.

If a super-duper, 1.2GHz XScale machine running RISC OS 6 was revealed tomorrow, what advantage would it bring in real terms? Speed maybe, but with all the usual gaps - can't play DVDs, can't watch Flash movies, can't watch AVI and many other movie formats, no decent bitmap editor. No DTP editor with PDF ability or transparency ability, no way to import modern Illustrator files, no modern spreadsheet fully (or near as damn it) compatible with Excel. Oh, no RAW converter/editor.

RISC OS needs a much bigger advantage to hold over other OSes except for impressive font display and drag and drop.

arenaman on 31/08/06 2:45PM
[ Reply | Permalink | Report ]

In reply to Michael Stubbs:

"We have no control over and no means to achieve any advance of RISC OS as a platform"

On the contrary, due to its modular nature it is perfectly possible for third parties to advance RISC OS (with or without access to the source code for the remainder).

(That doesn't mean it will happen, of course, but it is inaccurate to say that we have no control.)

gdshaw on 31/08/06 7:31PM
[ Reply | Permalink | Report ]

"We have no control over and no means to achieve any advance of RISC OS as a platform"

gdshaw I think you have quoted out of context. What he mean't was that only people who can make new hardware are "only Castle have that ability and perhaps other select companies with RISC OS knowledge"

Similarly it is up to Castle if they Open Source Risc OS.

I don't think he said anything inaccurate

Jwoody on 31/08/06 8:16PM
[ Reply | Permalink | Report ]

In reply to James Woodland:

So on the one hand only Castle can advance RISC OS because only they can make new hardware, but on the other hand new hardware would not advance the platform because of all the software gaps? Sorry, but I don't see how that makes any sense at all (even if you accept the premise).

Be careful not to confuse the hardware platform (of which we have several - including x86 via emulation), the software platform (essentially the ABI and API) and the existing codebase.

Castle control one (current) hardware platform and a substantial part of the existing codebase. Significant, yes, but a long way from the total control implied above.

gdshaw on 31/08/06 10:17PM
[ Reply | Permalink | Report ]

gdshaw

"So on the one hand only Castle can advance RISC OS because only they can make new hardware"

Thats NOT what was said Please read carefully "only Castle have that ability and perhaps other select companies with RISC OS knowledge" i.e Castle and a select few.

"but on the other hand new hardware would not advance the platform because of all the software gaps? Sorry, but I don't see how that makes any sense at all (even if you accept the premise)."

Make sense to me.

Jwoody on 31/08/06 10:34PM
[ Reply | Permalink | Report ]

"Druck read the comments from the beginning"

So would it be fair to summarise that you hope for 2x performance 1200Mhz versus 600Mhz and a further 1x performance ( to make 3x ) By improvements of the DDR memory 533Mhz and onboard 1 Meg of Ram.

Jwoody on 31/08/06 10:42PM
[ Reply | Permalink | Report ]

Jwoody: a 3x improvement on Iyonix is not going to shoot any lights out amongst x86 users, granted, but it might just revive development of key applications such as CinoDVD, and also render ports such as Firefox actually pleasant, rather than merely feasible, to use.

bucksboy on 31/08/06 10:55PM
[ Reply | Permalink | Report ]

In reply to James Woodland:

Apologies if I over-condensed the summary there, but my point doesn't really depend on exactly how you slice and dice the wording.

You don't need to be Castle, or to be a 'select company with RISC OS knowledge' (whatever that means), to produce potentially usable hardware - even if you allow ARM-based hardware only.

Any sufficiently skilled programmer can enhance the operating system. Yes, access to the existing codebase would help, but it isn't necessary.

Any sufficiently skilled programmer can help to plug some of the software gaps. Maybe not all of them, but some would be a good start.

To port the existing codebase to new hardware you would (quite possibly) need Castle's consent, but that is very different from requiring that they or an existing player take the initiative. (You do not, of course, have to use any or all of the existing codebase.)

In short, whatever you mean by "advancing RISC OS as a platform" there are options open to us. Some of them might even happen if we spent more time doing rather than complaining.

gdshaw on 31/08/06 11:34PM
[ Reply | Permalink | Report ]

JWoody>Actually the memory interface is DDR2 (not DDR unlike the original IOP321), the L2 cache is 512KB (there was *no* L2 cache on the original IOP321). Additionally the 342 supports PCI express. So when comparing clock with clock you're not comparing like with like as to some degree the processor architecture (well at the very least it's memory and I/O capabilities) have changed. David Ruck's suggestion of 3x would consequently not appear an unreasonable one.

AMS on 01/09/06 6:21PM
[ Reply | Permalink | Report ]

AMS "So when comparing clock with clock you're not comparing like with like "

Thats why I said and a further 1x performance ( to make 3x ) By improvements of the DDR memory 533Mhz and onboard 1 Meg of Ram.

Jwoody on 01/09/06 8:16PM
[ Reply | Permalink | Report ]

And IIRC the original IOP321 had some bugs in the memory controller, wich made it even slower than one would expect.

JGZimmerle on 01/09/06 9:03PM
[ Reply | Permalink | Report ]

So, lets play hypotheticals. Below is what I consider a dream ARM based RISC OS Machine:

Processor : Intel XScale IOP342 Operating System : RISC OS 6 taking full advantage of the dual core IOP342 Graphics card: best off the shelf card available. Sound: provided by the best of the shelf soundcard available Firewire, USB2 and Bluetooth connectivity DVD RW (all formats) CD RW (all formats) Real Alternaive for RISC OS Quicktime for RISC OS Opera or a fully functional Firefox for RISC OS an AVI player An up to date IM client OPEN OFFICE for RISC OS

How big a lottery roll over would be neccessary for me to win to pay for the development of such a machine.

JWCR on 04/09/06 11:06PM
[ Reply | Permalink | Report ]

Would a very large rewrite of RISC OS be required to delegate a particular routine function, such as printing, to the second core of a dual-core processor? Being able to continue working while a large file or document printed out would be a useful real-world improvement in productivity IMO.

bucksboy on 05/09/06 4:14PM
[ Reply | Permalink | Report ]

My hypothetical dream ARM based RISC OS machine:

Squillion GHz 128-core ARM 18 CPU RISC OS 9.3 with support for telepathic control and holographic displays A zillion terabytes of multi-GHz memory (non-volatile, so no need for a pesky hard disc) The size of a walnut Subspace networking so I can go on holiday to Andromeda and still use t'internet Power consumption so low I can power it with my own body heat

Was posting this comment a pointless waste of time?

I think so.

Cogs on 05/09/06 8:05PM
[ Reply | Permalink | Report ]

@bucksboy: But that is possible today, isn't it? I can't remember the last time I had a printing job on RISC OS wich blocked the machine.

JGZimmerle on 05/09/06 9:22PM
[ Reply | Permalink | Report ]

JGZimmerle: forgive my imprecision: it is not the printing that locks the machine in my case (I use Printspool), but the passing of the image to the spooler i.e. if I print a Photodesk image the hourglass appears until the image has been completely spooled and during this time the keyboard is unresponsive.

bucksboy on 05/09/06 9:44PM
[ Reply | Permalink | Report ]

As you say its the application rendering the image that causes single tasking during printing. Without a multi-processor aware PMT operating there isn't another processor cant run the application, which may require access to any OS and most Wimp APIs. On the othe hand the task of spooling the generated data out to a printer is something another processor can do, as it doesn't require much interaction with the OS, but spooling is something that can be done transparently in the background with !PrintSpool already.

druck on 05/09/06 10:31PM
[ Reply | Permalink | Report ]

In reply to bucksboy: That's the lack of preemptive multitasking. Or at least the inability of Photodesk and !Printers to cooperatively multitask while the rendering takes place. Without overhauling RISC OS, changes would have to be made to the software. Even then, it might not help much if a lot of disc IO is happening. That needs overhauling too.

Without that happening (it is unlikely tbh), the best you can do, if you haven't already, is upgrade to Iyonix. Beyond that, you can limit the resolution of the images you print (that will help), or maybe try wimp2 with the dodgy preemption patch (which probably won't work and will most likely crash Photodesk - I haven't tried it). If you've done all of that, I'm all out of ideas. Though a last ditch is that you might find you gain about 3% more processor power if you stop sound DMA by typing "*audio off" at the command line.

Anyone got any other ideas?

Cogs on 05/09/06 10:41PM
[ Reply | Permalink | Report ]

I think that about covers it. It really is Photodesk's fault, for not multitasking while rendering. I guess he could save the image into a different application wich handles multitasking printing better.

As for PMT, I think the best way to implement it would be to do it the Windows' way, by adding a new PMT-capable API (call it WIMP3 if you want) while keeping the old one for compatibility. If the new API is similar to the old one, the applications wich are still developed might be converted.

JGZimmerle on 05/09/06 11:08PM
[ Reply | Permalink | Report ]

Dan Maloney: Well, it comes down to the difference between those who want to see RISC OS survive on Desktop Computers, and list what they would want to see in the next generation RISC OS machine; and those who just enjoy bitching about what their current RISC OS machine cannot do, and why it cannot do it.

JWCR on 06/09/06 02:06AM
[ Reply | Permalink | Report ]

(nt)

mripley on 07/09/06 11:40PM
[ Reply | Permalink | Report ]

In reply to JWCR: "Well, it comes down to the difference between those who want to see RISC OS survive on Desktop Computers, and list what they would want to see in the next generation RISC OS machine"...

I don't see the connection. If making wish lists was all that was needed to save the RISC OS market then it would be saved by now. Bitching about what RISC OS cannot do is helpful: It identifies the things people NEED as opposed to the things that they just think are "k3wL". This is how products such as Gimpprint or Aemulor come about. It is why products that begin with "Wouldn't it be cool if..." fail. Eg: RON, ARM Twister, Phoebe's original aim of multiple StrongARMs and 3 VIDCs... the list goes on.

Saying things like "I want the best graphics card available" isn't really very helpful or realistic. We will get whatever cards that can be made to work - end of story.

Cogs on 08/09/06 00:32AM
[ Reply | Permalink | Report ]

Basically, I was proposing a machine that runs RISC OS with the level of hardware that comes a standard these days with a Windows PC, the basic level of hardware that would be needed to begin to get a PC user interested in RISC OS. Obviously "whatever cards that can be made to work" of the shelf are the "best available". I'm talking about contemporary PC minimums here, not cutting edge.

JWCR on 08/09/06 12:08AM
[ Reply | Permalink | Report ]

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

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

Online banking with RISC OS
We thought this would be of high interest

28 comments, latest by devine on 25/9/05 8:30AM. Published: 1 Sep 2005

Random article

Omega sighted in Scotland
We went to Livingston. We saw the Omega. Were we impressed? Read on...

25 comments, latest by diomus on 13/9/02 6:36PM. Published: 7 Sep 2002

Create a new account
Forgot your password?

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Drobe's only failing is the sixth-form geek-journo tone with its lead balloon humour and occasional smugness and ugly personalty"
Page generated in 0.1801 seconds.