| Omega PCI docs exist |
|
Published: 24th Nov 2004, 15:47:01GMT Source: drobe.co.uk
By Chris Williams
|
| Page 1 of 1 |
|
| But who wants them? |
|
 We 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.
Links
MicroDigital websiteRelated articles
Omega USB project contemplated
ROL cuts deal with Omega users
Fears over Omega refund saga
This article has been linked to, or is available in the following formats:
|
| |
|
imj  (+2.5)
24/11/04 4:04PM |
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. |
piemmm (+4.0)
24/11/04 5:16PM |
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)? |
mrchocky (+4.0)
24/11/04 5:42PM |
In reply to pie:
In reply to 1:
Get currying
In reply to 2:
MicroDigital's PCI probably predates the Iyonix. But the Iyonix one might based upon Phoebe's. |
jmb (+1.5)
25/11/04 2:54AM |
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). |
flypig
25/11/04 4:50PM |
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. |
hzn (+1.5)
25/11/04 5:11PM |
In reply to imj:
True! I hope that that is sorted out quickly! Who registeres SWIs by the way?
In reply 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...
In reply to jmb:
Well if there are similarities and it is more complete then that sounds like "based on" to me.
In reply 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 
|
spellinn (+1.5)
25/11/04 5:51PM |
In reply to 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!
Cheers,
/Neil/ |
jmb
26/11/04 12:33AM |
In reply to 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). |
jb
30/11/04 10:03AM |
issue: SWI chunks are allocated via a formal email request mechanism via either [Email: allocate [at] riscos.com ] or [Email: allocate [at] 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..
JB |
| |
|
|
|
