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

PCI for the masses

By Peter Naulls. Published: 14th Jul 2003, 18:00:08 | Permalink | Printable

Got Expansion? [Update 9:10 15/07/2003]

With the availability of the Iyonix, PCI is usable on RISC OS systems. It's therefore worth discussing the implications of this, and what it enables us to do.

What's the deal?

PCI, or Peripheral Component Interconnect is simply a bus specification for connecting various devices together. Many of the chipsets you can purchase interface to PCI, as do many of the internal expansion devices you can buy for PCs (as opposed to external ones, which tend to be USB).

PCI isn't just for expansion, either. The majority of the onboard devices in the Iyonix are PCI too. Let's have a look at the PCI devices in the Iyonix:

On board
  • 1Gbit network controller
  • AC97 (Sound)
  • IDE interface
  • Power management
  • Southbridge
  • XScale IOP321

PCI card
  • Graphics card
  • USB card

In fact, there are a couple more of onboard ones, but we won't confuse the situation as they don't have too much bearing on this discussion. Perhaps a surprise entry in this list is the XScale processor itself. Apart from the processor core, which is the ARM part of the processor, this particular XScale also contains a PCI controller, which is the device which runs the whole PCI show in the Iyonix, and is responsible for allowing configuration of the devices.

The Southbridge is the device which is largely responsible for allowing the machine to talk to the outside world. As well as providing several PCI devices itself (IDE and AC97 in particular), it also contains a number of other devices (e.g. serial port, interrupt controller, floppy drive), which although not PCI themselves, are configured in the Southbridge via PCI mechanisms.

Electrical Specification

As with many of these types of specification, PCI has both a hardware and software aspect to it. Most of the hardware aspects are rather complex, and won't be of interest unless you're constructing a new PCI card. There is, however, one important point that needs to be noted for Iyonix, the signal keying.

PCI cards come in 3 types - 5V, which is the older specification. Next is 3.3V which is newer and is intended for embedded, laptop and other low power devices. Finally, there's universal, which supports both. The Iyonix only supports (and will only physically take) 3.3V or universally keyed PCI cards. You can tell the difference from the slots on the cards. A slot on the card on the connector nearest the back panel indicates it is 3.3V keyed. A slot on other end indicates 5V, and I'll leave you to guess what having both slots means.

The problem is, that many of the PCI cards available are 5V only, so you need to be careful if you go down to your local PC dealer. Chances are the salesperson doesn't even know PCI keying is, so you'll have to check yourself. In addition, some 5V PCI cards can be modified (with your hole maker of choice) to 3.3V by cutting an additional slot, if the card is able to cope. The USB card in the Iyonix is an example of this.

The Iyonix, of course, has 4 PCI Slots of which 2 are used by cards shipped with the machine.


Of course, to make all these devices work, you'll need drivers. Naturally, RISC OS 5 already contains drivers for all the devices used by RISC OS on the Iyonix, but if you want to put another card in, you'll have to obtain a RISC OS driver for it. Simon Wilson's done this in the case of a TV card, where he's made a driver based upon the Linux "bttv" driver.

Castle have made their PCI API available on their website, and this should be your first stop if you're looking at porting or writing your own driver. The API is very similar to that found in Linux - indeed, this was the root cause of the RISC OS 5 GPL debacle. In any case, this at least makes porting Linux drivers a little easier.

Note however, that just because the RISC OS 5 and Linux PCI APIs are similar doesn't mean that porting Linux drivers is trivial - drivers invariably rely on many OS-specific intefaces, of which PCI is but one, and there will be plenty of leg work still to do.

And of course, if you base a driver on Linux sources, then it'll be GPLed, which somewhat limits your chances of trying to profit financially from making a driver available. Existing BSD drivers may be a better, but possibly harder, route if you're aiming to do this. But the fact that open source drivers exist at all for a given card means that it's much more likely you can also create a RISC OS driver.

Software Interfaces

To the best of my knowledge, there isn't yet any C interface on RISC OS to the SWIs on Castle's site. However, DeskLib will soon have an interface, as will, I expect, OSLib.

RISC OS 5 does give you two commands which you can use to examine the PCI devices in your Iyonix. *PCIDevices and *PCIInfo <n>. I'll let you figure out what they do.

