| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 322.1 | kermit ? | BAXTA::MACKAY_RANDY | | Mon Sep 29 1986 19:57 | 2 |
|
Won't kermit do it ?
|
| 322.2 | A stand-alone CPU | 9712::DANTOWITZ | David .. DTN: 226-6957 | Tue Sep 30 1986 00:19 | 4 |
|
Stand-alone CPU. No VMS, no nuthin' !
David
|
| 322.3 | | 26286::MCLEMAN | We'll sell no Wine, unless it's time | Tue Sep 30 1986 08:25 | 9 |
| What are you connecting the 8800 to, a big MachoVAX or a MicroVAX?
We just developed a new vax cpu and we down line load it over it's
console line with this neat little hack. But we use Set ho/dte to
actually talk to the console. Is this what you need? or are you
needing something more elaborate?
Jeff
|
| 322.4 | The 8800 console ... | EAGLE1::DANTOWITZ | David .. DTN: 226-6957 | Tue Sep 30 1986 15:34 | 16 |
|
For years we have been using the console ports of
various CPUs. We down-load a smart driver to send
data in large packets or just depositing things to
the console (a longword at a time).
The 8800 console is VERY slow (yes, we can test a
730 faster than an 8800!) To speed this up, one
method would be to have a driver talking over a
terminal port, thus we get around the console's
overhead. Another method might be to have one CPU
test the other CPU, if some sort of thing can be
rigged.
David
|
| 322.5 | Would a DR32 device help? | NESSIE::KEVIN | Kevin O'Brien | Tue Sep 30 1986 16:53 | 11 |
|
Maybe I'm missing the point but it sounds to me like you need a
DR32 type device. There is a native BI DR device on the way.
I agree the 8800 console is SLOW! I'd rather push a car uphill
with a rope than deal with the PRO. The next 8800 will have a �VAX
console! Let's hope it's faster!!!
KO
|
| 322.6 | Whyizzit so slow? | JON::MORONEY | %SYSTEM-S-BUGCHECK, internal consistency failure | Tue Sep 30 1986 17:31 | 6 |
| Hmmm, that's funny. Thought the Pro 380 was a reasonably quick machine, at
least for something like a console...
Hmmm.. MicroVAX consoles... Perhaps a use for a warehouse full of Microvax I's?
-Mike
|
| 322.7 | Wanted: Driver for 8800 - class 4 license | EAGLE1::DANTOWITZ | David .. DTN: 226-6957 | Tue Sep 30 1986 17:37 | 9 |
| > Maybe I'm missing the point but it sounds to me like you need a
> DR32 type device. There is a native BI DR device on the way.
Okay. Is this hardware standard on an 8800? What sort
of driver do we need, and is there such a driver already
that we can use?
David
|
| 322.8 | Not the computer, but the cans and the string | BARAKA::LASTOVICA | Norm Lastovica | Tue Sep 30 1986 20:53 | 3 |
| Issue with the 8800 machines being slow is not the PRO. It is quite
fast. The wire between the machines is very slow. It seems that
everything is serial and packitized, etc.
|
| 322.9 | smaller is better | ASIA::MCLEMAN | We'll sell no Wine, unless it's time | Wed Oct 01 1986 08:14 | 6 |
| As far as using a MV1 or MV2 (qbus) as a console is expensive. Now
we have a..... ooopppsss. Not supposed to say. :-)
Jeff
|
| 322.10 | | JON::MORONEY | %SYSTEM-S-BUGCHECK, internal consistency failure | Wed Oct 01 1986 10:52 | 4 |
| re .9: If the bottleneck is the comm link between the PRO and the 8800, (as .8
states) how will switching to a >shhh...< help?
-Mike
|
| 322.11 | Roll your own application | NESSIE::KEVIN | Kevin O'Brien | Wed Oct 01 1986 12:06 | 17 |
|
RE: .7
No DR devices are not standard they are options. There
is a VMS driver but you have to write your own application. It
ain't easy to use these devices but after seeing some of the things
in this notesfile I'm sure that you could get lots of real GOOD
help.
RE: .10
The bottleneck is the 8 line port between the console and the
CLK module. With the >shhh...< it seems to me that it should be
quicker!! (At least I hope so)
KO
|
| 322.12 | | ASIA::MCLEMAN | We'll sell no Wine, unless it's time | Thu Oct 02 1986 10:01 | 7 |
| Re .10
It is the interface they use between the Pro and the 8800. It is
the old PRO RT option ( if I'm not mistaken).
Jeff
|
| 322.13 | | ULTRA::PRIBORSKY | Tony Priborsky | Thu Oct 02 1986 12:42 | 5 |
| Besides, what good would it do? You'd have to have so much software
underneath any such device that communicated directly to VAX memory
that you'd negate the benefit of AXE. Remember, everyone here
has said that if any such animal exists, it runs under VMS. This
is contradiction to your request...
|
| 322.14 | .. .. | EAGLE1::DANTOWITZ | David .. DTN: 226-6957 | Thu Oct 02 1986 14:45 | 8 |
|
We reserve the first 32K of memory (PA and VA) for the driver.
If there was a simple method by which to use a port (I/O address)
that was directly mapped, even a simple polling scheme would
work faster than the console route.
What do ports look like to the CPU?
|
| 322.15 | | ULTRA::PRIBORSKY | Tony Priborsky | Tue Oct 07 1986 09:50 | 14 |
| The solution to this lies in VAXELN. I'm assuming that an 8800
can be remote loaded over the NI. Load a base VAXELN image
into the 8800 via the Ethernet. That base image has an application
that understands how to load a "file" (which is the AXE image with
a little front end to get it going) into the 8800's memory. Then,
set up the RPB to point the secondary CPU's restart routine to the
AXE image. Then your ELN program issues the "boot other CPU"
command. This causes the SECBOO.COM file to "boot" the secondary,
and your AXE program starts. You'll have to teach AXE to stay
away from the memory that the VAXELN image is using, or have it
gracefully "die" after it kicks the secondary in the rear.
Now you only have to solve the problem of getting the AXE output back
to the "host".
|