HDTenEightyP/NetNews huggingface dataset:
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.sys.intel
Subject: Re: LOADALL and the 486
Date: 11 Nov 92 09:23:50 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <1992Nov9.115520.5893@fct.unl.pt> jpl@antares.fct.unl.pt (Joao Prospero Luis [ps]) writes:

>Marcus Jenkins (marcusj@apricot.co.uk) wrote:
>: I know this may be an FAQ, but I am just a little confused.  Is
>: LOADALL implemented in the 486?  PC Magazine said that it is
>: in all processors from 2-486.  It also said that Microsoft use
>: the instruction in HIMEM.SYS, SMARTDRV.SYS and RAMDRIVE.SYS in
>: MS-DOS.  On the other hand, an instructor from Intel (while lecturing
>: on an i386/486 programming and architecture course) alleged that
>: LOADALL is only there on 286 and earlier steps of the 386.  Does
>: anybody know the REAL answer?  Is there commercial software out
>: there that does use this reserved instruction.  This enquiry is
>: out of curiosity only - I have no intention of putting LOADALL
>: into any of my programs!

>	As far as I know (it isnt that much) LOADALL isnt implemented in
>the 386, but is simulated by some BIOSes. When it traps an invalid opcode

Actually, LOADALL is two different instructions for 286 and 386.
It seems that at least the d0/d1 version of the 386DX has the LOADALL386
instruction. See /pub/pc/infos/loadall*.txt at ftp.uni-duisburg.de for
information on loadall286 and loadall386.
Many 386 BIOSes versions emulate the loadall286 instruction, because it
is used occasionally in some programs (HIMEM uses it, but only when a
286 is detected; there is seperate code for 386 which is used if one is
detected. The loadall386 is by far not so well known.

>it goes to check if it is a LOADALL, if it is it is simulated otherwise
>it does something else (in fact I think it tests some other invalid opcode
>first but I dont remember which). This was confirmed with my AMI BIOS.

>	JPL

>--
>Joao Prospero Luis                 |
>Universidade Nova de Lisboa        | Internet: jpl@fct.unl.pt
>Faculdade de Ciencias e Tecnologia |
>Departamento de Informatica        | Fax:   (+351) (1) 295-5641
>2825 Monte Caparica, PORTUGAL      | Phone: (+351) (1) 295-4464

-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
|  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
Newsgroups: comp.sys.intel
From: mg@elan (Michael Golan)
Subject: Re: Slime lives: Intel's latest tactic against clones
Organization: Princeton University, Dept. of Computer Science
Distribution: na
Date: 10 Nov 92 14:57:09 GMT

rshwake@irscscm.UUCP (Ray Shwake) writes:

>Excerpted from InfoWorld's _At_Deadline_ column (November 12, 1992):

>	using clone chips would be affected. The proposed royalty rates
>	would be approximately 20 percent of the cost of the clone processor
			       ^^^^^^^^^^^

Wow, Intel has big balls. huge. 20% for the trivial (and stupid) seg:ofs.
From: fj05+@andrew.cmu.edu (Faisal Nameer Jawdat)
Newsgroups: comp.sys.intel
Subject: Re: Cyrix486SLC and NeXTSTEP 486
Date: 10 Nov 92 12:54:46 GMT
Article-I.D.: andrew.sf03qqa00WB5RIg8gv
Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA

news@ux1.cso.uiuc.edu (News) writes:
>     That shows there is definitely a big difference between a Cyrix 486SLC
> and a Intel 486SX/DX.  Otherwise, NeXT would advertise support for the
> Cyrix chip.

aside from the already known different memory paths and lack of
coproccessor (but gee, these are such minor differences :-) ) that's
it, but this was obvious from the initial cyrix specs

someone posted a while back with the differences (instruction/data
wise) between a 486 and a 386/387 and showed how it would be easy
enough for someone to write an os that would only work with a 486 be
exploting 486 features

and when you consider that the cyrix chip is essentially a very fast
386sx, the differences between it and a full 486 are obvious

what i want to know is whether NS486 will require a 487 if you have a
486sx
Newsgroups: comp.sys.intel
From: news@ux1.cso.uiuc.edu (News)
Subject: Cyrix486SLC and NeXTSTEP 486
Organization: University of Illinois at Urbana
Date: Tue, 10 Nov 1992 04:16:10 GMT