This isn't meant to be a PCI programming tutorial, but I was asked about this privately, so it's worth covering briefly. As is implied by Castle's API, PCI access occurs in various ways. The first is via configuration registers, which identify the device and do various other high level things. Many drivers won't have to touch these. Depending on the card, there will be various regions such as memory, IO and ROM. Memory regions are typically for things like graphics card frame buffers and audio codecs, although some cards have registers there that you might otherwise expect to see in an IO region. ROM regions tend to contain x86 code, and probably aren't interesting on RISC OS. These regions can be mapped into logical memory, so your driver can access them directly.

Omega PCI

Information on this is currently pretty thin on the ground. The Omega certainly has a PCI interface of some description, and it even has the same Southbrige chip with the various devices on it. The problem is that most of the people who are likely to write or port drivers to RISC OS have an Iyonix, rather than holding out for an Omega. This means unless Iyonix drivers can be ported easily, or the Omega has the same PCI interface, then Omega owners might be left wanting. We'll have to see how this plays out.

Rounding Off

In the interests of brevity, I've left out quite a number of things - PCI-X, AGP, bus mastering, etc. I will say only that they exist, and the interested reader should start with the PCI specification linked below.

Let's see those drivers.


Reader Sprow points out that the Iyonix conforms to the PCI 2.2 specification (see below), and probably also to the 2.3 specification. The important point about the latter is that it rules out the 5V only cards, and conformance to this is required by Jnauary next year. This is good news for Iyonix owners, as it means that new PCI cards are much more likely to be suitable.


PCI Specification 2.3
RISC OS 5 PCI Manager
Iyonix PCI Slots

Previous: Alpha, Omega in the wild
Next: New alternative OS section opens


Viewing unthreaded comments | View comments threaded by reply | Skip to the end

drivers please indeed.

pretty please can we have a 64bit SCSI card and a firewire one?

just asking


 is a RISC OS Userepistaxsis_RISC OS on 14/7/03 7:15PM
[ Reply | Permalink | Report ]

Isn't the podule interface on the Iyonix much faster than that of the RiscPC? If so, wouldn't it be better to simply update the drivers for an existing SCSI podule? Cheers!

 is a RISC OS Userfwibbler on 14/7/03 8:38PM
[ Reply | Permalink | Report ]

The opposite is also true. If a PCI card driver is developed for the Omega, it may not work on the Iyonix.

I think I commented sometime last year that the basing the RISC OS PCI interface on Linux code was a smart move. It will certainly make it easier to develop drivers. Simon's work is proof of that.

Will it make the boat go faster? I think the answer is yes.

Cheers Steve

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

The podule interface is twice as fast, and lacks DMA. Yes, updating drivers is a good idea, but a PCI card can go a lot faster.

knutson: You missed an important part of what I wrote. The number of people who might be able to write PCI drivers for the Omega could potentially be very small. So yes, what you say could be true, but not very significant.

-- Peter, drobe.co.uk

 is a RISC OS Usermrchocky on 14/7/03 9:20PM
[ Reply | Permalink | Report ]

Ah. Fair enough. My point was simply that Iyonix users could quickly run out of PCI slots thus they should be reserved for hardware that really needs their speed. All depends on what you want to do with the machine I guess. Cheers!

 is a RISC OS Userfwibbler on 14/7/03 11:06PM
[ Reply | Permalink | Report ]

Nothing a few dollars and some documentation wouldn't fix. -- Cheers Insignificant Steve ;-)

 is a RISC OS Userknutson on 15/7/03 6:06AM
[ Reply | Permalink | Report ]

I don't know what all this FUD about not making money from GPL software is. I make a decent wage from mine (all legal and taxed I might add) on top of my day job wages. Also you could have the driver ported and hense stay GPL but the seperate front end code as proprietry closed-source and charge for the whole package. You would have to make available the source for the driver bit but not the front end. Even then you can still charge for the act of downloading from your own site.

GPL != free beer GPL == freedom

 is a RISC OS Userdansguardian on 15/7/03 11:12AM
[ Reply | Permalink | Report ]

