[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

322.0. "8800 stand-alone port driver" by 9712::DANTOWITZ (David .. DTN: 226-6957) Mon Sep 29 1986 12:05

	I am looking for a driver that can be used on an 8800
	to send data back and forth between the 8800 (one
	processor) and another VAX (a`la terminal line).

	The same effect could be achieved if we could bring up
	VMS on one of the processors and talk to the other
	processor too.

	The key factors are that we need to run an application
	in privileged modes, without VMS and we need to transmit
	information between the stand-alone CPU and another VAX.

	Any help would be appreciated.

	David
T.RTitleUserPersonal
Name
DateLines
322.1kermit ?BAXTA::MACKAY_RANDYMon Sep 29 1986 21:572
    
    	Won't kermit do it  ?
322.2A stand-alone CPU9712::DANTOWITZDavid .. DTN: 226-6957Tue Sep 30 1986 02:194
	Stand-alone CPU.  No VMS, no nuthin' !

	David
322.326286::MCLEMANWe'll sell no Wine, unless it's timeTue Sep 30 1986 10:259
    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.4The 8800 console ...EAGLE1::DANTOWITZDavid .. DTN: 226-6957Tue Sep 30 1986 17:3416

	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.5Would a DR32 device help?NESSIE::KEVINKevin O'BrienTue Sep 30 1986 18:5311
322.6Whyizzit so slow?JON::MORONEY%SYSTEM-S-BUGCHECK, internal consistency failureTue Sep 30 1986 19:316
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.7Wanted: Driver for 8800 - class 4 licenseEAGLE1::DANTOWITZDavid .. DTN: 226-6957Tue Sep 30 1986 19:379
>    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.8Not the computer, but the cans and the stringBARAKA::LASTOVICANorm LastovicaTue Sep 30 1986 22:533
    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.9smaller is betterASIA::MCLEMANWe'll sell no Wine, unless it's timeWed Oct 01 1986 10:146
    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.10JON::MORONEY%SYSTEM-S-BUGCHECK, internal consistency failureWed Oct 01 1986 12:524
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.11Roll your own applicationNESSIE::KEVINKevin O'BrienWed Oct 01 1986 14:0617
    
    
    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.12ASIA::MCLEMANWe'll sell no Wine, unless it's timeThu Oct 02 1986 12:017
    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.13ULTRA::PRIBORSKYTony PriborskyThu Oct 02 1986 14:425
    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::DANTOWITZDavid .. DTN: 226-6957Thu Oct 02 1986 16:458

	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.15ULTRA::PRIBORSKYTony PriborskyTue Oct 07 1986 11:5014
    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".