I'm not an official spokeperson or anything like that, but I just picked
up the "NeXTSTEP 486 Product Questions and Answers - Sept 30th 1992" sheet
at a PC fair on campus.  It has the following statements in it:

Q: "Will NeXTSTEP 486 run on the Cyrix 486SLC?"
A: "No. The Cyrix chip is not a true 486."

    That shows there is definitely a big difference between a Cyrix 486SLC
and a Intel 486SX/DX.  Otherwise, NeXT would advertise support for the
Cyrix chip.
    The info sheet does say that NeXTSTEP 486 will support ISA/EISA 486SX,
486DX, 486DX2, and future members of the Intel x86 family.  The IBM 486SLC
is not addressed, but that's probably because NeXTSTEP 486 won't support
MicroChannel.  It clarifies by saying that NeXTSTEP 486 will run on any
TRUE 486, so AMD better do a good job or they'll be left out too.

Jeff Barcalow
Organization: University of Illinois at Chicago
Date: Wednesday, 11 Nov 1992 14:59:46 CST
From: SALIM <U26043@uicvm.uic.edu>
Newsgroups: comp.sys.intel
Subject: $ for sale: Mouse for IBM compatibles.

Hi, I have a few Microsoft compatible mouses I want to sell off.

Here are the specs. on them.
Opto Mechanical Mouse. (3 button)
Model # f-842
Switchable Between Microsoft & PC mouse.
400dpi.  Box, manual & installation disk included.
All of them are brand new and come with warranty.

I want to sell all 3 of them fast! So please make me any reasonable
offers.  Email if interested.
                                                           Salim Lakha
                                                          u26043@uicvm.uic.edu
                                                          (708)673-0915
From: isc10192@nusunix1.nus.sg (KOH KHANG WEE)
Newsgroups: comp.sys.intel
Subject: request for info regarding 586 and 486 chips
Date: 9 Nov 92 00:58:59 GMT
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]

hi ! 

I am doing an assignment on the above two chips and need some
information (rumours ?) and data specs for these chips. I'd appreciate
it if someone could tell me about the chip's address bus, data
registers, basically how each works, and how they differ (i mean the 486
and 586) also please tell me how the chips differ with the 386 model.\
I hope u all can help me....thanks in advance....
oh...one more thing...please Email your reply....Thanks again.

regards

Jerry Koh
Newsgroups: comp.sys.intel
From: mostert@cs.sun.ac.za (A. Mostert)
Subject: Re: Undocumented instructions in x86 CPUs
Organization: University of Stellenbosch
Date: Sat, 7 Nov 1992 11:24:10 GMT

In article <1992Nov5.101717.26632@umr.edu> mcastle@mcs213d.cs.umr.edu (Michael R Castle) writes:
>In article <mostert.51@cs.sun.ac.za> mostert@cs.sun.ac.za (A. Mostert) writes:
>>I just became aware of an undocumented instruction that (I think) works on
>>all members of the x86 family. The opcode is D4 10 and it does this:
                           		         ^^^^
>>   AH = AL >> 4
>>   AL = AL & 0xF

>hmm.... listed in my Microprocessors and Peripheral Handbook... AAM 

AAM is opcode D4 0A
AAD is opcode D5 0A

The second byte is actually a number specifying the base, as various people
pointed out to me since my original posting. However, only the form with 0A
as base is officialy documented by Intel. 

Can anyone tell me if this works on the NEC v20/V30 processors ?

A. Mostert
mostert@cs.sun.ac.za
Newsgroups: comp.sys.intel
From: karel@cv.ruu.nl (Karel Zuiderveld)
Subject: 485 cache module unreliable?
Date: Tue, 10 Nov 1992 18:34:15 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group

No luck in comp.sys.ibm.pc.hardware, perhaps here?

I'm considering to add cache to my Hauppauge board; it accepts the 485
cache module (128K).

However, Hauppauge claims that the cache is extremely unreliable due
to design errors from Intel and strongly recommend against using it.

Is this true? 

Karel

