HDTenEightyP/NetNews huggingface dataset:
From: jeremy@jacobs.CS.ORST.EDU (Jeremy Smith)
Newsgroups: comp.sys.handhelds
Subject: HP handhelds wanted
Date: 13 Aug 92 06:49:18 GMT
Article-I.D.: leela.1992Aug13.064918.14315
Followup-To: casson@ohsu.EDU
Organization: Computer Science Outreach Services - Oregon State University


I have most of the Classic series except my
HP55 does not work. I think the 71 has maximum cuteness value, and I have one
battered working machine and one battered non working machine. The runner up
for cuteness is the HP 85 (desktop engineers). I have gone in for this series
in a big way. I have some duplicates of various old ones for trading. 

Actively seeking an HP 55 and the card reader and HPIL for the 71.  

casson@ohsu.edu. Regards  Henry.


[Posted for a friend, please reply to him, thanks]

-- 
jeremy@jacobs.cs.orst.edu (Jeremy |-) Smith)
I'm sorry Dave, I'm afraid I can't do that... well, yes I can!
SGNTR VRS VRSN 3.1B: Strppd nd cmprssd fr qckr trnsmssn! nfct yrs tdy!
Newsgroups: comp.sys.handhelds
From: woodhams@phoenix.Princeton.EDU (Michael Woodhams)
Subject: An old Commodore calculator
Originator: news@nimaster
Organization: Princeton University Observatory
Date: Wed, 19 Aug 1992 20:54:35 GMT


I have just acquired an old Commodore programmable calculator. The
person I got it from estimated it was made in about 1974. The label on
the back gives its model number as P50. Any information on this
calculator would be appreciated. In particular, it uses either a
disposable 9V battery or can be operated via an AC adapter, which I
don't have. The label says "Use commodore adaptor no. DC-50S or 707 or
708 or 709." If anybody knows what voltage these produce, this would
be useful.

I hadn't even realised Commodore ever made calculators, or that they
existed as long ago as 1974. What did they do before making the PET?

Xref: sparky comp.sys.handhelds:1909 alt.folklore.computers:12912
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.sys.handhelds,alt.folklore.computers
Subject: Re: An old Commodore calculator
Date: 22 Aug 92 15:09:30 MDT
Organization: Utah State University

In article <1992Aug22.053412.12764@uwm.edu>, anthony@csd4.csd.uwm.edu (Anthony J Stieber) writes:
> I just turned on the larger of the two paperweights, and I notice that
> digits are entered from the left to the rightmost position.  This is
> the opposite of all the other (four) stand alone calculators in the
> house and I think, most other calculators.  The latter machines scroll
> the display right to left to make room for digits as they are entered.
> 
> Why is this?  I would think that not scrolling the display would be
> easier on both the machine and the eyes.  The decimal point does
> wander even if the number of decimal places is the same.

Scrolling the display to the left as digits come in is, in my experience, 
easier. You can just shift the buffer to the left and stuff the digit in the
end instead of searching for or keeping track of the current insertion point;
less work, less stuff to keep track of. Admittedly, I've always done this in
situations where the data I was using fit in a register on the machine I
was using, so shifting left was one instruction...

Roger Ivie
ivie@cc.usu.edu
Newsgroups: comp.sys.handhelds
Subject: Unsubscribe
From: IO20081@MAINE.maine.edu (robert eric beckwith)
Date: Tue, 18 Aug 92 10:20:01 EDT
Return-path: <IO20081@maine.maine.edu>
To: handhelds@gac.edu

unsubscribe
Newsgroups: comp.sys.handhelds
From: anthony@csd4.csd.uwm.edu (Anthony J Stieber)
Subject: Re: HP 95LX and Kittyhawk.
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Fri, 14 Aug 1992 00:51:03 GMT

In article <14272@mindlink.bc.ca> Frank_Murray@mindlink.bc.ca (Frank Murray) writes:
>Has anyone seen a price(in Cdn $) for the 21.8 meg Kittyhawk PCMCIA hard drive
>for the HP 95LX?  I read in a magazine the drive would be $568.00 !