Lots of companies make money off GPL'd software, and charging for a 'pretty' version is quite a good model, as if you're only charging for the front end, you'd have to do a really good job or people would not bother with it. OTOH, if you give something away and charge for support then your incentive to make software extremely easy to use and reliable is a bit watered down as who wants a support contract for something that never fails? The exception for this is massive companies who just want support for peace of mind.

 is a RISC OS Userthegman on 15/7/03 11:41AM
[ Reply | Permalink | Report ]

dans: _excuse_ me. You're accusing me of FUD, but don't say where. Kindly withdraw your accusation and careful reread what I really wrote.

I *never* said you can't make money from GPL. I *never* said you couldn't do anything you've named.

If you want examples of GPLed stuff making money (albeit not very much), look at my Unix Porting Project, but please get off your GPL high horse.

-- Peter, drobe.co.uk

 is a RISC OS Usermrchocky on 15/7/03 11:53AM
[ Reply | Permalink | Report ]

MrChocky. I read dans... posting and thought the FUD was a general comment or directed to knutson's comment on dollars being thrown at it. Have I misse dsomethng or is this a carry over from another article/newsgroup etc??????

cheers bob

 is a RISC OS Usernijinsky on 15/7/03 12:52PM
[ Reply | Permalink | Report ]

bob: you aren't making much sense. GPL is only previously mentioned in my article, and Dan's comment is clearly directed at it. Your confusion perhaps comes because Dan's comments don't really have very much bearing on what I said in the article.

-- Peter, drobe.co.uk

 is a RISC OS Usermrchocky on 15/7/03 1:07PM
[ Reply | Permalink | Report ]

mrchocky: nijinsky is right it was a general comment. I tend to find that most people think that one can't charge for GPL software or make money from it.

It was not directed directly at the comments in the article (very good and interesting btw thanks).

I am aware of your unix project having been a subscriber twice of the browser version. Unfortunately this has now lapsed due to unexpected personal expenses not due to the quality of the work.

 is a RISC OS Userdansguardian on 15/7/03 2:01PM
[ Reply | Permalink | Report ]

Peter: To be fair to Dan, I read his comment as a general one, reflecting the general "GPL means no-one gets paid" opinion that floats about. As an author, I'm sure that you're very protective of your work, and having someone question it's integrity is one of the most insulting that can happen. I'm also sure that very few people who read drobe actually realise how much time and effort it takes to write the articles that they read, and if they did then they would make sure that any comments they made were very carefully worded so that they couldn't be incorrectly interpretted. Unfortunarely for the author, the lack of this perfect situation brings the effort back to their door as all comments must be taken with at least a pinch of salt. Everyone has their bad days, author and reader alike, but the unfair side of it is that an author can end up undermining his or her work simply by their perceived attitude, whereas the reader can simply walk away.

-- Richard Wilson Publications Manager, Tradelink Publications Ltd.

 is a RISC OS Usernot_ginger_matt on 15/7/03 2:18PM
[ Reply | Permalink | Report ]

If it was meant to be a general comment, then I apologise - but it was far from clear that it was the case, since mine was the only GPL reference, and perhaps you should have made your case elsewhere.

If you want to do an article on GPL and RISC OS then of course we'd be happy to publish it.


-- Peter, drobe.co.uk

 is a RISC OS Usermrchocky on 15/7/03 2:21PM
[ Reply | Permalink | Report ]

Hi Peter!

It may be true that most of the people that *you know* are capable of producing drivers for PCI cards have an Iyonix and they might not buy an Omega in addition to it. But you can't assume that you know all the people who are capable of producing drivers. So your hint that there might be a shortage of authors for Omega-PCI drivers is spreading FUD.

@Steve: I am of the opinion that it was not such a smart move to use the Linux PCI code as a base for the ROS PCI layer. I think the FreeBSD code would have been a much better choice.

-- Julian G. F. Zimmerle

 is a RISC OS UserJGZimmerle on 15/7/03 5:44PM
[ Reply | Permalink | Report ]

Or even NetBSD, 'cause it was designed to be portable from the start. Although there are many more books on the subject of hacking the Linux kernel than there are for any of the BSDs...

 is a RISC OS Usernunfetishist on 15/7/03 6:00PM
[ Reply | Permalink | Report ]