-- 
Karel Zuiderveld                            E-mail: karel@cv.ruu.nl
3D Computer Vision - Room E.02.222          Tel:    (31-30) 506682/507772
Academisch Ziekenhuis Utrecht               Fax:    (31-30) 513399
Heidelberglaan 100, 3584 CX Utrecht, The Netherlands
From: 8904596@ul.ie
Newsgroups: comp.sys.intel
Subject: ISPS simulator/ 8086 Spec. Wanted.
Date: 3 Nov 92 18:10:14 GMT
Organization: University of Limerick, Ireland


My wish list...

Are there ftp sites with ISPS simulators available ?

Does anyone have a ISPS description of the Intel 8086/8088 architecture ?

Any information on the above would be most helpful.
	
			Thanking you in advance,

				Warren Buckley,

				Email : 8904596@ul.ie
Newsgroups: comp.sys.intel
From: mkd@mtung.lincroftnj.ncr.com (Mark Darby)
Subject: followup to query
Date: Tue, 10 Nov 1992 22:00:24 GMT
Distribution: usa
Organization: AT&T Bell Labs - Middletown, NJ

Hello again....

I'm not sure whether I made myself clear in my previous posting....

I'm looking for an 8051-ish assembler package for microcontrollers.
I believe the name of the package is CAS and is available somewhere
on the internet via FTP.

Can someone point me in the right direction?

Thanks...
Mark Darby
mkd@mtung.att.com / mkd@mtung.lincroftnj.ncr.com
From: mk@vall.dsv.su.se (Magnus Karlson)
Newsgroups: comp.sys.intel
Subject: Re: Undocumented instructions in x86 CPUs
Date: 5 Nov 92 23:41:54 GMT
Organization: University of Stockholm, Sweden


At least my Programmers ref. for both 286 and 386 lists AAM as opcode
D4 0A not D4 10. If you enter D4 10 in debug and do a unasemble you get
AAM 10 as result!

	Magnus Karlson, mk@vall.se
Newsgroups: comp.sys.intel,comp.sys.ibm.pc.hardware,comp.benchmarks
From: pfk@rz.uni-jena.de (Frank Klemm)
Subject: Re: ATI Ultra PRO 24-bit?
Reply-To: pfk@rz.uni-jena.de (Frank Klemm)
Organization: University Jena, Germany
Date: Thu, 05 Nov 1992 12:19:25 GMT


In article <smithbm.720819736@craft.camp.clarkson.edu>, smithbm@craft.camp.clarkson.edu (Azrak) writes:
|> The ATI Graphics Ultra Pro with 2 Megs of VRAM will do the following
|> resolutions (I am only including a portion of what it can do for brievity):
|> 640x480x16.7M    (True 24 bit color)
|> 800x600x16.7M    (True 24 bit color)
|> 1024x768x65536   (Hi-color 16 bit) (No 24 bit color in this resolution)
|> 1280x1024x256    (8 bit color)
|> 
|> Note that 1024x768x65536 uses 1.5 Megs of memory. Impossible to get 24 bit
|> color at this resolution due to memory limitations.
|> Note that 1280x1024x256 uses 1.3 Megs of memory. Impossible to get 16 bit
|> color at this resolution due to memory limitations.

Why do this card not support 1152x900x64k and 960x720x16M ???

Frank
Newsgroups: comp.sys.intel
From: scottm@intime.intime.com (Scott Michel)
Subject: What is OverDrive?
Organization: -- J/24 -- Racers Home for Programmers
Distribution: comp
Date: Wed, 11 Nov 1992 19:07:08 GMT

This is probably an FAQ, but I'm flame-proof by design anyway. So, here goes:

?What is OverDrive?

It'd make sence if this were the 487, but then, why would you use it with a
486 DX?

Just curious,
-scottm
From: tmh@keks.first.gmd.de (Thomas Hoberg)
Newsgroups: comp.sys.intel
Subject: Re: Cyrix486SLC and NeXTSTEP 486
Date: 11 Nov 92 03:40:58 GMT
Organization: GMD-FIRST, Berlin
In-reply-to: news@ux1.cso.uiuc.edu's message of 10 Nov 92 04:16:21 GMT

In article <BxHFvo.K0B@ux1.cso.uiuc.edu> news@ux1.cso.uiuc.edu (News) writes:
[...]
   Q: "Will NeXTSTEP 486 run on the Cyrix 486SLC?"
   A: "No. The Cyrix chip is not a true 486."

       That shows there is definitely a big difference between a Cyrix 486SLC
   and a Intel 486SX/DX.  Otherwise, NeXT would advertise support for the
   Cyrix chip.