Has HP announced a version of the Kittyhawk for the 95LX?  The
Kittyhawk drive is PCMCIA 2.0 device and will probably only fit in Type
III (10?mm thick) cavities.  The HP-95LX has the older PCMCIA 1.0
standard and has a Type I cavity (3.3mm thick).  PCMCIA 1.0 was only
intended for memory, while PCMCIA 2.0 has support for block and stream
oriented devices like disk drives and modems.  It seems that at least one
company has already made a modem that will work on PCMCIA 1.0 devices.
It may be possible for hard drives to work similiarly.  As it stands,
the Kittyhawk won't work in any palmtop that I know of.

An obvious application of the Kittyhawk drive would be in either an
external module for the 95LX, or integrated into a future machine
(95HD?) or a machine with a Type III PCMCIA 2.0 slot.  My guess is that
HP will probably use the drive for many other things as well.  A
Kittyhawk cartridge that fits in an HP LaserJet font cartridge slot is
a possibility.  HP may also be planning to get into the notebook
computer market, the 95LX was just them getting their feet wet.  In the
past HP has only sold relabled Zenith products.

Does anyone have any comments?  Am I totally wrong?
--
<-:(= Anthony Stieber	anthony@csd4.csd.uwm.edu   uwm!uwmcsd4!anthony
From: pq@cs.man.ac.uk (Paul Quare)
Newsgroups: comp.sys.handhelds
Subject: Psion 3 development kits
Date: 21 Aug 92 09:47:33 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

Here in the U.K.,when you buy a Psion 3, you fill in a registration form
which promises a free subscription to Psion News, a newsletter the first
copy of which I received this morning. They had some comments inside about their
C development kits,which sell for: (I think) #295, #195 & #50 {#=U.K.pound} for
the various levels. The costlier versions provide an MSDOS development system
and the least cost one just provides documentation. Anyway,I phoned up and
ordered one of the documentation type kits,so if I have time I'll try and post
a mini-review of what you are sent. (Then I presume that it's just a few 
evenings work to produce a Unix emulator :- ).
Paul Quare
From: pete@plutonium.CChem.Berkeley.EDU (Pete Goodeve)
Newsgroups: comp.sys.handhelds
Subject: Re: P(sigh)on has made me cry again...
Date: 14 Aug 92 07:24:36 GMT
Distribution: inet
Organization: University of California, Berkeley
NNTP-Posting-Host: plutonium.cchem.berkeley.edu


In  <1992Aug12.124715.12847@sbil.co.uk> (12 Aug),
Robert  Greenwood (rob@sbil.co.uk) writes:
> Crumbs, I've never seen so much traffic about the Psion before, shame
> it's all bad (-:
>
> Pete Goodeve writes:
|> are making me feel a lot better:  1) The new one *is* version 1.80F,
|> (my previous was 1.77F) so *presumably* the cable problem is fixed(!);
> Are you saying it's a cable problem that took out the buttons?  I don't
> think so as my buttons went dodgy about a month back, some worked, some
> didn't, then then worked again, etc.  However, they never all failed to
> work.
Yes.  It seems to be on good authority (including when I talked to the
Psion tech service) that it is the connecting flat cable.  Badly cured,
according to someone (name misplaced -- sorry).
Your problem doesn't dound quite the same, though.  Each time it's happened
to me, some or all of the buttons have died suddenly and permanently.

> Buy a Flash RAM card and make it your default disk.  Swapping to the new
> machines are they arrive each month/week/day is much easier then (I've fo
und).
Hope it doesn't come to that...  Don't want a Flash RAM as my default
in any case: it'd fill up too fast.  Eventually I'll get one as backup,
of course.


What's interesting is that -- despite the torrent of complaints -- not
one person has given up on the Psion!  It's just too nice a little beast...

Oh -- I see [late addition] that Bernd agrees with me...(:-)):