Just a small clarification:

By money I wasn't referring to GPL'd code. It is also possible to write drivers from scratch. Of course to do this you need to beable to feed yourself too, hence the money bit. Any company could employee someone to write drivers for devices if the demand exists. This is as true for USB as it is for PCI.

Julians point is good. From what I understand BSD code can be modified without having to release the modified source. Of course either option is smarter than developing a new API that requires development of drivers from scratch.

-- Steve Knutson

 is a RISC OS Userknutson on 15/7/03 9:33PM
[ Reply | Permalink | Report ]

Yes, the BSD licence is "permissive" and allows commercial ventures to use the code with minimal obligation or reciprocation on their part. However, the fact that Linux has had a lot more attention with respect to drivers, and the fact that Castle found it more appropriate to work from the GPL'd Linux sources, would seem to suggest that developers don't necessarily care about (or aren't particularly motivated to cater for) companies that take but don't give in return.

So, yes, OpenBSD/NetBSD/FreeBSD might have been interesting from a licence perspective, but then how interesting were they from a technical perspective? Can the level of support from *BSD drivers compare to Linux implementations?

However, I still wonder to this day how Castle got away with the licensing issues (and dubious "BIOS" arguments) around the PCI layer, but I certainly have no sympathy for proprietary software companies and their concerns about competing with open source technologies whilst continuing to deliver closed source products.

 is a RISC OS Userguestx on 16/7/03 2:27PM
[ Reply | Permalink | Report ]

There are other ways for companies to "give in return" than to release source. Some of the *BSD projects need money more than anything else, so a company could simply contribute that way, without giving key parts of their products away for free. -- Julian G. F. Zimmerle

 is a RISC OS UserJGZimmerle on 16/7/03 3:03PM
[ Reply | Permalink | Report ]

The list in the article of all the on-board PCI devices highlights a fundamental difference in approach between Castle and Microdigital.

David Atkins at Wakefield gave an interesting talk about the trials and tribulations of dealing with chip manufacturers during the process of developing new dedicated hardware to work with RISC OS in his "Spectrum" of machines, including the Omega.

Castle have taken a load of industry-standard devices - see PCI list above - and made RISC OS work with them.

Which is the better approach? Discuss.


 is a RISC OS UserMartyn Fox on 16/7/03 7:18PM
[ Reply | Permalink | Report ]

Which approach has produced a working machine that one can buy?

If there's soft/hardware that does what you want you'd be daft to design it again. Depends what you're trying to achieve, an xscale RISC OS machine to sell or a supercool set of technologies to base your products on, some of which are RISC OS machines.

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

Exactly, the Iyonix, made of standard components, was the quickest route to market, while the Omega is a much more flexible design, wich took a lot more time to develop.

So you can choose: Get an Iyonix now, if you want a fast (but slightly incompatible) machine now, wich will never be faster than it currently is. Get an Omega within a few days or weeks (depending on your position in the queue) if you want a very flexible machine wich has the potential to get faster and additional hardware-features over time.

-- Julian G. F. Zimmerle

 is a RISC OS UserJGZimmerle on 17/7/03 8:28PM
[ Reply | Permalink | Report ]

Hi Julian,

Another viewpoint would be that you can choose between getting an Iyonix now if you want fast, proven hardware with a future-proof OS built by the owner of the OS copyright, together with a nice software bundle containing a capable browser.

Or you can choose if you wait a few weeks/months/years to get an Omega which will be a lot slower, a lot more expensive, comes with an either laughable or "not ready yet" software bundle, promises more performance partly for even more money (XScale or other 32bit only processors in conjunction with a not-working-yet magic solution to run 26bit software on it) or if you just wait long enough (JPEG/MPEG acceleration, FPU, 2D/3D acceleration), relies on a dubious and potentially performance-killing UMA architecture with comparatively slow RAM, needs an immediate and costly OS upgrade to get vital features like DHCP, only guarantees an incredibly scarce screen resolution, and basically relies on a "it's not ready yet, but it will be great once it is finished" promise for most of its features.

Flexibility on its own is no good for the customer.


 is a RISC OS Userhubersn on 18/7/03 11:50AM
[ Reply | Permalink | Report ]

JGZimmerle: I find your cursory evaluation of the Iyonix and Omega rather amusing. How is the Omega a much more flexible design than the Iyonix? What makes you say that the Iyonix will never get any faster?

A cynic would probably say get an Omega in a few weeks, or years, depending upon how much credence you place in anything Microdigital says.

Just an off the wall qustion for the group here: If the Microdigital 'soft' computer concept were really superior to conventional hardware, would it not be used by mainstream (i.e. PC) manufacturers?



 is a RISC OS UserNeilWB on 18/7/03 11:55AM
[ Reply | Permalink | Report ]

Not cheap enough for them.

The real potential for the Omega would be to program the FPGA on the fly for specific tasks.

 is a RISC OS Usermavhc on 18/7/03 7:58PM
[ Reply | Permalink | Report ]

Hi Steffen,

I know you don't believe anything from MD. However, machines are being delivered now. You make a lot of assumptions in your posting, wich might not all be correct. Basically it sounds like spreading FUD to me.

-- Julian G. F. Zimmerle

 is a RISC OS UserJGZimmerle on 20/7/03 9:11AM
[ Reply | Permalink | Report ]

Hi Neil,

the Omega is much more flexible because the function of its most important chips can be changed at run-time and because it has a high-bandwidth expansion bus for additional CPUs/FPAs.

The Iyonix does not have any potential for hardware performance enhancements of the machines wich are already with the users (short of a mainboard-exchange). It might get minor speed-ups through optimisation of the software. -- Julian G. F. Zimmerle

 is a RISC OS UserJGZimmerle on 20/7/03 9:21AM
[ Reply | Permalink | Report ]

"What makes you say that the Iyonix will never get any faster?"

Those blobs of solder which fix the processor to the mother-board, perhaps.

Castle claim that mounting the processor on the motherboard was necessary for reasons of reliability. They say that track lengths have to be matched within very tight tolerances and that a socket would introduce impedance problems.

If MD intend to supply an XScale as an upgrade, it will presumably have to be on a daughter board.

It will be interesting to see who is right.

I imagine that speed upgrades on the Iyonix would have to be through motherboard replacement. This would, of course, allow other enhancements to be made at the same time.


 is a RISC OS UserMartyn Fox on 20/7/03 1:22PM
[ Reply | Permalink | Report ]

If Omegas are in the hands of customers how come noone's talking about their production Omega? Where are the reviews? Comments? Praise? Problems?

 is a RISC OS Usermavhc on 20/7/03 3:45PM
[ Reply | Permalink | Report ]

mavhc > Well MD say they're shipping so I'd imagine 10's if not hundreds of people have them by now (unless MD's definition of "shipping" means something different !).