Not necessarly big, but something essential...
       The info sheet does say that NeXTSTEP 486 will support ISA/EISA 486SX,
   486DX, 486DX2, and future members of the Intel x86 family.  The IBM 486SLC
   is not addressed, but that's probably because NeXTSTEP 486 won't support
   MicroChannel.
I've heard of a 386SLC, but a 486SLC? What's that?

   It clarifies by saying that NeXTSTEP 486 will run on any
   TRUE 486, so AMD better do a good job or they'll be left out too.

   Jeff Barcalow

Now just assuming that Intel isn't bribing or secretly threatening the
software industry (not impossible I'm beginning to think--where is
anti trust hiding out, anyway?), there must be technical reasons why
NeXT-Step 486 won't support the 486 (if it really doesn't support the
386. After all, while NeXT Step isn't SUPPORTED on the 386
(performance reasons :-), it might still run on it).

The only technical reasons I could think of are:
- the 386 is too slow
- NeXT Step uses PostScript, PostScript means floating point (but a
486SX doesn't have it either...hmm)

- NeXT Step 486 relies on page faults at ring 0
NeXT Step is supposed to be based on MACH, MACH runs on a 386, so
unless they've changed a lot there, I don't see why they should
require that. I could see that they want to save ring transition
overhead in a micro kernel system (so they have system processes run
at ring 0 but with some protection like read-only pages and a pageable
kernel), but is it worth excluding the whole 386 market (laptops)?

So are they using 486 just to say that they are better than the
average 386 Unix or what?
---
Thomas M. Hoberg   | Internet: tmh@first.gmd.de
1000 Berlin 41     |           tmh@cs.tu-berlin.de
Wielandstr. 4      |
Germany            | BITNET:   tmh@tub.bitnet 
+49-30-851-50-21   |
From: jwreilly@mipos2.intel.com (Jeffrey Reilly)
Newsgroups: comp.sys.intel
Subject: Re: 386/486 differences
Summary: benchmarks performance
Date: 6 Nov 92 01:54:47 GMT
Organization: Intel Corporation, Santa Clara, CA USA

In article <7944@transfer.stratus.com> scol@scottsdale.az.stratus.com (Scott Colbath) writes:
>
>Could someone tell me which would provide better performance between the  
>following two choices.
>
>1) 486 SX 25MHz
>
>       OR
>
>2) 386 DX 33MHZ

The following information is available:

On 16 bit Integer code: 

CPU		ZIFF DAVIS Bench Processor Test
-----------------------------------------------
25MHz 80486SX	6792.91
33MHz 80386DX	5044.00

On 32 bit Integer Code

CPU		SPECint92
------------------------------------------------
25MHz 80486SX	14.24
33MHz 80386DX	8.35

In both cases, the 25MHz 80486SX offers the better perfomance.

>
>These are the two choices I am considering for my first PC. All other aspects  
>of the PC's are tha same on both the machines including price.
>
>All info is greatly appreciated.

Jeff

Jeff Reilly			Performance Benchmarking And Analysis
jwreilly@mipos2.intel.com	Intel Corporation
(408) 765 - 5909		Santa Clara, California
Newsgroups: comp.sys.intel
From: thomas@aeon.in-berlin.de (Thomas Wolfram)
Subject: Re: Undocumented instructions in x86 CPUs
Organization: Cities in Dust
Date: Fri, 6 Nov 1992 01:16:15 GMT

In <mostert.51@cs.sun.ac.za> mostert@cs.sun.ac.za (A. Mostert) writes:
>Hi all

>I just became aware of an undocumented instruction that (I think) works on
>all members of the x86 family. The opcode is D4 10 and it does this:
>   AH = AL >> 4
>   AL = AL & 0xF
>Is this a well known instruction ? Does anyone know of any other instructions
>(besides LOADALL and the 386 bit string stuff) that Intel did not tell us
>about ?

What you discovered was some time ago mentioned in the german computer magazine
"c't". (I guess is more an old story.)
This is the fact that the instructions 'aam' and 'aax' also work
with other basises then 10. It's sometimes (e.g. for conversions) very useful
and I use often following macros (turbo assembler):