Bernd Meyer (meyer@fuhainf2.fernuni-hagen.de) writes:
> Robert  Greenwood (rob@sbil.co.uk) wrote:
> : Crumbs, I've never seen so much traffic about the Psion before, shame
> : it's all bad (-:
>
> despite of its tiny problems, the Psion 3 is definitely the best organizer
> and palmtop around and I would recommend to bouy it to everybody who wants
> to have a real useful tool for such task right now.
>   [......]        Without any doubt I would buy a Series 3 again, if I had to
> choose again.

That pretty well sums up my feelings, too...
                                                -- Pete --
From: kako@nagara.info.gifu-u.ac.jp (Eiji Kako)
Newsgroups: comp.sys.handhelds
Subject: Re: undocumented SHARP PC-E500
Date: 7 Aug 92 02:57:25 GMT



>    Is it possible to give me some details about the above mentioned
>    commands? Especially syntax?

I can tell you more details. If you use these commands, own *your* risks.

Here is syntax of undocmented commands.

(1) SAVEM  - save machine code program
  SYNTAX:  SAVEM "filename" , &xxxxx , &yyyyy
           &xxxxx is the start address, &yyyyy is the end address.
  EXAMPLE: SAVEM "E:PROGRAM1.BIN" , &BFE00 , &BFFFF

(2) LOADM  - load machine code program
  SYNTAX:  LOADM "filename" [ , &xxxxx ]
           &xxxxx is the start address. If you don't input, to be
           loaded same address you save.
  EXAMPLE: LOADM "E:PROGRAM1.BIN"
           
(3) PEEK   - peek memory
  SYNTAX:  PEEK &xxxxx
           &xxxxx is the address in which is your data you want.
  EXAMPLE: PEEK &BFE00

(4) POKE   - write data to memory
  SYNTAX:  POKE &xxxxx , &yy [ , &zz [ ... ] ]
           &xxxxx is the target address. &yy is data to write.
           &zz is written in the address ( &xxxxx + 1 ).
  EXAMPLE: POKE &BFE00 , &07
           ( &07 is machine code of RETF )

(5) CALL   - call machine code program
  SYNTAX:  CALL &xxxxx
           &xxxxx is the address of the machine code program.
  EXAMPLE: CALL &BFE00


Enjoy!

kako
From: heilig@plains.NoDak.edu (Zachary Heilig)
Newsgroups: comp.sys.m6809
Subject: The 6309 features file...
Date: 20 Aug 92 05:40:26 GMT
Article-I.D.: plains.19799
Organization: North Dakota Higher Education Computing Network


Hello, a while back, someone posted an article showing some(most,all?)
of the extended features of the 6309 chip, I saved it, but it was lost
in a horrible blunder on my part, if someone out there has it, could
you please mail it to me? thanks.

__
Zach
-- 
    - Zach Heilig (heilig@plains.nodak.edu)

Ninety-Ninety Rule of Project Schedules:
	The first ninety percent of the task takes ninety percent of
	the time, and the last ten percent takes the other ninety
	percent.
From: sl1zm@cc.usu.edu
Newsgroups: comp.sys.m6809
Subject: 6309 opcodes and changes from 6809?
Date: 20 Aug 92 03:59:04 MDT
Organization: Utah State University

I'd like info on the 6309 as well.
What I need the most is a list of any new instructions and what their
opcodes are, as well as any other new features or changes in behavior.

I'm writing an emulator/debugger for the 6809 and I thought I might as
well add 6309 support while I was at it.

Thanks!

James

Newsgroups: comp.sys.m6809
From: c9224697@cc.newcastle.edu.au
Subject: MS-DOS to COCO OS9
Organization: University of Newcastle, AUSTRALIA
Date: Thu, 13 Aug 1992 05:53:19 GMT



  i have a coco3 without a modem, but have access to internet on ms-dos
machines so i am looking for a way to get os9 to read ms-dos disks or ms-dos to 
write in os9 format(this been preferable) or some other way to transfer data
between the two? 

 if you can help please mail me at c9224697@wombat.newcastle.edu.au
        thanks  in antisipation  Aaron.