Julian> And how will programmable logic allow you to turn a 32bit/33MHz PCI slot into a 64bit/66MHz one ? It doesn't - so there are limits to Omega expandability too (and I'd point out that the Iyonix already *has* 64bit/66MHz PCI).

As to xScale, that is an future *option* for Omega, whereas Iyonix users have it *today*. There is also the little matter of the xScale being 32bit only and RISC OS 4 being strictly 26 bit - so what sort of performance hit will "ArmTwister" make in resolving that (if and when it finally arrives).

I suggest Martyn's point stands, when you change a motherboard you get not only a new CPU, but also faster I/O devices, faster memory and so on - the sort of things the FPGA's in Omega will do nothing about.....

-- Annraoi McShane,

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


of course there are also limitations to the Omega's expandability, but they are much lower. One could turn the 33MHz PCI bus into a 66MHz one or the 133MHz memory bus into a 166MHz one, simply by reprogramming the Northbridge-FPGA.

As for a motherboard exchange: This is a possibility that is open to the Omega as well. The problem with it is that it takes time (wich many users have to pay a technician for) and costs a lot more money than a simple FPGA update. Of course the Omega's mainboard will not last for ever, but IMO it will a lot longer than the Iyonix'.

With Xscale I see it like this: If you want a RISC OS computer with an Xscale now and all your software is compatible with it, then go on, buy yourself an Iyonix. But I would remommend you to check throughly wether this is the case. I need to do multimedia-editing sometimes, so I need software like ProSound, StudioSound and CineWorks, as well as a program to record sound with the computer. Currently all these things are not possible with an Iyonix. ProSound does load with Aemulor, but as soon as you try to actually do anything with it, it crashes the whole machine. So simply testing wether a program does load is not enough. You have to test all og the functions you require from that the programs you need. And it might be, that with the next version of Aemulor it will simply stop working (even in parts).

 is a RISC OS UserJGZimmerle on 21/07/03 2:18PM
