From cse.psu.edu!9fans-outgoing-owner Thu Oct 26 13:14:11 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <9590>; Thu, 26 Oct 1995 13:14:01 -0400 Received: by colossus.cse.psu.edu id <78629>; Thu, 26 Oct 1995 13:00:11 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <78730>; Thu, 26 Oct 1995 12:58:41 -0400 From: jmk@plan9.att.com To: 9fans@cse.psu.edu Date: Thu, 26 Oct 1995 12:36:13 -0400 Subject: re: adaptec aha-2940 Message-Id: <95Oct26.125841edt.78730@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO This should be in a FAQ: there is no support for any Adaptec AHA-2xxx series controller. It would be great if someone wrote a driver since these are popular and show up embedded on motherboards. However, it's completely different from any other Adaptec controller and I've been convinced by others on the list that a driver would be a fair amount of work. A month or so ago this was my response: None that I know of. Someone should probably do it as the Adaptec 2xxx controllers are fairly popular. However, it's unlikely to be me as 1) I tried again to get the manuals only to receive the "User's Guide" like I did 2 years ago and on further inquiry discover the useful manuals are all on back-order; 2) I don't have a controller and they do seem rather expensive compared to the NCR8xx alternatives with similar performance; 3) I looked at the Linux driver after this question came up last time and got frightened. ------ original message follows ------ >From cse.psu.edu!9fans-outgoing-owner Thu Oct 26 12:35:48 EDT 1995 Received: by colossus.cse.psu.edu id <78624>; Thu, 26 Oct 1995 12:12:13 -0400 Received: from goggins.bath.ac.uk ([138.38.32.13]) by colossus.cse.psu.edu with SMTP id <78628>; Thu, 26 Oct 1995 11:28:28 -0400 Received: from bath.ac.uk (actually host solomon.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Thu, 26 Oct 1995 15:19:54 +0000 Original-Received: from GATEWAY by bath.ac.uk with netnews for 9fans@bath.ac.uk (9fans@cse.psu.edu) PP-warning: Illegal Received field on preceding line To: 9fans@cse.psu.edu Date: Tue, 24 Oct 1995 22:26:54 -0400 From: "Nathan D. Tuck" Message-ID: <46k79e$p4h@jaws.cs.hmc.edu> Organization: Harvey Mudd College, Claremont, CA Subject: adaptec aha-2940 Source-Info: From (or Sender) name not authenticated. Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Hi, We have a few Gateway machines with Adaptec AHA-2940 PCI SCSI Master controllers. So far as I can tell, Plan9 doesn''t seem to be happily recognizing them. Can anybody give me any advice on where to go from here? I'm willing to spend up to say 5*20 hours writing a device driver (Mountain Dew, yummy) if that is the best route. Advice as to which parts of the source I can cut and paste, potential similarities with say the 1542, etc etc would be much appreciated. Thanks. Please reply via e-mail and through the newsgroup (just in case our newsreader chokes), nate From cse.psu.edu!9fans-outgoing-owner Thu Oct 26 20:18:48 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <9881>; Thu, 26 Oct 1995 20:18:44 -0400 Received: by colossus.cse.psu.edu id <78356>; Thu, 26 Oct 1995 20:03:11 -0400 Received: from bunyip.cc.uq.oz.au ([130.102.2.1]) by colossus.cse.psu.edu with SMTP id <78355>; Thu, 26 Oct 1995 20:02:49 -0400 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <06190-0@bunyip.cc.uq.oz.au>; Fri, 27 Oct 1995 09:55:28 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id JAA23648 for <9fans@cse.psu.edu>; Fri, 27 Oct 1995 09:21:08 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id XAA15411; Thu, 26 Oct 1995 23:21:10 GMT Message-Id: <199510262321.XAA15411@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.4 10/10/95 To: 9fans@cse.psu.edu cc: sysseh@devetir.qld.gov.au Subject: Re: adaptec aha-2940 In-reply-to: Your message of "Tue, 24 Oct 1995 22:26:54 -0400." <46k79e$p4h@jaws.cs.hmc.edu> X-Face: $.-~&U=${N=I$&B~1:E6C8w`s2>*j3hV1j`KM@-toD:Z$o.,e4mfnKDpV1.WlHU}^O"3''L %N=8hj4%d.18rx5CP=d5NQW-`\gF97|$cY$?WZ8#|L]B5x]6z-I#g+cfSnOvoHzh-p,v~M[j4jt^$E G"@]fay-K8I@QkLCCC{kkmq'6?hMb"3Ww4"%R#~cRXN6sTI'Z)8c.5vk}KU\6|ms@Bzcte0e%6n:%. R{jW`&cUB_JtWbZ#u|W56lU&69/KhRcRJfR|*n.v\^W$}$kc Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO > Hi, > > We have a few Gateway machines with Adaptec AHA-2940 PCI SCSI Master > controllers. So far as I can tell, Plan9 doesn''t seem to be happily > recognizing them. Can anybody give me any advice on where to go from > here? I'm willing to spend up to say 5*20 hours writing a device > driver (Mountain Dew, yummy) if that is the best route. Advice as to > which parts of the source I can cut and paste, potential similarities > with say the 1542, etc etc would be much appreciated. Thanks. Many of the free UN*X clones have drivers for this beast - the one for FreeBSD is particularly good. Found in all the usual places (ftp.cdrom.com, which happens to be a FreeBSD machine) > > Please reply via e-mail and through the newsgroup (just in case our > newsreader chokes), > > nate > > -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From cse.psu.edu!9fans-outgoing-owner Thu Oct 26 12:59:24 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <1032>; Thu, 26 Oct 1995 12:59:14 -0400 Received: by colossus.cse.psu.edu id <78626>; Thu, 26 Oct 1995 12:46:53 -0400 Received: from goggins.bath.ac.uk ([138.38.32.13]) by colossus.cse.psu.edu with SMTP id <78629>; Thu, 26 Oct 1995 11:44:52 -0400 Received: from bath.ac.uk (actually host solomon.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Thu, 26 Oct 1995 15:20:01 +0000 Original-Received: from GATEWAY by bath.ac.uk with netnews for 9fans@bath.ac.uk (9fans@cse.psu.edu) PP-warning: Illegal Received field on preceding line To: 9fans@cse.psu.edu Date: Wed, 25 Oct 1995 20:41:31 -0400 From: Olof Backing Message-ID: Organization: Plan 9 mailing list Subject: Have DEC2100 & DEC3100 - what now? Source-Info: From (or Sender) name not authenticated. Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: R Hello! I have: * DEC3100 w. b/w monitor (VR262) * DEC2100 w. VT320 terminal * 24 Mb memory to spend (like 16 + 8 on each machine) * 3 RZ55 (300 Mb) * TKZ50 * access to a CDROM (RRD42) Can I, and should I spend the time and effort in porting Plan9 for these machines? /Olof -- WHOAMI: Olof Backing EMAIL: WHERE: Royal Institute Of Technology, Stockholm obg@nada.kth.se SNAIL: Skarpnacks Alle 45, 3tr, S-128 33 SKARPNACK, Sweden VOICE: + 46 8 931619 From cse.psu.edu!9fans-outgoing-owner Thu Oct 26 13:47:27 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <9590>; Thu, 26 Oct 1995 13:47:19 -0400 Received: by colossus.cse.psu.edu id <78636>; Thu, 26 Oct 1995 13:32:54 -0400 Received: from minster.cs.york.ac.uk ([144.32.16.26]) by colossus.cse.psu.edu with SMTP id <78735>; Thu, 26 Oct 1995 12:59:58 -0400 Message-ID: X-Sender: pete@minster.york.ac.uk X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Oct 1995 11:24:38 -0400 To: 9fans@cse.psu.edu From: Pete Fenelon Subject: Re: plan 9 on ps/2s? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: R At 09:22 23/10/95 -0400, Dave wrote: >has there been a port of plan9 to microchannel pcs? we have a load of >decked-out ps/2 model 70s that we'd like use to play with plan 9 on. is >this hopeless? Off-topic, but we've had trouble getting PS/2s to run Dos and Windows properly, so I don't really hold much hope for them running anything exotic. pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dep't of Computer Science, University of York, York, YO1 5DD (+44 1904 433388) pete.fenelon@minster.york.ac.uk http://dcpu1.cs.york.ac.uk:6666/pete/pete.html From cse.psu.edu!9fans-outgoing-owner Thu Oct 26 14:59:07 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <1032>; Thu, 26 Oct 1995 14:59:05 -0400 Received: by colossus.cse.psu.edu id <78659>; Thu, 26 Oct 1995 14:44:54 -0400 Received: from plan9.att.com ([192.20.225.252]) by colossus.cse.psu.edu with SMTP id <78669>; Thu, 26 Oct 1995 14:35:02 -0400 From: jmk@plan9.att.com To: 9fans@cse.psu.edu Date: Thu, 26 Oct 1995 13:50:00 -0400 Subject: datasheets for the CMD640b and RZ1000 PCI IDE chips Message-Id: <95Oct26.143502edt.78669@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: R I've been unable to get the datasheets for these chips from the respective manufacturers so I can turn off prefetch and, in the case of the CMD at least, enable the second controller. If someone has either the datasheets and could FAX them to me (+1 908 582 4417) or can supply the missing parts of the following pseudo-code I'd be most grateful. Thanks. if controller is one of the above read some PCI config register alter some bits write the config register back From cse.psu.edu!9fans-outgoing-owner Fri Oct 27 11:09:46 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <9972>; Fri, 27 Oct 1995 11:09:42 -0400 Received: by colossus.cse.psu.edu id <78384>; Fri, 27 Oct 1995 10:51:27 -0400 Received: from ferrari.sfu.ca ([142.58.110.11]) by colossus.cse.psu.edu with SMTP id <78387>; Fri, 27 Oct 1995 10:51:08 -0400 Received: from fraser.sfu.ca (fraser.sfu.ca [142.58.110.1]) by ferrari.sfu.ca with ESMTP (8.6.12/SFU-2.6H) id HAA18392 for <9fans@cse.psu.edu> (from vanepp@sfu.ca); Fri, 27 Oct 1995 07:50:50 -0700 From: Peter Van Epp Received: by fraser.sfu.ca (8.6.12/SFU-2.6C) id OAA04861 (from vanepp@sfu.ca); Fri, 27 Oct 1995 14:50:50 GMT Date: Fri, 27 Oct 1995 10:50:50 -0400 Message-Id: <199510271450.OAA04861@fraser.sfu.ca> To: 9fans@cse.psu.edu Subject: Re: datasheets for the CMD640b and RZ1000 PCI IDE chips Newsgroups: comp.os.plan9 References: <95Oct26.143502edt.78669@colossus.cse.psu.edu> X-Newsreader: NN version 6.5.0 #5 (NOV) Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: R In comp.os.plan9 you write: >I've been unable to get the datasheets for these chips from the respective >manufacturers so I can turn off prefetch and, in the case of the CMD at least, >enable the second controller. If someone has either the datasheets and could >FAX them to me (+1 908 582 4417) or can supply the missing parts of the >following pseudo-code I'd be most grateful. Thanks. > if controller is one of the above > read some PCI config register > alter some bits > write the config register back I saw an article in the local free computer paper that said both of these chips have a number of bugs. A set of test programs and places for discussion are listed as follows: the article itself ftp.cdrom.com/.4/os2/incoming/eidete16.zip The author is Roedy Green (Roedy@bix.com) PC tech essay: http://www.mei.microm.com/rz1000/rz1000.txt Pat Duffy's Web site hhtp://warp.eecs.berkeley.edu/os2/workbench/work.htm Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada From cse.psu.edu!9fans-outgoing-owner Fri Oct 27 15:13:12 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <10090>; Fri, 27 Oct 1995 15:13:11 -0400 Received: by colossus.cse.psu.edu id <78406>; Fri, 27 Oct 1995 14:51:40 -0400 Received: from crash.cts.com ([192.188.72.17]) by colossus.cse.psu.edu with SMTP id <78404>; Fri, 27 Oct 1995 14:50:49 -0400 Received: by crash.cts.com (Smail3.1.29.1 #5) id m0t8tr3-0002JjC; Fri, 27 Oct 95 11:50 PDT Message-Id: Date: Fri, 27 Oct 1995 14:50:00 -0400 From: cwr@cts.com (Will Rose) To: 9fans@cse.psu.edu Subject: Re: datasheets for the CMD640b and RZ1000 PCI IDE chips Newsgroups: comp.os.plan9 Organization: CTS Network Services (CTSNET), San Diego, CA X-Newsreader: TIN [version 1.2 PL2] Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: R In article <95Oct26.143502edt.78669@colossus.cse.psu.edu> you wrote: : I've been unable to get the datasheets for these chips from the respective : manufacturers so I can turn off prefetch and, in the case of the CMD at least, : enable the second controller. If someone has either the datasheets and could : FAX them to me (+1 908 582 4417) or can supply the missing parts of the : following pseudo-code I'd be most grateful. Thanks. : if controller is one of the above : read some PCI config register : alter some bits : write the config register back Try Roedy Green, roedy@BIX.COM. He's done a lot of work on the problems with these controllers, and will probably know of sources. Will cwr@crash.cts.com From cse.psu.edu!9fans-outgoing-owner Fri Oct 27 15:35:43 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <10085>; Fri, 27 Oct 1995 15:35:39 -0400 Received: by colossus.cse.psu.edu id <78383>; Fri, 27 Oct 1995 15:21:36 -0400 Received: from soclab.soc.iastate.edu ([129.186.33.121]) by colossus.cse.psu.edu with SMTP id <78386>; Fri, 27 Oct 1995 15:21:19 -0400 Received: by soclab.soc.iastate.edu with sendmail-5.65 id ; Fri, 27 Oct 1995 14:20:58 -0500 Date: Fri, 27 Oct 1995 15:20:58 -0400 From: btutt@iastate.edu Message-Id: <9510271920.AA02462@soclab.soc.iastate.edu> To: 9fans@cse.psu.edu Subject: Re: datasheets for the CMD640b and RZ1000 PCI IDE chips Newsgroups: comp.os.plan9 References: <95Oct26.143502edt.78669@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: R In comp.os.plan9 you write: >I've been unable to get the datasheets for these chips from the respective >manufacturers so I can turn off prefetch and, in the case of the CMD at least, >enable the second controller. If someone has either the datasheets and could >FAX them to me (+1 908 582 4417) or can supply the missing parts of the >following pseudo-code I'd be most grateful. Thanks. > if controller is one of the above > read some PCI config register > alter some bits > write the config register back Unfortunately I dont have either... I know intel has a web page on the rz1000 chips.. and the current linux source code detects CMD640b and rz1000 and handles it... you might want to check it out. Wish i could be of more help... I'd gladly try and write a aha driver based off of the linux one, but unfortunately... I dont have the cash to afford a plan 9 Cd. :) Now if we could only figure out how to get the aic-7850's working with the linux aic7xxx driver. :) Bill Tutt btutt@iastate.edu From 9fans@cse.psu.edu Wed Nov 1 16:46:24 EST 1995 Article: 749 of comp.os.plan9 Xref: cannon.ecf comp.os.plan9:749 Path: cannon.ecf!utnut!torn!howland.reston.ans.net!plug.news.pipex.net!pipex!dish.news.pipex.net!pipex!bt!btnet!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!dundee.ac.uk!zippy.dct.ac.uk!uknet!dcl-cs!bath.ac.uk!ccsis Newsgroups: comp.os.plan9 Subject: Re: IP Implementation of Plan 9 Message-ID: <95Oct30.194310est.78638@colossus.cse.psu.edu> From: beto@plan9.CS.SU.oz.AU Date: Tue, 31 Oct 1995 06:24:38 GMT Reply-To: 9fans@cse.psu.edu Sender: ccsis@bath.ac.uk (Icarus Sparry) Organization: Plan 9 mailing list Approved: plan9mod@bath.ac.uk Lines: 22 In <9510302212.AA03541@mwtech.rent-a-guru.de> Martin Weitzel wrote: > This is not tied to any specific problem, just out of curiosity: > > Recently I gave a short introduction to Plan 9 for a couple of persons. > One question I could not answer was whether the IP implementation was > written "all fresh" or taken from any other system (e.g. the streams > based implementation of SVR4). A related question from the same person > was if multicast addressing is supported by the IP implementation of Plan 9. > Multicast is not supported in the new release. We, in basser, add multicast to the IP code, ethernet filtering and counting, and IGMP processing in user-mode. We have a 9vat application, but it's not extremely clever with missed and duplicated messages. If you are interesting in the code, or want to improve 9vat b: please mail me. beto From 9fans@cse.psu.edu Fri Nov 3 16:52:06 EST 1995 Article: 779 of comp.os.plan9 Xref: cannon.ecf comp.os.plan9:779 Newsgroups: comp.os.plan9 Path: cannon.ecf!utnut!cs.utexas.edu!academ!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!tank.news.pipex.net!pipex!uknet!dcl-cs!bath.ac.uk!ccsis From: forsyth@plan9.CS.york.ac.UK Subject: ext2fs Message-ID: <95Nov2.173200est.34208@psuvax1.cse.psu.edu> Sender: ccsis@bath.ac.uk (Icarus Sparry) Reply-To: 9fans@cse.psu.edu Organization: Plan 9 mailing list Date: Thu, 2 Nov 1995 12:25:56 GMT Approved: plan9mod@bath.ac.uk Lines: 8 /pub/plan9/bod/tapefs.bod on ftp.cs.york.ac.uk has changes that, applied to /sys/src/cmd/tapefs (make a copy first), will yield an ext2fs.c and mkfile to produce fs/ext2fs that gives read-only access to a linux ext2fs partition. it is known to work on exactly one linux partition (mine), with 1k blocks (not my idea, the linux installation chose the block size). the file has been lurking there for some time, but i forgot to mention it here. From cse.psu.edu!9fans-outgoing-owner Wed Mar 6 22:39:26 1996 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <10872>; Wed, 6 Mar 1996 22:39:18 -0500 Received: by colossus.cse.psu.edu id <78666>; Wed, 6 Mar 1996 22:25:49 -0500 Received: from plan9.cs.su.oz.au ([129.78.96.37]) by colossus.cse.psu.edu with SMTP id <78664>; Wed, 6 Mar 1996 22:25:22 -0500 From: beto@plan9.cs.su.oz.au Date: Thu, 7 Mar 1996 12:42:55 -0500 To: 9fans@plan9.cs.su.oz.au Subject: QuickCam driver Message-Id: <96Mar6.222522est.78664@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO Hi, I got a QuickCam on monday and transformed a Linux program into a Plan 9 driver which serves /dev/camera and /dev/focus. /dev/camera has the same format than /dev/screen so most of fb/* programs work well with it. For example, to display some video while() drop '#C'/camera or to get a bigger picture resample 1280 '#C'/camera | transpose .......... | 9v It has all the limitation of QuickCams, but for 109$ is a nice toy. We found it good for producing face files. If any one is interested just let me know and I'll post the driver. From cse.psu.edu!9fans-outgoing-owner Thu Mar 7 09:34:09 1996 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <1681>; Thu, 7 Mar 1996 09:34:02 -0500 Received: by colossus.cse.psu.edu id <78689>; Thu, 7 Mar 1996 09:20:35 -0500 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <78682>; Thu, 7 Mar 1996 09:19:16 -0500 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cse.psu.edu Date: Thu, 7 Mar 1996 09:21:37 -0500 Subject: Re: Unzip for Plan 9? Message-Id: <96Mar7.091916est.78682@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO ftp://ftp.cs.york.ac.uk/pub/plan9/pub/gzip.tar ftp://ftp.cs.york.ac.uk/pub/plan9/pub/unzip.tgz you might need to use the -f (force) option with gzip, because it changes behaviour based on isatty() From cse.psu.edu!9fans-outgoing-owner Thu Mar 7 15:09:38 1996 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <10025>; Thu, 7 Mar 1996 15:09:34 -0500 Received: by colossus.cse.psu.edu id <78696>; Thu, 7 Mar 1996 14:55:51 -0500 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by colossus.cse.psu.edu with SMTP id <78693>; Thu, 7 Mar 1996 14:55:33 -0500 Received: by galapagos.cse.psu.edu id <12686>; Thu, 7 Mar 1996 14:54:17 -0500 From: Scott Schwartz To: 9fans@cse.psu.edu Subject: pgp Message-Id: <96Mar7.145417est.12686@galapagos.cse.psu.edu> Date: Thu, 7 Mar 1996 14:54:11 -0500 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO Here are some diffs for pgp to get it to compile under ape. I'd like to have the 9fans look them over before sending them off to the pgp maintainers. #!/bin/rc # # command: /bin/boddle orig . # srcdir: orig # version: 826228074 # date: Thu Mar 7 14:47:54 EST 1996 # myname=$0 doextract=no fn usage{ echo $myname: usage: $myname '[-X] [src-directory]' >[1=2] exit usage } fn sigint{ rm -rf 826228074 exit interrupt } while(~ $1 -*){ switch($1){ case -X doextract=yes case -* usage } shift } switch($#*){ case 0 srcdir=orig case 1 srcdir=$1 case * usage } if(! ~ $doextract yes){ echo This shell file contains a bundle of diffs representing changes echo to original source files in the Plan 9 distribution. It will run echo against the files in echo ' ' $srcdir echo '(unless overridden by the optional source directory argument)' echo and create a directory 826228074 containing the updated files. echo It will NOT automatically update the original files. echo echo Invoke with argument -X to perform the actual extraction. exit 0 } rm -rf 826228074 mkdir 826228074 target=826228074/fileio.c echo -n '826228074/fileio.c: ' if(! test -f $srcdir/fileio.c || ! test -r $srcdir/fileio.c){ echo $srcdir/fileio.c unreadable exit unreadable } sum=`{sum < $srcdir/fileio.c} if(! ~ 92f3d44635173 $sum(1)^$sum(2)){ echo $srcdir/fileio.c is not the original distribution file exit original } cp $srcdir/fileio.c 826228074/fileio.c ed 826228074/fileio.c >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM fileio.c' 471a #endif . 470a #ifdef _PLAN9_SOURCE strcat(result, "lib/pgp"); #else . 467a #endif . 466a #ifdef _PLAN9_SOURCE s = getenv("home"); #else . wq //GO.SYSIN DD VADIM fileio.c sum=`{sum < 826228074/fileio.c} if(~ 3e7e69ed35294 $sum(1)^$sum(2)) echo if not{ echo 826228074/fileio.c checksum error creating updated file exit checksum } target=826228074/fileio.h echo -n '826228074/fileio.h: ' if(! test -f $srcdir/fileio.h || ! test -r $srcdir/fileio.h){ echo $srcdir/fileio.h unreadable exit unreadable } sum=`{sum < $srcdir/fileio.h} if(! ~ b1b4317f4854 $sum(1)^$sum(2)){ echo $srcdir/fileio.h is not the original distribution file exit original } cp $srcdir/fileio.h 826228074/fileio.h ed 826228074/fileio.h >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM fileio.h' 28a #endif . 27a #ifdef _PLAN9_SOURCE #define PGP_SYSTEM_DIR "/lib/pgp/" #else . wq //GO.SYSIN DD VADIM fileio.h sum=`{sum < 826228074/fileio.h} if(~ e63d10dc4923 $sum(1)^$sum(2)) echo if not{ echo 826228074/fileio.h checksum error creating updated file exit checksum } target=826228074/makefile echo -n '826228074/makefile: ' if(! test -f $srcdir/makefile || ! test -r $srcdir/makefile){ echo $srcdir/makefile unreadable exit unreadable } sum=`{sum < $srcdir/makefile} if(! ~ a16b56f019247 $sum(1)^$sum(2)){ echo $srcdir/makefile is not the original distribution file exit original } cp $srcdir/makefile 826228074/makefile ed 826228074/makefile >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM makefile' 153a # Plan 9, for the x86, under the the Ansi/Posix Environment (ape/psh) plan9-8: $(MAKE) all CC=cc LD=cc \ CFLAGS="$(RSAINCDIR) -DIDEA32 -DUNIX -DPORTABLE -DMAX_NAMELEN=28 \ -D_BSD_EXTENSION -D_POSIX_SOURCE -D_PLAN9_SOURCE" \ OBJS_EXT="gettimeofday.o" . wq //GO.SYSIN DD VADIM makefile sum=`{sum < 826228074/makefile} if(~ 08cde43019504 $sum(1)^$sum(2)) echo if not{ echo 826228074/makefile checksum error creating updated file exit checksum } target=826228074/more.c echo -n '826228074/more.c: ' if(! test -f $srcdir/more.c || ! test -r $srcdir/more.c){ echo $srcdir/more.c unreadable exit unreadable } sum=`{sum < $srcdir/more.c} if(! ~ 4ae91e6711934 $sum(1)^$sum(2)){ echo $srcdir/more.c is not the original distribution file exit original } cp $srcdir/more.c 826228074/more.c ed 826228074/more.c >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM more.c' 445,461c fflush(pgpout); . 416,439d 406,414d 393,403d 391c } . 253,389c fflush(pgpout); while ((c = fgetc(fp)) != EOF) putchar(c); fclose(fp); . 250,251c if ((fp = fopen(fn, "r")) == NULL) . 242,248c FILE *fp; int c; . 237,240c extern FILE *pgpout; int more_file(char *fn) . 235d 42,233d 24,40d 22d 2,19c If you want "more", you know where to find it. . wq //GO.SYSIN DD VADIM more.c sum=`{sum < 826228074/more.c} if(~ 82d2c1d4498 $sum(1)^$sum(2)) echo if not{ echo 826228074/more.c checksum error creating updated file exit checksum } target=826228074/pgp.c echo -n '826228074/pgp.c: ' if(! test -f $srcdir/pgp.c || ! test -r $srcdir/pgp.c){ echo $srcdir/pgp.c unreadable exit unreadable } sum=`{sum < $srcdir/pgp.c} if(! ~ 5a924c3b69200 $sum(1)^$sum(2)){ echo $srcdir/pgp.c is not the original distribution file exit original } cp $srcdir/pgp.c 826228074/pgp.c ed 826228074/pgp.c >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM pgp.c' 1190a # endif . 1189a # endif # ifdef SIGILL . 1188a # endif # ifdef SIGSEGV . 1187a # ifdef SIGTRAP . wq //GO.SYSIN DD VADIM pgp.c sum=`{sum < 826228074/pgp.c} if(~ 16b6ff1869271 $sum(1)^$sum(2)) echo if not{ echo 826228074/pgp.c checksum error creating updated file exit checksum } target=826228074/system.c echo -n '826228074/system.c: ' if(! test -f $srcdir/system.c || ! test -r $srcdir/system.c){ echo $srcdir/system.c unreadable exit unreadable } sum=`{sum < $srcdir/system.c} if(! ~ 30363a1238303 $sum(1)^$sum(2)){ echo $srcdir/system.c is not the original distribution file exit original } cp $srcdir/system.c 826228074/system.c ed 826228074/system.c >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM system.c' 38a #ifdef _PLAN9_SOURCE #undef UNIX int ttyctl = -1; int ttyfd = -1; void ttycbreak(void) { if (ttyfd == -1) if ((ttyfd = open("/dev/cons", 2)) < 0) perror("open /dev/cons"); if (ttyctl == -1) if ((ttyctl = open("/dev/consctl", 1)) < 0) perror("open /dev/consctl"); if (ttyfd == -1 || ttyctl == -1) { fprintf(stderr, "cannot open cons, using stdin\n"); close(ttyfd); ttyfd = -1; close(ttyctl); ttyfd = -1; ttyfd = 0; } else { write(ttyctl, "rawon", 5); } } void ttynorm(void) { close(ttyctl); ttyctl = -1; close(ttyfd); ttyfd = -1; } int getch(void) { char c; read(ttyfd, &c, 1); return(c); } #endif . wq //GO.SYSIN DD VADIM system.c sum=`{sum < 826228074/system.c} if(~ 8bd32cc338938 $sum(1)^$sum(2)) echo if not{ echo 826228074/system.c checksum error creating updated file exit checksum } target=826228074/zunzip.h echo -n '826228074/zunzip.h: ' if(! test -f $srcdir/zunzip.h || ! test -r $srcdir/zunzip.h){ echo $srcdir/zunzip.h unreadable exit unreadable } sum=`{sum < $srcdir/zunzip.h} if(! ~ 8b721d5710483 $sum(1)^$sum(2)){ echo $srcdir/zunzip.h is not the original distribution file exit original } cp $srcdir/zunzip.h 826228074/zunzip.h ed 826228074/zunzip.h >/dev/null >[2=1] <<'//GO.SYSIN DD VADIM zunzip.h' 123a # include . wq //GO.SYSIN DD VADIM zunzip.h sum=`{sum < 826228074/zunzip.h} if(~ e62ac94e10514 $sum(1)^$sum(2)) echo if not{ echo 826228074/zunzip.h checksum error creating updated file exit checksum } From cse.psu.edu!9fans-outgoing-owner Mon Mar 11 04:20:52 1996 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <813>; Mon, 11 Mar 1996 04:20:42 -0500 Received: by colossus.cse.psu.edu id <78386>; Mon, 11 Mar 1996 04:10:59 -0500 Received: from symbionics.co.uk ([158.43.6.17]) by colossus.cse.psu.edu with SMTP id <78385>; Mon, 11 Mar 1996 04:10:38 -0500 Received: from symsun3.symbionics.co.uk (sympc143.symbionics.co.uk) by symbionics.co.uk (4.1/SMI-4.1) id AA03399; Mon, 11 Mar 96 09:09:24 GMT Message-Id: <9603110909.AA03399@symbionics.co.uk> Comments: Authenticated sender is From: "Nigel Roles" To: 9fans@cse.psu.edu Date: Mon, 11 Mar 1996 04:09:15 -0500 Subject: NCR SCSI driver - new release Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO My latest effort is available in ftp://ftp.cs.york.ac.uk/pub/plan9/ngr/ncr There are two subdirectories, 9free, and src. 9free contains gzipped kernel images for 9dos and 9pcdisk, plus a modified b.com and instructions for building an NCR compatible 4 disk demo set. Src contains the source code for the kernel, and also the assembler for the microcode. This release represents the first release with mostly everything done. Specifically, * Multi-target * Synchronous negotiation * LUNs * Performance comparable to drivers for other operating systems Nigel Roles From 9fans@cse.psu.edu Wed Mar 13 15:50:09 EST 1996 Article: 1249 of comp.os.plan9 Xref: cannon.ecf comp.os.plan9:1249 Newsgroups: comp.os.plan9 Path: cannon.ecf!utcsri!newsflash.concordia.ca!news.mcgill.ca!mcrcim.mcgill.edu!bloom-beacon.mit.edu!newsxfer2.itd.umich.edu!gatech!usenet.eel.ufl.edu!warwick!niss!bath.ac.uk!ccsis From: beto@plan9.CS.SU.oz.AU Subject: devqqam.c Approved: plan9mod@bath.ac.uk Reply-To: 9fans@cse.psu.edu Sender: ccsis@bath.ac.uk (Icarus Sparry) Organization: Plan 9 mailing list Message-ID: <96Mar13.000640est.78606@colossus.cse.psu.edu> Date: Wed, 13 Mar 1996 05:19:00 GMT Lines: 678 Here is the driver for the QuickCam. You have to add the line camera0=type=qcam port=0x378 to your plan9.ini replacing port=???? for your port iobase. You have two files: #C/focus and #C/camera. For example: echo contrast 120 > '#C'/focus echo brightness 180> '#C'/focus echo whitebal 125> '#C'/focus echo width 320 > '#C'/focus echo height 240 > '#C'/focus echo width 160 > '#C'/focus echo height 120 > '#C'/focus echo width 80> '#C'/focus echo height 60 > '#C'/focus to set some values and getmap bw # gray scale color map 9v '#C'/camera while() fb/drop '#C'/camera for some photos /****************************************************************** Copyright (C) 1996 by Scott Laird Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL SCOTT LAIRD BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ******************************************************************/ /* * Ported to Plan9 by beto@cs.su.oz.au (5/3/96) */ #include "u.h" #include "../port/lib.h" #include "mem.h" #include "dat.h" #include "fns.h" #include "io.h" #include "../port/error.h" #include "devtab.h" typedef struct Qcam Qcam; struct Qcam { QLock; int inuse; int iobase; /* begging of attached parallel port */ uchar *scan; /* scan area */ int width; int height; int bpp; int mode; int contrast; int brightness; int whitebal; int port_mode; int debug; }; Qcam qcam; #define dprint if (qcam.debug) print enum{ Qdir, Qcamera, Qfocus, }; Dirtab qctab[]={ "camera", {Qcamera}, 0, 0600, "focus", {Qfocus}, 0, 0600, }; #define Nqctab (sizeof(qctab)/sizeof(Dirtab)) #define IN(x) inb(qcam.iobase+(x)) #define OUT(x,y) outb(qcam.iobase+(x), y) enum{ LPdata = 0x0, /* data reg .off */ LPstatus = 0x01, /* status reg .off */ LPctl = 0x02, /* cmd/args reg .off */ QC_UNIDIR = 1, QC_BIDIR = 2, QC_SERIAL = 3, }; void reset(void); void qcset(void); int qcsetscanmode(void); void qcscan(void); void qccmd(int); void qcwait(int val); int qcwaithand(int); uchar qcreadbyte(); int read_lpstatus(void); int read_lpcontrol(void); int read_lpdata(void); void write_lpdata(int d); void write_lpcontrol(int d); void qcctlwrite(char *, int); void qcamreset(void) { ISAConf qcconf; qcconf.port = 0x278; if(isaconfig("camera", 0, &qcconf) == 0) return; if(strcmp(qcconf.type, "qcam") != 0) return; switch(qcconf.port){ case 0x278: case 0x378: case 0x3bc: break; default: print("devqcam: bad qcam port 0x%x\n", qcconf.port); return; } qcam.iobase = qcconf.port; dprint("devqcam: port %d \n",qcam.iobase); } void qcaminit(void) { qcam.port_mode=QC_UNIDIR; qcam.width=160; qcam.height=120; qcam.bpp=6; qcam.contrast=104; qcam.brightness=180 /* was 135 */; qcam.whitebal=132; } Chan * qcamattach(char *spec) { return devattach('C', spec); } Chan * qcamclone(Chan *c, Chan *nc) { return devclone(c, nc); } int qcamwalk(Chan *c, char *name) { return devwalk(c, name, qctab, (long)Nqctab, devgen); } void qcamstat(Chan *c, char *db) { devstat(c, db, qctab, (long)Nqctab, devgen); } void qcamwstat(Chan *c, char *dp) { USED(c, dp); error(Eperm); } void qcamcreate(Chan *c, char *name, int omode, ulong perm) { USED(c, name, omode, perm); error(Eperm); } void qcamremove(Chan *c) { USED(c); error(Eperm); } Chan * qcamopen(Chan *c, int omode) { ulong pa; switch (c->qid.path) { case Qcamera: qlock(&qcam);/**/ if(waserror()){ qunlock(&qcam); nexterror(); } if (qcam.inuse) error(Einuse); qcam.inuse = 1; omode &= ~OTRUNC; if (omode != OREAD) error(Eperm); if (qcam.scan == 0) { pa = (ulong)xalloc(320*240); /* maximun possible size */ if (pa == 0) panic("qcopen bufinit"); /* It shouldn't panic ???? */ qcam.scan = (uchar *)(pa|KZERO); } qcset(); /* * I scan one photo per open which * will be returned in next reads */ qcscan(); poperror(); qunlock(&qcam);/**/ } return devopen(c, omode, qctab, (long)Nqctab, devgen); } void qcamclose(Chan *c) { if ((c->flag&COPEN) == 0) return; switch (c->qid.path) { case Qcamera: qlock(&qcam); dprint("caught in qcclose()\n"); qcam.inuse = 0; qunlock(&qcam); break; } } char qcbuf[1024]; long qcamread(Chan *c, char *a, long n, ulong offset) { int len, hlen,rem, s, i, j, hmany; char buf[300]; switch((int)(c->qid.path&~CHDIR)){ case Qdir: return devdirread(c, a, n, qctab, Nqctab, devgen); case Qcamera: /* * return a previously scanned * frame, using the same format that /dev/screen */ hlen = snprint(buf,sizeof(buf),"%11d %11d %11d %11d %11d ", 3,0,0,qcam.width,qcam.height); /* * should be a problem with returning * a small read with the header */ if (offset < hlen) { n = readstr(offset,a,n,buf); break; } offset -= hlen; len=qcam.height*qcam.width; if (offset < len) { if (n > len - offset) n=len-offset; memmove(a,qcam.scan+offset,n); } else n=0; break; case Qfocus: j=0; buf[0]=0; j+=snprint(buf,sizeof(buf),"width %d\n",qcam.width); j+=snprint(buf+j,sizeof(buf)-j,"height %d\n",qcam.height); j+=snprint(buf+j,sizeof(buf)-j,"bpp %d\n",qcam.bpp); j+=snprint(buf+j,sizeof(buf)-j,"mode %d\n",qcam.mode); j+=snprint(buf+j,sizeof(buf)-j,"contrast %d\n",qcam.contrast); j+=snprint(buf+j,sizeof(buf)-j,"brightness %d\n",qcam.brightness); j+=snprint(buf+j,sizeof(buf)-j,"whitebal %d\n",qcam.whitebal); j+=snprint(buf+j,sizeof(buf)-j,"debug %d\n",qcam.debug); n = readstr(offset,a,n,buf); break; default: error(Egreg); } return n; } long qcamwrite(Chan *c, char *a, long n, ulong offset) { int len, rem, s, i; switch((int)(c->qid.path&~CHDIR)){ case Qcamera: error(Eperm); break; case Qfocus: qlock(&qcam); if(waserror()){ qunlock(&qcam); nexterror(); } qcctlwrite(a, n); poperror(); qunlock(&qcam); break; default: error(Ebadusefd); } return n; } void qcctlwrite(char *a, int n) { int nf; char cbuf[256], *field[10]; if (n >= sizeof(cbuf)) error(Ebadarg); memmove(cbuf, a, n); if (n > 0 && cbuf[n-1] == '\n') n--; cbuf[n] = 0; nf = getfields(cbuf, field, sizeof(field), " "); if (nf == 0) error(Ebadarg); /* check range */ if (strcmp(field[0], "width") == 0 && nf == 2) { qcam.width= strtoul(field[1], 0, 10); } else if (strcmp(field[0], "height") == 0 && nf == 2) { qcam.height= strtoul(field[1], 0, 10); } else if (strcmp(field[0], "bpp") == 0 && nf == 2) { qcam.bpp= strtoul(field[1], 0, 10); } else if (strcmp(field[0], "contrast") == 0 && nf == 2) { qcam.contrast= strtoul(field[1], 0, 10); } else if (strcmp(field[0], "brightness") == 0 && nf == 2) { qcam.brightness= strtoul(field[1], 0, 10); } else if (strcmp(field[0], "whitebal") == 0 && nf == 2) { qcam.whitebal= strtoul(field[1], 0, 10); } else if (strcmp(field[0], "debug") == 0) { if (nf == 1 || strcmp(field[1], "on") == 0) qcam.debug = 1; else if (strcmp(field[1], "off") == 0) qcam.debug = 0; else error(Ebadarg); } } /* * Functions to access the * IO registers of a parallel port */ int read_lpstatus() { return IN(LPstatus); } int read_lpcontrol() { return IN(LPctl); } int read_lpdata() { return IN(LPdata); } void write_lpdata(int d) { OUT(LPdata,d); } void write_lpcontrol(int d) { OUT(LPctl,d); } /* * Reset the QuickCam and program for brightness, contrast, * white-balance, and resolution. */ void qcset() { qcsetscanmode(); reset(); /* Set the brightness. Yes, this is repetitive, but it works. * Shorter versions seem to fail subtly. Feel free to try :-). */ qccmd(0xb); qccmd(qcam.brightness); qccmd(0xb); qccmd(1); qccmd(0xb); qccmd(1); qccmd(0xb); qccmd(qcam.brightness); qccmd(0xb); qccmd(qcam.brightness); qccmd(0xb); qccmd(qcam.brightness); qccmd(0x11); qccmd(qcam.height); qccmd(0x13); if(qcam.bpp==4) qccmd(qcam.width/2); else qccmd(qcam.width/4); qccmd(0x11); qccmd(qcam.height); qccmd(0x13); if(qcam.bpp==4) qccmd(qcam.width/2); else qccmd(qcam.width/4); /* I still don't know what these do! */ qccmd(0xd); qccmd(0x1); qccmd(0xf); qccmd(0x7); qccmd(0x19); qccmd(qcam.contrast); qccmd(0x1f); qccmd(qcam.whitebal); } /* Decide which scan mode to use. There's no real requirement that * the scanmode match the resolution in q->height and q-> width -- the * camera takes the picture at the resolution specified in the * "scanmode" and then returns the image at the resolution specified * with the resolution commands. If the scan is bigger than the * requested resolution, the upper-left hand corner of the scan is * returned. If the scan is smaller, then the rest of the image * returned contains garbage. */ int qcsetscanmode() { switch (qcam.width) { case 80: if(qcam.height==60) qcam.mode=8; break; case 160: if(qcam.height==120) qcam.mode=4; break; case 320: if(qcam.height==240) qcam.mode=0; break; } if (qcam.mode<0) { print("Error: unsupported resolution (%d x %d)!\n", qcam.width,qcam.height); return 1; } switch (qcam.bpp) { case 4: break; case 6: qcam.mode+=2; break; default: print("Error: Unsupported bit depth\n"); return 1; } return 0; } /* Reset the QuickCam. This uses the same sequence the Windows * QuickPic program uses. Someone with a bi-directional port should * check that bi-directional mode is detected right, and then * implement bi-directional mode in qc_readbyte(). */ void reset() { int bidir; write_lpcontrol(0x20); write_lpdata(0x75); bidir=read_lpdata()!=0x75; if(bidir) { print("Bidirectional port found. Hack qc_readbyte to use.\n"); qcam.port_mode=QC_BIDIR; } /* usleep(250);*/ write_lpcontrol(0xb); /* usleep(250); */ write_lpcontrol(0xe); } /* qc_command is probably a bit of a misnomer -- it's used to send * bytes *to* the camera. Generally, these bytes are either commands * or arguments to commands, so the name fits, but it still bugs me a * bit. See the documentation for a list of commands. */ void qccmd(int command) { int status; write_lpdata(command); /* These pauses seem to be needed for some reason. */ qcwait(1); write_lpdata(command); qcwait(1); write_lpdata(command); write_lpcontrol(6); qcwaithand(1); status=read_lpstatus(); write_lpcontrol(0xe); qcwaithand(0); status=read_lpstatus(); } /* qc_waithand busy-waits for a handshake signal from the QuickCam. * Almost all communication with the camera requires handshaking. */ int qcwaithand(int val) { if(val) while(!(read_lpstatus()&8)); else while((read_lpstatus()&8)); return 0; } /* Read a byte from the QC. This is only used from qcscan. Notice that there are places for three modes of operation: unidirectional, bidirectional, and serial. Right now only unidirectional is implemented. Bidirectional uses the unidirectional code. Serial code is just a case: stub, just in case someone wants to plug a Mac QuickCam into a 230.4k serial port and see what happens. Wishful thinking. */ uchar qcreadbyte() { int ret; int hi,lo; switch (qcam.port_mode) { case QC_UNIDIR: /* Unidirectional Port */ case QC_BIDIR: /* Bi-directional Port same as uni-dir for now. */ write_lpcontrol(6); qcwaithand(1); hi=read_lpstatus()&0xf0; write_lpcontrol(0xe); qcwaithand(0); lo=(read_lpstatus()&0xf0)>>4; ret=hi|lo; break; case QC_SERIAL: /* Serial Interface. Just in case.*/ default: print("Mode %d not supported\n",qcam.port_mode); ret=0; break; } return ret; } /* Read a scan from the QC. This takes the qcam structure and * requests a scan from the camera. It sends the correct instructions * to the camera and then reads back the correct number of bytes. In * previous versions of this routine the return structure contained * the raw output from the camera, and there was a 'qc_convertscan' * function that converted that to a useful format. In version 0.3 I * rolled qc_convertscan into qc_scan and now I only return the * converted scan. The format is just an one-dimensional array of * characters, one for each pixel, with 0=black up to n=white, where * n=2^(bit depth)-1. Ask me for more details if you don't understand * this. */ void qcscan() { uchar *scp; int i=0; unsigned int a=0,b=0; int len; len=qcam.height*qcam.width; scp=qcam.scan; qccmd(0x7); qccmd(qcam.mode); /* * I hack the byte capture a bit mainly to: * - expand 4 o 6 to 8bit (?????) * - stop color invertion * -- beto */ while(i>4))&0xf; scp[i++]=(16-a)&0xf;*/ scp[i++]=(a & 0xf0) | ((a>>4) &0xf); scp[i++]=((a << 4) & 0xf0) | (a&0xf); break; case 6: /* In 6bpp mode the first pixel is in the high 6 bits of the * first byte, the second pixel is the two remaining bits from * that byte plus the 4 high bits from the second byte. The * third pixel is the 4 remaining bits from the second byte plus * the two high bits of the third byte, and the 4th pixel is the * remaining six bits from the third byte. Repeat until desired * effect is achieved. */ /* * I should compact this a bit * One line gets the byte and the other expands to * 8 bits - beto. */ a=qcreadbyte(); scp[i]=a >> 2; scp[i] = (scp[i] << 2 | ((scp[i] >> 4) & 0x3)); i++; b=a; a=qcreadbyte(); scp[i]=(b&3)<<4|(a>>4); scp[i] = (scp[i] << 2 | ((scp[i] >> 4) & 0x3)); i++; b=a; a=qcreadbyte(); scp[i]=(b&0xf)<<2|(a>>6); scp[i] = (scp[i] << 2 | ((scp[i] >> 4) & 0x3)); i++; scp[i]=(a&0x3f); scp[i] = (scp[i] << 2 | ((scp[i] >> 4) & 0x3)); i++; break; default: print("Unknown bit depth in qcscan. Exiting.\n"); } } reset(); } /* THIS IS UGLY. I need a short delay loop -- somthing well under a millisecond. Unfortunately, adding 2 usleep(1)'s to qc_command slowed it down by a factor of over 1000 over the same loop with 2 usleep(0)'s, and that's too slow -- qc_start was taking over a second to run. This seems to help, but if anyone has a good speed-independent pause routine, please tell me. -- Scott */ void qcwait(int val) { int i; while(val--) for(i=0;i<50000;i++); } From cse.psu.edu!9fans-outgoing-owner Sat Mar 30 15:48:15 1996 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <9778>; Sat, 30 Mar 1996 15:48:12 -0500 Received: by colossus.cse.psu.edu id <79029>; Sat, 30 Mar 1996 15:38:20 -0500 Received: from research.att.com ([192.20.225.4]) by colossus.cse.psu.edu with SMTP id <79035>; Sat, 30 Mar 1996 15:34:03 -0500 Received: from research.att.com by ns; Sat Mar 30 15:22:08 EST 1996 Received: from allegra.tempo.att.com by research; Sat Mar 30 15:19:58 EST 1996 Received: from ode.tempo.att.com by allegra.tempo.att.com; id AA14898; Sat, 30 Mar 96 15:16:07 EST Received: by ode.tempo.att.com; id AA19889; Sat, 30 Mar 96 15:19:50 EST Date: Sat, 30 Mar 1996 15:19:49 -0500 From: Eran Gabber Subject: a driver for MPEG-1 playback card is available To: 9fans@cse.psu.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO A driver for Talisman XL MPEG-1 playback card is available. The driver was written by Eran Gabber of the Information Systems Research Department at Bell Labs. It is derived from a FreeBSD driver by Brian E. Litzinger . Talisman XL is a hardware MPEG-1 playback card for ISA bus. It displays full motion video in a VGA window and/or generates NTSC signal. In particular, MPEG decoding, picture resizing and video overlay are all done in hardware. However, it doesn't use DMA due to its complex architecture. The driver is placed in the public domain. It can be freely distributed, provided the copyright and these terms are retained, in this and all derived works. The driver is provided AS-IS, without any warranty. The driver is NOT a part of the Plan9 distribution. To install the driver, you should modify two kernel source files (clock.c and fns.h). This means that you will have to take some care in applying future patches to these source files. See the installation instructions. The driver was tested on Globalyst 630 PCs (100MHz and 120MHz) and on a Micron Electronics Millennia (133MHz Pentium) running Plan9. The driver is available from . This page also points at a copyright disclaimer and installation instructions. Please read both carefully. Please send me your bug reports, comments, and suggestions. If you use the driver, please send me a note. I don't promise to support this driver, but I will do my best... Eran Gabber Eran Gabber E-mail: eran@bell-labs.com Bell Labs, Room MH 2C-234A http://cm.bell-labs.com/is/who/eran 600 Mountain Avenue Phone: 1-908-582-4354 Murray Hill, NJ 07974 Fax: 1-908-582-5809 From cse.psu.edu!owner-9fans Wed Sep 11 13:42:22 1996 Received: from cse.psu.edu ([130.203.3.50]) by cannon.ecf.toronto.edu with SMTP id <12100>; Wed, 11 Sep 1996 13:42:15 -0400 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id NAA05645; Wed, 11 Sep 1996 13:37:37 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Wed, 11 Sep 1996 13:36:40 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id NAA05552 for 9fans-outgoing; Wed, 11 Sep 1996 13:35:58 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by cse.psu.edu (8.7.5/8.7.3) with SMTP id NAA05548 for <9fans@cse.psu.edu>; Wed, 11 Sep 1996 13:35:48 -0400 (EDT) Received: from research.research.bell-labs.com by dirty; Wed Sep 11 13:35:40 EDT 1996 Received: from allegra.tempo.att.com by research; Wed Sep 11 13:34:29 EDT 1996 Received: from ode (ode.tempo.att.com) by allegra.tempo.att.com; id AA04061; Wed, 11 Sep 96 13:34:30 EDT Received: by ode; id AA01546; Wed, 11 Sep 96 13:34:29 EDT Date: Wed, 11 Sep 1996 13:34:28 -0400 From: Eran Gabber Reply-To: Eran Gabber Subject: Talisman X driver version 2.0 To: 9fans@cse.psu.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Status: RO Version 2.0 of a driver for Talisman X MPEG decoder card is available from . It was tested on Globalyst 630 PCs (100MHz and 120MHz) and on a Micron Electronics Millennia (133MHz Pentium) running Plan9. Changes in version 2.0: - more frequent calls to scheduler during lengthy data transfers - support for loading color lookup table It still supports only 640x480 screen resolution. The hardware: Talisman X is a hardware MPEG-1 playback card for ISA bus. It displays full motion video in a VGA window and/or generates NTSC signal. In particular, MPEG decoding, picture resizing and video overlay are all done in hardware. However, this card doesn't support DMA. All data transfers are done in software. Disclaimer: The driver is placed in the public domain. It can be freely distributed, provided the copyright and these terms are retained, in this and all derived works. The driver is provided AS-IS, without any warranty. The driver is NOT a part of the Plan9 distribution. To install the driver, you should modify two kernel source files (clock.c and fns.h). This means that you will have to take some care in applying future patches to these source files. See the installation instructions. Please send me your bug reports, comments, and suggestions. If you use the driver, please send me a note. Regards, Eran From cse.psu.edu!owner-9fans Tue Sep 24 06:46:21 1996 Received: from cse.psu.edu ([130.203.3.50]) by cannon.ecf.toronto.edu with SMTP id <709>; Tue, 24 Sep 1996 06:46:17 -0400 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id GAA03953; Tue, 24 Sep 1996 06:46:34 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Tue, 24 Sep 1996 06:46:03 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id GAA03916 for 9fans-outgoing; Tue, 24 Sep 1996 06:45:56 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.cs.york.ac.uk (forsyth@p9auth.cs.york.ac.uk [144.32.33.120]) by cse.psu.edu (8.7.5/8.7.3) with SMTP id GAA03912 for <9fans@cs.psu.edu>; Tue, 24 Sep 1996 06:45:51 -0400 (EDT) From: forsyth@plan9.cs.york.ac.uk Message-Id: <199609241045.GAA03912@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 24 Sep 1996 06:50:09 -0400 subject: keyboard map Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Status: RO there is a package in ftp://ftp.cs.york.ac.uk/plan9/kbmap.tgz that provides an initial version of small changes to /sys/src/9/pc/kbd.c and a new /sys/src/9/port/devkbmap.c to allow the keyboard maps to be set for non US keyboards. there are instructions in the README in the package. contents: term% pub/gzip -f -d ; Sun, 17 Nov 1996 16:16:42 -0500 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id QAA07572; Sun, 17 Nov 1996 16:14:41 -0500 (EST) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Sun, 17 Nov 1996 16:06:50 -0500 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id QAA07473 for 9fans-outgoing; Sun, 17 Nov 1996 16:06:24 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by cse.psu.edu (8.7.5/8.7.3) with SMTP id QAA07465 for <9fans@cse.psu.edu>; Sun, 17 Nov 1996 16:06:18 -0500 (EST) Received: from research.att.com by ns; Sun Nov 17 16:05:02 EST 1996 Received: from corona.research.att.com by research; Sun Nov 17 16:04:33 EST 1996 Received: (from rsc@localhost) by corona.research.att.com (8.7.5/8.7) id QAA20402 for 9fans@cse.psu.edu; Sun, 17 Nov 1996 16:04:32 -0500 (EST) Date: Sun, 17 Nov 1996 16:04:32 -0500 Message-Id: <199611172104.QAA20402@corona.research.att.com> From: Russ Cox To: 9fans@cse.psu.edu Subject: effort duplication Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Status: R has anyone written an smb client for plan 9? (smb is the network file system protocol used by win/nt, 95, wfwg, etc.) has anyone written a mac hfs file system srv? has anyone added midi support to devaudio? (for the sound blaster, that is) russ From cse.psu.edu!owner-9fans Sun Nov 17 18:34:37 1996 Received: from cse.psu.edu ([130.203.3.50]) by cannon.ecf.toronto.edu with SMTP id <1420>; Sun, 17 Nov 1996 18:34:32 -0500 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id SAA08618; Sun, 17 Nov 1996 18:33:53 -0500 (EST) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Sun, 17 Nov 1996 18:29:55 -0500 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id SAA08546 for 9fans-outgoing; Sun, 17 Nov 1996 18:29:48 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from galapagos.cse.psu.edu (root@galapagos.cse.psu.edu [130.203.2.12]) by cse.psu.edu (8.7.5/8.7.3) with SMTP id SAA08542 for <9fans@cse.psu.edu>; Sun, 17 Nov 1996 18:29:43 -0500 (EST) Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Sun, 17 Nov 1996 18:29:06 -0500 To: 9fans@cse.psu.edu Subject: Re: effort duplication In-reply-to: Your message of "Sun, 17 Nov 1996 16:04:32 EST." <199611172104.QAA20402@corona.research.att.com> Date: Sun, 17 Nov 1996 18:29:05 -0500 From: Scott Schwartz Message-Id: <96Nov17.182906est.12684@galapagos.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Status: R One more for the list: Anyone done a screen blanker? From cse.psu.edu!owner-9fans Sun Nov 17 20:32:32 1996 Received: from cse.psu.edu ([130.203.3.50]) by cannon.ecf.toronto.edu with SMTP id <2215>; Sun, 17 Nov 1996 20:32:27 -0500 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id UAA09781; Sun, 17 Nov 1996 20:31:32 -0500 (EST) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Sun, 17 Nov 1996 20:28:18 -0500 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id UAA09712 for 9fans-outgoing; Sun, 17 Nov 1996 20:28:11 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from nol.net (photon@dazed.nol.net [206.126.32.101]) by cse.psu.edu (8.7.5/8.7.3) with ESMTP id UAA09708 for <9fans@cse.psu.edu>; Sun, 17 Nov 1996 20:28:03 -0500 (EST) Received: from localhost (photon@localhost) by nol.net (8.8.2/NOL - 8.*) with SMTP id TAA08075 for <9fans@cse.psu.edu>; Sun, 17 Nov 1996 19:27:44 -0600 (CST) X-AUTH: NOLNET SENDMAIL AUTH Date: Sun, 17 Nov 1996 20:27:43 -0500 From: Brandon Black To: 9fans@cse.psu.edu Subject: effort duplication.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Status: R Along the lines of the "effort duplication" problem.. I have a few other wishlist items which I've been considering trying to work on (some are hopelessly beyond my skill level though)... An audio CD player... Terminal emulators like the hp2621 one, for more common term types like vt10[02], vt220, xterm, etc... drivers for some popular PCI FDDI cards... Fast Ethernet cards would be nice too, but FDDI is of course much better :) Maybe it would make all of this easier and encourage people a little more if someone were to set up a "project registry" of who is working on what, and what the status of their project is... make it easy to see if something you were thinking about is already in the works, and who's doing it. All it would take is a concise one-entry-per-line text file maintained on an ftp site by someone who has a few minutes left over each day.