Hi folks:
I am new to the classiccmp list. I am an EE, and collect teletype machines
and HP test gear. My first computer was an RCA VIP 1802-based board. My
second was an Apple II. I got to play with some bigger stuff when I worked
at Cray Research a decade ago. But I digress.
I have also been collecting HP 85 computer stuff (85A, 85B, 3"/5"/8"
drives, roms, cards...), and I just got a 9915A, which is the industrial
version of the HP 85A (cpu-only in a half-rack box).
This 9915A does not have the tape drive (option 001), but has the operator
interface card (opt 002), which provides connectors for keyboard (DB-25F),
control (DB-15F), and video (BNC). The problem is, I have no keyboard,
monitor, or documentation of any sort for the 9915. I have most of the
useful 85 docs (short of the service manual), but nothing on the 9915.
Judging from the number of pcb connections to the keyboard connector, I'd
guess it uses a special parallel keyboard. I found reference to a 98155A
keyboard in a post about a 9915B (85B-compatible), and I presume that is
the same keyboard used with the A version.
I hooked the video up to the composite input of a tv, and saw text and
graphics when I ran the self-test from the front-panel buttons of the 9915.
The image seemed wider than the screen, and I'm not sure if is just my tv
adjustment, or if the video signal is not quite ntsc composite.
As for the control connector, I have no idea what that might be used for.
There is also a little board inside that has eight sockets, four of which
are populated with 2732 eproms. I am wondering whether this is part of the
cpu system, or if it is for embedded program storage like the programmable
rom card for the 85.
I presume that I can hook up a disk with an hp-ib card (and rom), so it
should be usable once I find a keyboard and appropriate monitor.
Anyone have any docs/info/tidbits/keyboard...?
thanks,
gil smith
;-----------------------------------------------------------
; vaux electronics, inc. 480-354-5556
; http://www.vauxelectronics.com (fax: 480-354-5558)
;-----------------------------------------------------------
> > I also have a HP 9915A in my possesion. Useless without keyboard and I also
> >have only documentation for the HP-85.
>
> Maybe I should back up. You do know that the 9915 will read HP-85 tapes
> and run the HP-85 programs don't you? The HP-85 is inteneded to be the
> developement system for the 9915.
Yes, but I also don't have a HP-85 and when I had a HP-85 I could run programs
on that instead of the 9915 :). But it's not really an important matter; I just
would like to use the 9915 sometime.
> > This sounds like they are absolute unobtainium today? I'd better start
> looking
> >for a HP-85, only they seem to want quite some money when I see them on
> >eBay :).
>
> Are you kidding? I've seen plenty of them go cheap. But you should really
> look for a lot better machine like the 87XM. They have a lot more memory and
> have a number of ROMs built-in. Take a look at <http://www.ebbsoft.com>. It
> has some comparisions of the various models.
Unobtainium was related to the development kit for eproms. As for HP-85's, I'm
located in Europe and haven't seen them much around here. Last one I remember
was on eBay.de and it went for quite some money (over EUR 100,-?), but I
haven't really looked that hard. I know there's a friend looking for a cheap
one for couple of years and I don't think he has already found one. But I got
offered one by e-mail, so maybe I'll have one soon :).
There's also an industrial surplus site that sometimes has them, but the last
time I when they had one, it was already reserved for someone else. They did
have some other nice industrial computers.
greetings,
Michiel
Here's what came in my last acquisition of HP gear that I started to unpack
today....
(2) HP 2113E cpu's in impeccably mint condition. They look refurbed (no dust
at all). The have been tested and run diags perfectly. Each one has 512KW,
DCPC, M.E.M., Mem Protect, and 2102E memory controllers
One has loader roms: 264x terminal, 7970 magtape {YES!}, 79xx Disc, CS80
disc
The other has loader roms: 264x terminal, 7970 magtape, 79xx Disc, and
7905/06/20/25 disc
Here's the cards between the two...
(2) 13037 disc subsystem interfaces
(2) TBG
(2) BACI 12966A
(2) Line Printer 26099A
(2) BUS I/O
(5) GRD TRU IN/OUT
and..... a 5060-6282 prototyping board!
Other items in the racks...
13037D disc subsystem controller (this one is MINT!)
13037B disc subsystem controller
12979B I/O expansion chassis & PS
(2) 7906D disc drives (both appear to be in extremely clean condition)
(2) standard cream colored HP racks
Much fun!
Jay West
> Anyone want to share their secret?
a piece of dry ice? My father used it to freeze the adhesive
for the linoleum floor in our kitchen, and the old squares
came right up...
maybe it will work better than the cold from the air can...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | email: gentry at zk3.dec.com (work) |
| Unix Support Engineering Group | mbg at world.std.com (home) |
| Hewlett Packard | (s/ at /@/) |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 (DEC '77-'98) | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+
Hello all,
As part of a recent eBay win, I acquired an Orion Instruments Unilab II. I
have cables/software for the Rockwell 65/11EAB, and am looking for
cables/software for any other processor, especially the 1802, Z-80, 8080,
8088. If anyone has software available, and cabling diagrams, please let me
know! I have complete docs available, as well as the software for the
65/11EAB... I'd also be willing to write out a cable diagram for the
65/11EAB.
Thanks!
Rich B.
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
>From: "Ross Archer" <archer(a)topnow.com>
>
>"Dwight K. Elvey" wrote:
>>
>> >From: "Ross Archer" <dogbert(a)mindless.com>
>> >
>> >Jerome H. Fine wrote:
>> >
>> >>>Jim Kearney wrote:
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >>>I just had an email exchange with someone at Intel's Museum
>> >>>(http://www.intel.com/intel/intelis/museum/index.htm)
>> >>>
>> >>>
>> >>
>> >>Jerome Fine replies:
>> >>
>> >>I am not sure why the information is so blatant in its
>> >>stupid attempt to ignore anything but Intel hardware
>> >>as far a anything that even look like a CPU chip, but
>> >>I guess it is an "Intel" museum.
>> >>
>> >>Of course, even now, Intel, in my opinion, is so far
>> >>behind from a technical point of view that is is a sad
>> >>comment just to read about the products that were
>> >>way behind, and still are, the excellence of other
>> >>products. No question that if the Pentium 4 had been
>> >>produced 10 years ago, it would have been a major
>> >>accomplishment.
>> >>
>> >Harsh! :)
>> >
>> >Guess it depends on what you mean by "far behind from a
>> >technical point of view."
>> >
>> >If you mean that x86 is an ugly legacy architecture, with
>> >not nearly enough registers, an instruction set which
>> >doesn't fit any reasonable pipeline, that's ugly to decode
>> >and not particularly orthogonal, that from purely technical
>> >reasons ought to have died a timely death in 1990,
>> >I'd have to agree.
>> >
>> >However, look at the performance. P4 is up near the
>> >top of the tree with the best RISC CPUs, which have
>> >the advantage of clean design and careful evolution.
>> >
>> >It surely takes a great deal of inspiration, creativity,
>> >and engineering talent to take something as ill-suited
>> >as the x86 architecture and get this kind of performance
>> >out of it. IMHO.
>> >
>> >In other words, making x86 fast must be a lot like
>> >getting Dumbo off the air. That ought to count as
>> >some kind of technical achievement. :)
>>
>> ---snip---
>>
>> It is all done with smoke and mirrors.
>
>Anything the results in a net faster CPU isn't, in my book,
>akin to smoke and mirrors.
>
>If anyone's guilty of "smoke and mirrors", it's probably
>Intel by making a ridiculous long (20-24 stage) pipeline
>just to allow the wayupcrankinzee of clock rates so they can
>be first CPU to X Ghz. Why not a 50 stage pipeline that hits
>8 Ghz, nevermind the hideous branch-misprediction penalties
>and exception overhead?
>
>
>> We do the same
>> here at AMD. The trick is to trade immediate execution
>> for known execution. The x86 code is translated to run
>> on a normal RISC engine.
>
>Yes, and this in and of itself must be rather tricky, no?
>X86 instructions are variable-length, far from load/store,
>have gobs of complexity in protected nonflat mode, etc.
>I'd bet a significant portion of the Athlon or P4 is devoted
>just to figuring out how to
>translate/align/schedule/dispatch
>such a mess with a RISC core under the hood. :)
It doesn't take as much as one would think but it is a hit
on speed and space. Still, the overall hit is really quite
small.
>
>> This means that the same tricks
>> on a normal RISC engine would most likely only buy about
>> a couple percent. It would only show up on the initial
>> load of the local cache. Once that is done, there is
>> really little difference.
>> Choices of pipeline depth, out of order execution, multiple
>> execution engines and such are just the fine tuning.
>> Intel, like us is just closer to the fine edge of what
>> the silicon process can do than anything tricky that
>> people like MIPS don't know about.
>
>Well, why isn't something elegant like Alpha, HP-PA, or MIPS
>at the top of the performance tree then? (Or are they and
>I'm
>just not aware of the latest new products.)
>
>My pet theory is that the higher code density of x86
>vs. mainline RISC helps utilize the memory subsystem
>more efficiently, or at least overtaxes it less often.
>The decoding for RISC is a lot simpler, but
>if the caching systems can't completely compensate for the
>higher
>memory bandwidth requirements, you're stalling more often or
>limiting
>the maximum internal CPU speed indirectly due to the
>mismatch.
>And decoding on-chip can go much faster than any sort of
>external
>memory these days.
This is why the newer processor chips are really a memory
chip with some processor attached, rather than a processor
with some memory attached. We and Intel are turning into
RAM makers. Memory bandwidth is on the increase but it
isn't keeping up with chip speed.
Still, I don't understand why many are not going to more
efficient memory optimization than apparent execution speed.
The compiler writers have a ways to go. The day is gone
when pinhole optimization buys much. Keeping the process
in on chip cache is really the important thing. There isn't
an application out there that if one removed the large data
array and image bit tables, couldn't completely fit in the
caches that are being used today. The compilers just don't
write code well enough to keep the size down. It is just
that we've gotten into the poor choice of languages and poor
connection of software writers to the actual machine code
that is run.
Just my opinion.
Dwight
>
>This isn't really a discussion for classiccmp, but I
>couldn't
>resist since I'm sure at least some folks enjoy
>speculationalism
>on such topics. :)
>
>
>>
>> On a separate subject, I was very disappointed in the
>> Intel Museum. I'd thought it might be a good place to
>> research early software or early IC's. They have vary
>> little to offer to someone looking into this level of
>> stuff. Any local library has better references on this
>> kind of stuff ( and that isn't saying much ).
>> Dwight
>
>n
>
"Dwight K. Elvey" <dwightk.elvey(a)amd.com> wrote:
> Still, I don't understand why many are not going to more
> efficient memory optimization than apparent execution speed.
> The compiler writers have a ways to go. The day is gone
> when pinhole optimization buys much. Keeping the process
> in on chip cache is really the important thing.
As someone who writes code that goes through compilers, the reason why
I don't think too hard about the on-chip cache is because I have no
idea about the size or architecture of that on-chip cache. Well,
I have some idea, and that's that I can't count on it.
OK, so the products I work on are sold as portable C source that
is expected to build and run on a bunch of different processors,
some of which don't have any cache but may be clocked slow
enough for SRAM to keep up. I may not be the programmer you have
in mind.
So, let's take instead the case of someone writing code to run on
Win32. Reading the side of a box for something newish like that,
we could narrow it a bit further, to Win98, WinME, and Win2000
(hmm, maybe that's why this thing was in the closeouts pile, no WinXP).
That could be running on anything made in the last four years, and
what have x86 processor manufacturers done with on-chip caches in
that time? Overall I suspect it's an upward trend but I'm thinking
there were some local downturns for things like the early Celerons
to keep them from competing too effectively with Pentium IIs, but
as mentioned above I haven't really been paying attention.
I am thinking that the programmer will probably not know even if he
does want to think about writing code to fit in on-chip cache, and
he's the compiler vendor's customer. How is the compiler vendor
supposed to have any idea what the eventual target's on-chip cache
will be like?
-Frank McConnell
Hi --
Thanks to Don Maslin I'll soon have a set of reload diskettes for my Kaypro
10, and I plan to bring it from home to my shop to do the reload.
Is there a "park" or "ship" command I need to run before transporting the
unit, so as not to damage the hard drive?
TIA --
Glen
0/0
If I am not for myself, then who will be for me?
And if not now, when?
-- Pirkei Avot
On Oct 9, 8:57, Joe wrote:
> Does anyone know the specs for these disks? Where the cat's eye pattern
is located? How many sectors and tracks they have, etc etc?
They don't have sectors and tracks in the usual sense. Track 16 (on a
48tpi drive; track 32 on a 96tpi drive) has a cat's-eyes pattern. Track 01
or track 34 (02 or 68 on 96tpi) has an index burst pattern (a burst of
signal which is 200 microseconds after the index hole, assuming the speed
is correct).
--
Pete Peter Turnbull
Network Manager
University of York
