hwt@.uucp (Henry Troup) (09/18/89)
In article <7370001@hpfcso.HP.COM> rjn@hpfcso.HP.COM (Bob Niland) writes: > >HP's "pathetic 1/4" tape cartridge philosophy" consisted of getting into the >cartridge tape game about 5 years before QIC, back when there were no >obvious standards other than the one HP chose, the 3M "HCD" format. HCD has >some unique advantages (random access, update-in-place, ECC) that are too >widely used to abandon. It was also consistent with HP's previous tape systems. I remember an HP BASIC calculator that had a sectored cassette tape system, back about 1974 (I was in high school). My first job was on that machine. Nonetheless, tapes that can only to pre-formatted by the factor are a rather odd idea. utgpu!bnr-vpa!bnr-fos!hwt%bnr-public | BNR is not | All that evil requires hwt@bnr (BITNET/NETNORTH) | responsible for | is that good men do (613) 765-2337 (Voice) | my opinions | nothing.
kinsell@hpfcdj.HP.COM (Dave Kinsell) (09/20/89)
> (Michael Helm) > We did >have some trouble initially with the unusual connector[1] HP uses on >its SCSI board, but once that was overcome everything's spun along >just fine. I haven't tried any other 3rd party stuff yet. ----- >[1] Just unusual for our environment. HP uses a centronics-style >cable, & in our Sun-oriented environment we were used to Sun's DB-50 >style SCSI connectors. [I hope you can figure out what I mean, that's >not the correct terminology for these connectors.] But I think both >connector styles are kosher for the SCSI bus. Compatible centronics >connectors were a bother to find, however. The 'unusual connector' you refer to is Alternative 2 found in Appendix D of the SCSI standard. The DB-50 used by SUN is not contained in the standard (nor in the SCSI-2 draft). I don't know why they selected it, but it sure ain't standard. Dave Kinsell kinsell@hpfcmb.HP.COM
darrylo@hpnmdla.HP.COM (Darryl Okahata) (09/20/89)
In comp.sys.hp, rer@hpfcdc.HP.COM (Rob Robason) writes: > > >Please HP, WAKE UP TO THESE COMPLAINTS. > > Or at least respond.... [ ... ] > I can tell you that complaining to HP *DOES* help your cause. This > discussion group gets pretty wide readership in the lab at HP, though we > are reserved about responding because we really can't make commitments > to customers. I would like to re-emphasize Rob's statement that commenting here does help your cause (and those of others). I'm not trying to say that you should not go through normal channels (like your SE/FE), but commenting here does not hurt (you should still go through normal channels). There are many people, in many different HP divisions, that read comp.sys.hp. Perusing comp.sys.hp, I've noticed HP people responding from HP divisions in Fort Collins (CO -- 2 different divisions), Sunnyvale (CA), Cupertino (CA), and Santa Rosa (CA). Many times, someone will copy a note from comp.sys.hp and post it to one of HP's internal newsgroups (and there are many). For example, the note that originally said "Please HP, WAKE UP TO THESE COMPLAINTS.", was copied to an HP internal newsgroup and is currently generating a lively discussion. We can't really discuss what is going on, but we do appreciate your input. I would like to answer many of the questions asked on comp.sys.hp, but I don't know enough about sendmail, obscure facets of networking, cu(1), or hpwm (I use twm). It's better to let people from the divisions that produce the product to answer questions about it. Now, if someone asked a question about Emacs or microwave CAE .... -- Darryl Okahata darrylo%hpnmd@hpcea.HP.COM
scott@grlab.UUCP (Scott Blachowicz) (09/20/89)
In article <3822@helios.ee.lbl.gov> mike@fionn.lbl.gov (Michael Helm) writes: > Doesn't / didn't Apollo have some feature like that, you could > manufacture a mixed-architecture executable? I don't think this > is based on emulation, but rather had different instruction set- > based executables rolled up together. What I remember from having worked on a DOMAIN workstation a few years ago is... -Your "preferred" os-type was kept in an environment variable (I forget what it was called, but I'll call it $SYS). -$SYS could be set to things like SYSV, BSD4_2, or DOMAIN (again I don't remember the exact values). -Symbolic links could dereference environment variables, so things like /bin were really symbolic links to /$SYS/bin. This gets you the proper executables. -The process of loading a program could specify a specific $SYS for the executable to be produced or leave it as generic. The code I was working on at the time made some SYSV calls, so I had to load a specific to SYSV. The problem with that was that any sub-processes would inherit the $SYS setting if they weren't already specific to a certain os-type. (this includes the symbolic links). So I would run with a shell/$SYS for BSD, then run my program. When I want to run a new command it is referencing the /SYSV/bin directories, etc. Kind of confusing... keep in mind, this was about 3 years ago now, so things may have changed. I did like the idea of having symbolic links being able to dereference environment variables. It kind of gives you the same thing as HP's Context Dependent Files for some simple cases. For instance, if I want to do development on both 300 and 800 systems to the same file system, I could just setup a directory structure like this... case "`uname -m`" in 9000/8*) machine_type=hp800;; 9000/3*) machine_type=hp300;; esac ... mkdir srcs srcs/hp300 srcs/hp800 ln -s 'srcs/$machine_type' compiled ... cc -o compiled/foo.o -c foo.c -- Scott Blachowicz E-mail: scott@grlab.UUCP USPS: Graphicus ..or.. ...!hpubvwa!grlab!scott 150 Lake Str S, #206 VoicePh: 206/828-4691 Kirkland, WA 98033 FAX: 206/828-4236
fritz@hpfclp.SDE.HP.COM (Gary Fritz) (09/22/89)
> > Incredibly unlikely. This would require an entire virtual machine to be > > written to emulate the 68K on the HP-PA... Such an effort would be almost > > guaranteed to have significantly greater than a 5-10% performance hit... > > While I don't for a minute believe it would be easy to accomplish > what I'm talking about, ... It certainly wouldn't, but that's not the issue. Writing a 68K virtual machine on the 800 would be comparable to writing an 80x86 VM. Have you ever used the SoftPC product? It works just great, except it eats your 800. Emulating a dissimilar architecture is a lot of work for the *computer* as well as the programmer. I can't fathom how you could expect a 5-10% performance difference! Gary Fritz
burzio@mmlai.UUCP (Anthony Burzio) (09/27/89)
In article <7540040@hpfclp.SDE.HP.COM>, fritz@hpfclp.SDE.HP.COM (Gary Fritz) writes: > It certainly wouldn't, but that's not the issue. Writing a 68K virtual > machine on the 800 would be comparable to writing an 80x86 VM. Have you > ever used the SoftPC product? It works just great, except it eats your 800. > Emulating a dissimilar architecture is a lot of work for the *computer* > as well as the programmer. I can't fathom how you could expect a 5-10% > performance difference! Odd, SoftPC doesn't gnaw on my 9000/360 or my 9000/370... Remember, PCs have this nasty habit of going into polling loops to read input. This would suck all the marrow out of a processor indeed! Emulating a well behaved operating system, however, shouldn't be such a problem :-) ********************************************************************* Tony Burzio * Cats are natures' dog food... Martin Marietta Labs * mmlai!burzio@uunet.uu.net * *********************************************************************