aamx    MACRO basis             ;ah := al / basis
        db 0D4h, basis          ;al := al mod basis
        ENDM

aadx    MACRO basis             ;al := ah*basis + al
        db 0D5h, basis          ;ah := 0
        ENDM


You can then use it with (e.g.):

        aamx 16

regards,
Thomas

PS: What is the '386 bit string stuff'?
	
-- 
  Thomas Wolfram, European Advanced Networking Test Center
  (Process Computing Center, Technical University of Berlin)
  Strasse des 17.Juni 135, 1000 Berlin 12, Germany
  +49 030 31421294, wolf@prz.tu-berlin.de, thomas@aeon.in-berlin.de
From: stuart@wstuart (Stuart Hood)
Newsgroups: comp.sys.intel
Subject: Re: RMX development without inteltools ?
Date: 5 Nov 92 16:31:37 GMT
Reply-To: stuart@siesoft.co.uk
Organization: Siemens Nixdorf Information Systems Ltd.
X-Newsreader: Tin 1.1 PL4

lhalie@mswe.dnet.ms.philips.nl writes:
: Hello,
: 
: At Philips Medical Systems in Best (Holland) we develop software for Intel 
: target systems under RMX control. 
: At the moment we work on Vax and PC and use intel crosstools to generate our
: applications. We plan to work on Unix also in the future.
: 
: I have the following questions, referring to development in C (C++?)
: 
:  1. are there any sites, developping for intel targets (RMX?), and not using 
:     intel crosstools? 
:     Which compilers, linkers, locaters, debuggers do you use?
:     
:  2. does anyone have experience with cross debug tools (real mode and
:     286, 386 protected mode, not intel) from Unix to target or PC to target
: 

I'm afraid I can't help you with your second question.

As for your first,  years ago I did some RMX development
on Unix (System V, but it shouldn't matter) using an RMX
emulator that we developed.  I would recommend this
approach and could probably find you the emulator sources
if you'd like (no promises, it was 7 years ago!).

There weren't any (that I remember, so there may have been
a few) problems with differences between the Intel compiler
and the Unix compiler.  Nor were there any differences between
RMX and our emulator even though it only took a couple of weeks
to write.  Actually now I think about it,  we left out certain
parts that we weren't going to use,  such as task control.

Stuart.
-
--
S I E M E N S  Stuart Hood === Siemens Nixdorf House, Bracknell, Berks, UK
-------------  Phone: + 44-344-850892          Email: stuart@siesoft.co.uk
N I X D O R F  - Never let ignorance stand in the way of a good argument -
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.sys.intel
Subject: Re: Undocumented instructions in x86 CPUs
Date: 5 Nov 92 05:47:04 GMT
Organization: Auspex Systems, Santa Clara

>Sure, AAM (ASCII adjust after multiplication) is a well known instruction.

Yup.

In fact, unless you're referring to some *other* AAM instruction, AAM is
so well-known it's even on page 17-20 of the 1986 edition of the "80386
Programmer's Reference Manual"....

However, it *doesn't* mention what happens in AAM if the second byte of
the instruction *isn't* 0A.  The "One-Byte Opcode Map" on page A-4
shows AAM in the D4 location, which seems to indicate that D4 is the AAM
opcode, so maybe, in fact, the second byte is a secret operand that's
the base of the number system for which it's doing the adjustment.

In addition, AAM is claimed to take 17 cycles in the table on page E-5,
and an unsigned divide is claimed to take - surprise, surprise - 14 to
17 cycles with a one-byte operand.

Sounds as if AAM was - at least in the implementations on which you
tried it - really the "divide AL by a one-byte immediate operand,
stuffing the quotient into AH and remainder in AL" instruction....

10 hex is 16 decimal, and if D4 10 does a base-16 AAM, then it would be

	AH = AL >> 4
	AL = AL & 0xF

Try it with hex 11, and see if it does

	AH = AL / 17
	AL = AL MOD 17

Note, though, that they may have cut corners in future implementations,
such as the 586^H^H^HPentium, so that hex A is the only operand that
works correctly.