From: al@gold.gvg.tek.com (Al Thorpe)
Newsgroups: comp.sys.m6809
Subject: 6809 C Cross-Compilers
Date: 21 Aug 92 23:14:21 GMT
Reply-To: al@gold.gvg.tek.com (Al Thorpe)
Distribution: usa
Organization: Grass Valley Group, Grass Valley, CA


I'm searching for a 6809 C cross-compiler that runs on a Sun SparcStation.
Ideally, I'd like it to be compatible with the Whitesmith's compiler. We
haven't had support from Whitesmith's for years and I haven't been able to
locate them. Does anyone know if they are still in business?

Other C compilers are acceptable, although an ANSI-compatible version would
require extensive rewriting of the source code so I'd like to stick with K&R.

Thanks in advance,

Al Thorpe
The Grass Valley Group
(916) 478-3488
al@newslc1.gvg.tek.com
Newsgroups: comp.sys.m6809
From: adams@chuck.dallas.sgi.com (Charles Adams)
Subject: 68020 OS9 system
Organization: Silicon Graphics, Inc.
Date: Fri, 14 Aug 1992 02:40:25 GMT


Gang,

i have GIMIX single board 68020 system with FPU, SCSI, 20MB drive,
4 serial ports, 4MB RAM, OS9, C development, etc.

would like to sell it to OS9 guru or wanna be guru.  in nice cabinet,
well taken care of.  loads of software, etc.

would like to buy ICOM 725, thus looking at $800 USA.  prefer local
to dallas area to insure safe transport, etc.

oh.  clocked at 16.7MHZ.

details on request.  i'll be outta town for two weeks on sunday, so
apply early.

ciao,


will throw in PT-6809 system with deal.  operators standing by......

-- 

   Chuck Adams, K5FO @ 65wpm cw 
   adams@sgi.com
From: d3g347@beach.pnl.gov (PD Grengs)
Newsgroups: comp.sys.m6809
Subject: Page Flipping on the CoCo III
Date: 21 Aug 92 23:09:26 GMT
Article-I.D.: oracle.1992Aug21.230926.7438
Organization: Battelle Pacific Northwest Labs, Richland, WA
Originator: d3g347@beach.pnl.gov


Howdy folks.

I have an animation program that fills 384K (12 32K pages)
of my 512K CoCo III with interpolated ray-traced images.
At this point, I would like to know how I can rapidly flip
all 12 pages through the HSCREEN 2 display mode.

Any ideas...?

P.G.
Newsgroups: comp.sys.transputer
From: roger@gimli.inmos.co.uk (Roger Shepherd)
Subject: Re: T9000 status
Organization: INMOS Limited, Bristol, UK
Date: Tue, 18 Aug 1992 08:10:36 GMT

In article <66222@hydra.gatech.EDU>, henshaw@emperor.gatech.edu (Andy Henshaw) writes:
|> 
|>  I think that I am not atypical in thinking that this shortening
|> of Texas Instruments' name sounds very weird to people here in the
|> States.  Generally, we refer to them as TI.  

Ah! Around here TI (Tube INvestments) is the name of a company which makes 
all sorts of things to do with metal tubes.  It causes great disappoint
when reading the financial pages of the paper when there is a headline
about ``Major new product from TI'' and it turns out to be a climbing frame
or a bicycle. 

-- 
Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk
From: ralf@ark.abg.sub.org (Ralf Stephan)
Newsgroups: comp.sys.transputer
Subject: iserver? (was: Re: Wanted: Cross-Assembler)
Date: 20 Aug 92 09:34
Organization: Private Coherent 4.0.1 site Augsburg/Bavaria/Germany

michael@gandalf.moria (Michael Haardt) writes:
> 
> I use iserver for most programs, a binary for Linux and a b004 will be 
> available next time.

Sorry to ask some stupid questions.  Since I first purchased my Transputer
compiler/tools for MSDOS, and I'm now moving to Unix (Coherent in fact),
I would like to have at least a server program to start my .b4 binaries with
(Assumed that they work under Unix, too).

Now this "iserver" seems just the right thing!  Please, where are sources
available for it?  Or is there something similar (hopefully free) ?