[ Reply | Permalink | Report ]

Thats assuming the FPGA is actually capable of being clocked over 33MHz.

To keep costs down there is an extremely good chance that it is *not* capable of being clocked faster - otherwise it would *already* be at 66/133/whatever zillion MHz.(Why put a nice expensive chip in your box if you're going to underutilize it).

To get a faster PCI bus you're probably talking chip or motherboard swapouts. And, to be frank, the Omega motherboard is already quite out of date in terms of hardware (Hint: SDRAM is obsolete.).

Your points on compatibility are also pushing it. Exactly the same is true for the Omega and it's "different" hardwares. And please, don't try the argument about how the FPGA can magically be repogrammed to solve all our problems,

 is a RISC OS Useranon/ on 21/07/03 2:46PM
[ Reply | Permalink | Report ]

Hi Julian, I too don't really like the fact that the CPU is not upgradeable in the Iyonix, but it'll only be an issue if and when Castle make a faster Iyonix. If they do motherboard swapouts for a reasonable price, that's fine by me.

However, and it's a really big HOWEVER, the Omega's fancy FPGA features (FFF) are vapourware ATM, and as has been pointed out, the StrongARM and 133Mhz RAM are both out of place in a brand new desktop computer.

I'd love to see the Omega perform in all it's glory, with all the announced features, but not only are they not available, we don't even have a timeline for when they will be.

As for running discontinued 26 bit software, unless totally unavoidable, IMHO we should be trying to use the actively developed software and fund the active developers rather than use software which has been cast aside in favour of PC and Mac versions.

But again, I'd love to see some competition in the market and for RISC OS machines to break the magic 1Ghz barrier.

 is a RISC OS Userthegman on 21/07/03 4:13PM
[ Reply | Permalink | Report ]

Hi anonymous guest!

The FPGAs in the Omega can be clocked at well over 200MHz. AFAIK the reason to stick with 33MHz-PCI was that a lot of PCI cards do not work with higher frequencies.

SDRAM is not obsolete at all, it has a much lower latency than DDR-SDRAM.

I don't see where my point on compatability is pushing it. Show me an Iyonix wich I can use for serious sound- and video-editing. I have an Omega here on my desk, wich does it perfectly, running ProSound, StudioSound and CineWorks.

And there is nothing "magical" about reprogramming FPGAs at run-time. It's just really useful.

 is a RISC OS UserJGZimmerle on 21/07/03 5:31PM
[ Reply | Permalink | Report ]

Hi Garry!

Please explain why "Omega's fancy FPGA features" are vapourware ATM. I have one Omega sitting here on my desk, wich I have reprogrammed at least 40 times, now (not all official releases, though).

I too tend to stick with software that is still being actively developed. But there are just so many areas where this is not possible. Sound- und video-editing are only two examples, I'm sure other people can come up with more.

 is a RISC OS UserJGZimmerle on 21/07/03 5:37PM
[ Reply | Permalink | Report ]

Julian > No I am going by old pictures, so perhaps this has changed, but Omega only seems to have 32bit PCI sockets. If that is the case reprogramming the FPGA although it may allow for 66MHz operation it still *wont* support 64bit operation as PHYSICALLY there is nothing to plug the 64bit card into (ie., no 64bit socket)!

You'd need to redesign the PCB to support 64bit signals, fit 64bit sockets and *then* program the FPGA's to support it - or have I missed something ????



 is a RISC OS UserAMS on 21/07/03 5:38PM
[ Reply | Permalink | Report ]

Hello Julian!

The FFF I was referring to are the MPEG and Mesa/OpenGL stuff mentioned on MD's website, which I understand is not available to the masses. If you've got this on your Omega, I'd love to hear about it. On that note, I think we'd all like to see a review/report of the machine. I understand that MD are shipping to end users, so they cannot possibly have any problem with you telling us all about it, if it's a finalised production machine that we can all run out and buy.

I'm sorry if the above seems kind of abrupt, but as great as the Omega specs are, they just just don't seem to be available to buy. Could I go into a dealer and order a machine which has the specification as described on MD's website?


 is a RISC OS Userthegman on 21/07/03 9:17PM
[ Reply | Permalink | Report ]

Hi Annaroi!

You are absolutely right regarding 64-bit PCI. But most people don't really need that in a desktop machine, anyway. For most people 33MHz/32bit-PCI would be better, since a lot more cards work with it. For those who really need a faster PCI bus in their desktop machines, a 66MHz/32bit bus should be sufficient, especially since it is not slowed down by a graphics card.

 is a RISC OS UserJGZimmerle on 21/07/03 11:37PM
[ Reply | Permalink | Report ]

Hi Garry!

I will not write a review for the same reason that most other Omega owners I know don't: I do not have the time. Acceleration features will be availeble to regular Omega owners when they are advanced enough to be released.

 is a RISC OS UserJGZimmerle on 21/07/03 11:42PM
[ Reply | Permalink | Report ]

Hi Julian,

I am not qualified to discuss hardware issues, but I must say I remain sceptical regarding the claims made by MD about their FPGA based approach. If the advantages are real, why have mainstream hardware manufacturers, with their very large development budgets, not taken this route? Caution: please warn me if you are going to say that only MD has the necessary expertise - I'll have to tie myself to my chair to avoid falling off as I erupt unto fits of uncontrollable laughter.


 is a RISC OS UserNeilWB on 22/07/03 06:01AM
[ Reply | Permalink | Report ]

Hi Neil!

No, it has nothing to do with expertise, just economics. For large volume products FPGAs are much more expensive. Also most companys are not interested in selling products that last, they would rather sell us a new completely new mainboard/STB/NC/etc. every two years. But they still use FPGAs for prototyping. Once they are confident that their design works, they then give it to a chip manufacturer for mass-production.

 is a RISC OS UserJGZimmerle on 22/07/03 08:47AM
[ Reply | Permalink | Report ]

Hi Julian!

I've got to say, something is a little odd about all this, it's hard to believe that out of all the people who had Omegas on order, and presumably now have them, nobody has the time to write a few hundred words on it, run a few benchmarks etc. I'm certainly not accusing you of telling lies, but there is something strange about all this.

Do the regular Omega owners (please raise your hands) know when they'll be getting the advanced features?

For the record, the FPGA approach is a curious one, and it will be very interesting to see how it works out.

 is a RISC OS Userthegman on 22/07/03 10:05AM
[ Reply | Permalink | Report ]

Maybe MD said none of the owners could publish reviews/benchmarks. The last people who did never got any more support for their Omega, and updates would seem to be a vital part of the package ATM.

 is a RISC OS Usermavhc on 22/07/03 11:08AM
[ Reply | Permalink | Report ]

I could understand that for beta testers and such, but what end user would agree to that sort of thing?

 is a RISC OS Userthegman on 22/07/03 12:13AM
[ Reply | Permalink | Report ]

Hi Garry,

There is nothing inherently wrong with using FPGA's. Especially if you're doing a product for release into a limited (or unpredictable) market. FPGA's though more expensive than custom/ASIC circuits don't have the same set-up charge & minimum order quantities that ASIC's have - so in that sense the choice of FPGA made sense.

I'd probably have gone with Antifuse components (like QuickLogic's) rather than SRAM based reprogrammable units (in that Antifuse ones are "instant on" and don't need configuration ROM's like SRAM FPGA's do).

This would (however) mean the FPGA would behave very similarly to an ASIC (and once programmed could not be altered). The whole point of using FPGA's should *not* be just to allow half finished computers to be shipped and then "retrofitted" by a reprogramming job - but rather to allow manufacturers to produce short runs with limited risk and lower cost. If the system proves a success they should then be able to switch to full ASIC's which still have some speed benefit over FPGA parts (and once you start shipping machines in larger numbers ASICs finally *do* make economic sense).



 is a RISC OS UserAMS on 22/07/03 1:11PM
[ Reply | Permalink | Report ]

Hello Annraoi, I don't really know anything about FPGAs, but I was not saying that they were bad or anything. I think it's an interesting way to make custom hardware on the cheap. I thinks it's good that MD can do rolling upgrades even if some people would consider it unfinished.

What I don't like is this constant veil of secrecy and differing accounts of whether the machine is even shipping. If Omegas are really going to end users, then why have we not heard from *one* end user to tell us about their system? Very odd.

 is a RISC OS Userthegman on 22/07/03 3:26PM
[ Reply | Permalink | Report ]

Hi Garry,

Sure I know you weren't bad mouthing FPGA's ;)

