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

Omega PCI docs exist

By Chris Williams. Published: 24th Nov 2004, 15:47:01 | Permalink | Printable

But who wants them?

Omega motifWe can confirm that documentation covering the Omega PCI system, is available.

The techy bits
The PCI documentation is actually a good read and basically describes MicroDigital's PCI API: it all appears to make sense, SWIs are listed with entry and exit parameters and other details like DMA are discussed. Whoever wrote it has their head screwed on, and it's worlds apart from the statements previously released on MD's website.

The Omega PCI system is controlled by the PCIManager module, which manages the PCI bus and devices connected to it. It allows drivers to control individual devices, read information from them and configure interrupts.

The Omega motherboard also features a number of PCI devices in its Southbridge chip: UDMA IDE, two USB 1.1 controllers and a bridge to a another I/O chip that provides the floppy drive, serial and parallel ports and a PS/2 interfaces.

The politics
MicroDigital's API is very similar to Castle's PCI API, which is understandable as both APIs cater for the same industry standard PCI interface - but the APIs are not exactly the same.

They both share some of the same SWI names. For example, PCI_ReadID on an Iyonix and an Omega both read the vendor and ID information from a PCI card, but the entry and exit registers are defined differently. The Castle API has SWIs that the Omega API doesn't have, and vice-versa. Also, the way in which interrupts and memory mapping are handled differ between APIs. Finally, the MD API SWI base is 0x50E40 and the Castle base is 0x50380.

This isn't the first time we've seen an API split in the land of RISC OS. There's also the API divide between the Castle USB API and the Simtec USB API, which can't be helpful for potential developers, nor users who are torn over which USB card to buy, as each card has a different range of drivers.

It's a mild headache for developers who want to support PCI cards for both Iyonix and Omega users - but then, we can only think of one third party who's actively developing PCI stuff, and that's Simon Wilson. While his PCITV software for Iyonix users has been a success, he's been approached by only two users for an Omega port.

Until we were forwarded a copy of the documents earlier this month, we were a little concerned about whether or not such information existed. Once you've developed, released and marketed a new computer, you ideally want third party software developers to write drivers for your kit. Users will find your product more attractive if they can buy your machine and plug in all sorts of new stuff. It makes financial sense to therefore entice developers by offering lots of detailed and comprehendible guides and documents on how to write software for your hardware. So we're relieved to see that this information describing how to get code talking to the Omega's PCI hardware exists. Everyone wins.

Of course, the API text file originally came from an Omega owner and later passed onto us, and we didn't download or otherwise receive the text directly from MicroDigital. Castle earned themselves brownie points from the userbase by publishing their documentation online (the quality of the documentation is another matter, it's the thought that counts for some), while companies including RISCOS Ltd. are chastised for keeping their documentation for paying customers only. In ROL's case, they had a number of people working on the documentation at one point, which was eventually released to Select subscribers. Although the development team was in favour of publically releasing the docs, management had other ideas.

You never know: perhaps if MicroDigital were to publically release their hardware documentation, it could help boost the popularity of their kit.


MicroDigital website

Previous: Gaming news
Next: Select32 mini-Q and A


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

They cannot both have the same SWI base name "PCI" but different blocks. The allocation scheme is in place specifically to prevent this. One of the parties involved has made a large screwup.

 is a RISC OS Userimj on 24/11/04 4:04PM
[ Reply | Permalink | Report ]

Not having looked at the documentation (so I don't know if it's technically feasable), would it not be possible to either:

1) Create a 'glue' module that translated the Iyonix PCI SWIs into something the Omega PCI SWI interface can use 2) Why did MD not just make it 'iyonic PCI compatible' (apart from maybe losing face)?

 is a RISC OS Userpiemmm on 24/11/04 5:16PM
[ Reply | Permalink | Report ]


1: Get currying

2: MicroDigital's PCI probably predates the Iyonix. But the Iyonix one might based upon Phoebe's.

 is a RISC OS Usermrchocky on 24/11/04 5:42PM
[ Reply | Permalink | Report ]

chox: Based on the Phoebe PCI API docs I've got here, it's hard to say whether the Iyonix PCI implementation is based on it. There are some similarities (function handle in r3, for example), but the Iyonix API is far more complete (and loses some silliness like registering a driver with the PCI manager).

 is a RISC OS Userjmb on 25/11/04 2:54AM
[ Reply | Permalink | Report ]

It doesn't surprise me that the doc writer has "their head screwed on". Microdigital may have fallen down on the PR and timing side of their work, but technically they must be very competent.

It is a big shame there are now two standards. It's not just a problem for developers, but also for the end user who'll have to figure out which driver they need to download. Unfortunately the SWI registering process possibly makes it inevitable (can you have SWI chunks assigned to multiple competing companies?). That's why (IMHO) ROD need to publish open standards for this kind of thing, even if they don't develop the software themselves.

 is a RISC OS Userflypig on 25/11/04 4:50PM
[ Reply | Permalink | Report ]

To imj: True! I hope that that is sorted out quickly! Who registeres SWIs by the way?

To piemmm: 1) no, make a glue to make Omega IYONIX compatible! Then Omega could perhaps use existing IYONIX drivers like PCITV. 2) it an IYONIX with a "X" at the end...

To jmb: Well if there are similarities and it is more complete then that sounds like "based on" to me.

To flypig: I like that "ROD need to publish open standards ... even if they don't develop software"... They might have published some standards but probably to paying Select subscribers only and as for the second quoted part of the sencence: Nice one ;-)

 is a RISC OS Userhzn on 25/11/04 5:11PM
[ Reply | Permalink | Report ]

hzn: Pineapple/Alan Glover administer the filetype/SWI/Module registration database via RISCOS Developments. Email allocations at riscos.com

Who gets SWI names like "PCI_" depends on who registers them first. Anyone using commercial software which uses unregistered SWI/Error chunks are being extremely silly!



 is a RISC OS Userspellinn on 25/11/04 5:51PM
[ Reply | Permalink | Report ]

hzn: Quite honestly, the similarities aren't sufficient to make any kind of sensible judgment either way. I'd make the Phoebe docs available so you could see for yourself, but I've no idea about legal issues relating to them (bear in mind they were released to registered developers only).

 is a RISC OS Userjmb on 26/11/04 12:33AM
[ Reply | Permalink | Report ]

issue: SWI chunks are allocated via a formal email request mechanism via either allocate@riscos.com or allocate@iyonix.com .. the SWI chunk 0x50E40 reported above is already allocated to another name and use. It IS important that suppliers of RISC OS based software correctly follow the allocation mechanism if complete mayhem is to be avoided ..

As to duplicate APIs .. perhaps not desirable, but not always avoidable..


 is a RISC OS Userjb on 30/11/04 10:03AM
[ 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

  • RISC OS features in plain english
    A brave stab at bringing all the feature lists together into one easy to understand summary
     30 comments, latest by bucksboy on 16/1/06 6:56PM. Published: 14 Jan 2006

  • Random article

  • Apple Mac VirtualRiscPC beta on sale
    But only for a lucky PowerPC few
     20 comments, latest by EasyKees on 26/5/07 10:06PM. Published: 17 May 2007

  • 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.1278 seconds.