apollo@ecf.UUCP (08/31/87)
We were hoping to use Apollos for real-time data
acquisition and control for some of our experimental
work the reason being we already have 4 for our analytical
work and as a result would like to stay with the same
product.
From what what I understand of real-time o/s's
neither Aegis nor Domain/IX is at all appropriate for
such a task (no pun intended) what I was hoping though is that
someone out there is using Apollos for real-time work
and would be willing to post any suggestions,ideas,experiences
to the net as I'm quite sure others are contemplating doing
the same thing seeing that dn3000's and 4000's are so
inexpensive.
A last question: does anyone know of any real-time
executives (i.e. VxWorks, pSOS whatever) that have been
ported to Apollo?
Thanks in advance.
Vince Pugliese
University of Toronto
(416)667 7744
e-mail:apollo@ecf.toronto.edujensen@convex.UUCP (09/12/87)
The desire to do real time processing on an Apollo is interesting.
As a former employee of the company, I a bit familiar with the
architectural problems on the earlier product lines (DN 6xx, DN5xx,
DN4xx & DSP80).
First, Apollo has not written the interrupt handling code with
"real-time" responsiveness in mind. The kernel of the operating
system is monolithic, so you have to use the user device driver
facility to access special devices. There is some overhead associated
with this, which may preclude the responsiveness that you desire.
Although Apollo does have an assembler, it used to be hard to get
ahold of (unless Apollo has changed their distribution scheme).
Lastly, you have no control over anything like interrupt priorities,
thus, getting deterministic response to external events is going
to be hard.
As far as alternative O/S for Apollo systems, I am not aware of
any. Apollo does not release for general consumption the specific
internal details of their boxes. Thus you do not know how
memory addresses are allocated, how the memory mangement unit works,
how the display subsystem works, etc. This is the major stumbling
block to bringing up a non-Aegis O/S. It can be done, all of the
hardware peices are there to run something like Unix, but with
no documentation, it is near impossible.
Let me make a suggestion. Since the 3000 (and, presumably, the 4000)
has an AT compatible bus, look into using one of the commercial
"turbo cards" that fit in that bus. The turbo card can run a
fast "real time" monitor and the Apollo CPU only has to care about
communicating with the other processor. You may have to hack some
signals on the card, but then again, you may not. It may be worth
a look.
Good luck with what you want to do.
Bill Jensen
Convex Computer Corp.
{uiucdcs,ihnp4}!convex!jensenced@apollo.uucp (Carl Davidson) (09/18/87)
I would like to comment on some unintentionally misleading statements in a recent article. In article <63900008@convex> jensen@convex.UUCP writes: > >The desire to do real time processing on an Apollo is interesting. >As a former employee of the company, I a bit familiar with the >architectural problems on the earlier product lines (DN 6xx, DN5xx, >DN4xx & DSP80). > All of the product lines referred to (except the DN5XX) are no longer in production. > >..................... you have to use the user device driver >facility to access special devices. There is some overhead associated >with this, ..... > It is true that Apollo does not provide users with the ability to perform surgery on the OS kernel. Instead, we provide a facility called General Purpose I/O (GPIO) which allows users to dynamically load and execute device drivers in user space at run time. As Bill says, there is a slight overhead involved in dispatching interrupts. This overhead is so small, however, as to be unnoticeable (involves only a few lines of very slick assembler in our kernel). > >Although Apollo does have an assembler, it used to be hard to get >ahold of (unless Apollo has changed their distribution scheme). > This scheme has indeed changed. What counts, though, is that you probably won't need to use assembler to write a device driver on an Apollo. It can all be done quite easily in C, Pascal, or even (*ugh*) Fortran (if you're a real glutton for punishment)! On an Apollo, you can see your entire device driver, even the interrupt routine, run in the debugger during development. Try that on any other workstation! > >.... Apollo does not release for general consumption the specific >internal details of their boxes. ...... > Please see the Domain Series 3000/Series 4000 Hardware Architecture Handbook, Order No. 7861, Rev. 02 for the triviature (is that a word?) you seek. > >Let me make a suggestion. ... look into using one of the commercial >"turbo cards" that fit in that bus. ... It may be worth a look. > Despite the fact that Bill's information is a bit dated, he makes an outstanding suggestion! Data acquisition and real-time performance really [:-)] call for a real-time kernel like VRTX or iRMX to give you the control over scheduling you need. No full-featured OS, even Unix, can really be responsive enough for the most demanding cases (yes, I know some folks have modified the Unix kernel for real-time, but that is not the general case). You should have no trouble finding an assortment of cards which will fit the bill for your application. When you are selecting one, you should have a copy of Writing Device Drivers with GPIO Calls, Order No. 959, in hand. It has all of the information on configurability that you need to select a compatible card. > >Good luck with what you want to do. > Amen! **************************DISCLAIMER**************************** I AM SPEAKING ONLY FOR MYSELF. THE OPINIONS EXPRESSED HERE ARE MINE ALONE AND SHOULD NOT BE CONSTRUED AS THOSE OF APOLLO COMPUTER INC. **************************DISCLAIMER**************************** -- --Carl Davidson Progress: Being able to use $1 million Apollo Computer Inc. of computer equipment to put Chelmsford, MA in your two cents worth. {wanginst,yale,mit-eddie}!apollo!ced