The same, of course, may well apply to *other* undocumented
instructions; programmer, beware!  (What's Latin for "programmer"? :-))
I've heard a claim that the bit-field instructions didn't completely
work, even on the 386; I've no idea whether there's any truth to that
claim or not.
From: mkahn@hopi.sedona.intel.com (Mitch Kahn)
Newsgroups: comp.sys.intel
Subject: Re: 386 designed in Tel Aviv?
Date: 6 Nov 92 21:16:02 GMT
	<1d3n02INNd6s@iraul1.ira.uka.de> <1992Nov4.215945.21805@irscscm.UUCP>
Organization: i960(r) New Product Development, Chandler AZ

rshwake@irscscm.UUCP (Ray Shwake) writes:


] In article <1d3n02INNd6s@iraul1.ira.uka.de> S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa) writes:
] >> 
] >I read that, too, a while back. Looking at the authors of the papers published
] >on Intel's coprocessors, it is also reasonable to assume that much (if not all)
] >of the work on their coprocessor was done in Israel. Don't know if they are
] >based in Tel Aviv, though. Some other chip manufacturers have design centers
] >there, too. E.g. NS and IBM, I think.
]
]	 Intel's been doing a log of advanced design work in Israel at
]	 least back to the days of their involvement with the 8087. Motorola,
]	 IBM and others do a lot of high-end hardware *and* software work
]	 there. They also source some of their x86 chips there. I recall a
]	 certain concern about 80386 supplies during the Gulf War in the
]	 event the plant were hit by a Scud. Of course, the residents had
]	 other concerns.
]
Intel has a design center in Haifa and a fab near Tel Aviv. The
design center does both hardware and software work.

To their credit, the fab in Israel did not miss a single commit
during the Gulf War. Most employees worked right through the
hostilities.

BTW, the products I was working on at the time were fabbed
in Israel and we had some intersing phone meetings!

 
--
|  Mitch Kahn              | "I hope you know that this will go down on |
|  mkahn@sedona.intel.com  |  your permanent record..."                 |
*************************MY OWN OPINIONS*********************************
Newsgroups: comp.sys.intel
From: wbeebe@bilver.uucp (Bill Beebe)
Subject: Re: P24T
Organization: W. J. Vermillion - Winter Park, FL
Date: Sun, 8 Nov 1992 11:59:14 GMT

In article <92311.134450I18BC@CUNYVM.BITNET> CUNY/Spartacus <I18BC@CUNYVM.BITNET> writes:

>Isn't replacing the entire motherboard a just as good
>alternative than plugging in a new p24t (Pentium SX).  Sure
>it might cost a bit more, but a new motherboard wouldn't have
>the 32/64bit limitations a 486 motherboard would cause.

The reason for the success of the 386SX is in the fact that it is cheaper
to build 16-bit MBs as compared to the cost and complexity of building a
full 32-bit MB. As an example, a 33MHz 386sx MB costs around $100, while
a 25MHz i486sx MB costs around $200(US). Another point to consider; MB
designs require a minimum memory compliment to match the data width. With
16-bit designs, that's two SIMM sticks, which cost $60US. With 32-bit
designs, that's four SIMMs, which cost $120US (both cases 1MB SIMMS at
$30US each). With a 64-bit design, that would be eight SIMMs, which would
be $240US for 8MB or nearly $1000US for 64MB (using 4MB SIMMs at around
$125US each). So there are some real cost differences to consider between
32- and 64-bit designs.

-- 
William H. Beebe, Jr. - wbeebe@bilver.UUCP
                 UUCP - {ucf-cs,peora,uunet}!tarpit!bilver!wbeebe
                      - bilver Public Access Unix, Orlando FL
                      - (407)644-8327  2400/9600  24 hours  8N1
Newsgroups: comp.sys.intel
From: jle9162@zeus.tamu.edu (ECKHARDT, JASON LEE)
Subject: HPPA risc arch. info?
News-Software: VAX/VMS VNEWS 1.41    
Organization: Texas A&M University, Academic Computing Services
Distribution: usa
Date: Sun, 8 Nov 1992 07:17:00 GMT

This may not be the correct place, but does anyone have a phone number or
know where I can get info on the HPPA risc architecture or PA-RISC or
whatever it's called nowadays. (and is HP still the ones making this?)

Thanks, jason.

Newsgroups: comp.sys.intel