Many thanks in advance.  --ralf
-------------If your nose runs and your feet smell, you're built upside-down.
From: michael@uk.ac.oxford.robots (& Stevens)
Newsgroups: comp.sys.transputer
Subject: Re: occam
Date: 12 Aug 92 15:04:00 GMT
Organization: Dept. Engineering Science, Oxford University, UK
In-reply-to: jcbhrb@nic.cerf.net's message of 11 Aug 92 20:57:33 GMT

In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:

>   Elegant tool for expressing parallelism? definitely.
>   Elegant tool for expressing everything else? definitely not.
These two lines sum up OCCAM.


>   (2) I fail to see the advantage of having no operator hierarchy or default 
>       data types:
>
>       why write this:
>
>	  (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32))) - 4.0 (REAL32)
>
>       and count brackets when all I'm trying to do is:
>
>	  1.0 + 2.0*3.0 - 4.0
I think OCCAM is trying to make you aware of exactly what you are
doing numerically, although the use of brackets in the syntax is
confussing.
In ANSI C you also need 1.0f + 2.0f*3.0f - 4.0f to make things clear.
I think a lot of traditional C code ends up with additional type
conversion code produced that the user doesn't see; execpt that it
effect performance. Norcroft's ANSI C is very strong on this with its
'lower precission in wider context' and related warnings.

Thats enougth of me being nice to OCCAM for now. I better stop now
before I think of something to complain about.

--
Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk
From: steved@inmos.co.uk (Stephen Doyle)
Newsgroups: comp.sys.transputer
Subject: T9000 status from comp.sys.transputer
Date: 17 Aug 92 10:53:23 GMT
Distribution: world
Organization: The Internet

for the people on the transputer mailing list who didn't see this response
on T9000 status:-

Article 3025 of comp.sys.transputer:
Newsgroups: comp.sys.transputer
>From: roger@gimli.inmos.co.uk (Roger Shepherd)
Subject: Re: T9000 delayed until first quarter of 93.
Organization: INMOS Limited, Bristol, UK
Date: Wed, 5 Aug 1992 09:15:23 GMT


In article <01GN6SSA6BCGDU8JGR@RCNVMS.RCN.MASS.EDU>, 
                                     JPRATER@RCNVMS.RCN.MASS.EDU writes:|> 
|> 
|> 	It seems that Inmos found a severe bug in the control logic 
|> 	of the T9000.  They have corrected it but it apparently it
|> 	wasn't such a easy task.  This infomation was from one of those
|> 	electronic rags  I forget which on. 

This story has resurfaced recently.  It is referring to problems encountered
some time (c. 1 year) ago, not to anything discovered recently.

Recent progress on the T9000 has been good - a trade paper (Electronics 
Times?) reported CORRECTLY that the T9000 alpha silicon has now come 
out of fabrication and is being tested.  The first fully integrated T9000 
device should enter fab shortly.

(Note: the T9000 alpha contains all components of the T9000 except for 
the virtual channel system; that is it contains processor, FPU, cache, 
external memory interface, control unit and control links).
-- 
Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk

---------------------------------------------------------------------------

regards,

Steve Doyle, Software Marketing, INMOS Ltd   | Tel +44 454 616616
1000 Aztec West                              | 
Almondsbury                                  | UK: steved@inmos.co.uk
Bristol BS12 4SQ, UK                         | US: steved@inmos.com
From: PVR@autoctrl.rug.ac.be
Newsgroups: comp.sys.transputer
Subject: redirect comp.sys.transputer to transputer@prg.oxford.ac.uk
Keywords: > B-9052 Ghent-Zwijnaarde, Belgium. Fax: +32 91 64 58 39
Date: 17 Aug 92 13:19:00 GMT
Distribution: world
Organization: The Internet


 
The message from Steve Doyle of INMOS Bristol on the T9 illustrates the need to
redistribute all messages which are on comp.sys.transputer to the
transputer and occam grapevine in Oxford. Perhaps someone from INMOS can
deal with this. Please do not redistribute only the positive ones.
 