I have my doubts about rolling upgrades, if they were relatively minor and the machine was 99% complete that would be fine.... I am not so sure I'd be as tolerant if the machine was only 60% done.

As no-one has a clear ideas how much has to be done to get Omega completed I'd be loathe to suggest writing MD a "blank cheque" on rolling upgrades.



 is a RISC OS UserAMS on 22/07/03 7:41PM
[ Reply | Permalink | Report ]

Hi Annaroi,

the advantage of the SRAM based devices is that they can be reprogrammed while the system is running. So with the Omega you will be able to load a fast single-precision FPA into the FPGAs for games and when you get bored and decide to do some serious work wich requires a double-precision FPA, you just quit the game, load the other FPA into the FPGAs and get on with your work. The FPGA images don't take up much space (a few hundred kilobytes each), so you can easily get away with a 1MB flash ROM, wich is a small price to pay for this great flexibility. And then you also have a place to store additional driver software and modules.

 is a RISC OS UserJGZimmerle on 23/07/03 08:57AM
[ Reply | Permalink | Report ]

Hi Julian,

Agreed, SRAM based FPGA's do allow for dynamic modification (without even a re-boot). And like you suggest I've seen information about various uses for FPGA application specific acceleration (it is a useful approach IMHO).

My reason for preferring Antifuse over SRAM was for different reasons - yes they are more restrictive, but they once programmed (outside the machine) can't be corrupted (and so should be reliable than SRAM units). I was considering FPGA's as a cheaper alternative for limited runs (where an ASIC would be just too darned expensive) and was not even considering the FPGA as a means of making the machine hardware "reconfigurable".