>> Recent progress on the T9000 has been good - a trade paper (Electronics
>> Times?) reported CORRECTLY that the T9000 alpha silicon has now come
>> out of fabrication and is being tested.  The first fully integrated T9000
>> device should enter fab shortly.
 
I just hope that 'shortly' means September '92 and that 'fully integrated'
means alpha T9 plus VCP. Of course 'being tested' means they can still find
major bugs. Having lost several design-ins to Texas already, any hick-ups
could be a real catastrophy for INMOS.
 
By the way, does anyone know the price level of these processors ? Are these
the 40 MHz parts, with 50 MHz somewhere in '93 ?
 
Perhaps it would be a good idea to post the test report, particularly on
performance, to the whole, anxiously awaiting, community.
 
Patrick 'long time no see' Van Renterghem
University of Ghent (up to September 1st)
Belgium
From: iwp@cs.man.ac.uk (Iain Phillips)
Newsgroups: comp.sys.transputer
Subject: Re: occam
Summary: Use imakef for makefiles
Date: 12 Aug 92 12:53:15 GMT
Reply-To: iwp@cs.man.ac.uk (Iain Phillips)
Organization: Department of Computer Science, University of Manchester UK

In article <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de> jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
> ...                                                          a collegue
>spent several days of labour (as in GULAG) to produce the makefile. And every
>time you add a file to the thing, you start thinking about the dependencies
>and what you have to add to the makefile. None of that with the TDS. ...

The imakef tool supplied by Inmos with the toolsets does an excelent job in
producing makefiles.  It handles all the dependancies.  If your program has
only one executable and providing you have your #USEs, #INCLUDEs and ISEARCH
variable correct then there's nothing to worry about.  Here at Manchester,
converting a TDS program to toolset has just been a case of using iflat,
renaming one file, a couple of edits, imakef and make.  The recent versions
of imakef even add rules for deletion of intermediate files to save disk
space, and no dependancy checking of ISEARCH files for faster making.
--
Iain Phillips                iwp@cs.man.ac.uk or iwp@uk.ac.man.cs
Dept of Computer Science, University of Manchester, M13 9PL. U.K.
Newsgroups: comp.sys.transputer
From: k3mi@jupiter.sun.csd.unb.ca (Brian d'Auriol)
Subject: Re: occam
Organization: University of New Brunswick
Date: Wed, 12 Aug 1992 12:41:07 GMT

In article <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de> jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>
>Actually, I think the control of disk files is what the TDS does best. When
>we converted our main Occam programme from TDS to the toolset, a collegue
>spent several days of labour (as in GULAG) to produce the makefile. And every
>time you add a file to the thing, you start thinking about the dependencies
>and what you have to add to the makefile. None of that with the TDS. On the
>other hand, developing with multiple authors is that much harder, and some
>sensible versioning system would have enhanced the value of the TDS much.

Am I missing the point here, but, there is a utility in the latest version
of the Occam toolset (also in the latest version of the c toolset and if
I remember, is also in the D705 product)---ANYWAY: the utility is called
imakef and builds a makefile (complete with all necessary dependencies).  It
does this by backtracking from the desired .btl/.b8h/etc. to all .occ/.pgm 
files.   Although you do *have* to use standard file extensions so that
imakef can work.  The make program is *not* supplied with the toolset, but
we were able to obtain one from an ftp site.  At this most, most of us here
now rely on this feature - and new user/students come quickly up to speed as
well

Brian d'Auriol

A
     

Newsgroups: comp.sys.transputer
From: u31b3hs@cip-s01.informatik.rwth-aachen.de (Michael Haardt)
Subject: Transputer Cross Assembler -- Beta release available per ftp
Organization: RWTH-Aachen, Deutschland
Date: Wed, 19 Aug 92 09:43:05 GMT

I got almost flooded with requests, so here it is.   You can get my
first beta release of my transputer cross assembler per ftp from:

      ftp.thp.uni-koeln.de [134.95.64.1] pub/linux/beta/transputer

or [134.95.80.1] pub/thp/linux/beta/transputer if you can't reach the
first server.

Michael
Newsgroups: comp.sys.transputer