There is no reason why a computer could not have both types, the antifuse for bits that must be available from power on (and be uncorruptable) and SRAM for non-critical uses where configuration failure or corruption would not crash the machine.

Actually there is always some argument going on somewhere about Single Event Upsets (SEU's) the SRAM proponents (such as Xilinx) say they rarely happen (about once every 170 years (*)- but do bear in mind that's only an ESTIMATE) while Antifuse proponents suggest that their technology is less prone to such events.



(*) As FPGA's haven't be around for that long it has to be a statistical estimate - and as they say there's lies damn lies and statistics.

 is a RISC OS UserAMS on 23/07/03 1:16PM
[ Reply | Permalink | Report ]

You just get 170 and leave them for a year.

Anyway, it all sounds cool, but where is it? If it actually worked properly wouldn't there be fanfares everywhere? Unless they're building by hand and don't want too many orders right now.

 is a RISC OS Usermavhc on 23/07/03 5:04PM
[ Reply | Permalink | Report ]

Well, the Omega does use one CPLD, wich is a reprogrammable device wich keeps its configuration during power-offs.

 is a RISC OS UserJGZimmerle on 24/07/03 08:47AM
[ 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

  • Adventures with a Lego-cased A7K web server
    Having previously built desktop and laptop cases of out Lego bricks, model building Peter Howkins has turned his attentions towards crafting a slim box to slid his A7000 into a rack, alongside other rackmount servers. Having pieced together the housing, Peter puts a legacy RISC OS machine through its paces as an internet-facing server.
     11 comments, latest by jess on 3/12/08 2:07PM. Published: 21 Nov 2008

  • Random article

  • VirtualRiscPC fixed for RISC OS 6
    Boot bug was surprise says tester
     2 comments, latest by druck on 18/12/06 9:04AM. Published: 16 Dec 2006

  • 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
    "Leaking tit bits creates rumours, confusion and often mangles facts"
    Page generated in 1.2128 seconds.