Just today I got ahold of:
A front panel (just the silk-screened plastic) for a pdp-8/m
A front panel (silk-screened plastic) for a pdp-12
a pdp-8/e backplane
an asr-33
a pdp-8 of some sort in a 10.5" chassis. The reason I'm
not sure which one it is is because the silk-screened
front panel had been removed and replaced with
a white-colored panel by an organization from
which the prior owner had obtained the machine.
It has the paddle-type switches like I've seen on
pdp-8/e,f,m, but the address/data lights like on
a pdp-8/i,l.
Any thoughts, anyone?
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 |
+--------------------------------+-------------------------------------+
Hey all,
Yesterday I obtained a Documation card reader, 600cpm, for the total cost
of... *drumroll* $20! Anyone have docs?
WOOOHOOO!
Will J
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
Hi
There really isn't much danger if the machine isn't
moved. The heads are really quite smooth and landing
doesn't cause any significant issues. The problem
happens because the back edge of the head is very
sharp. If the surface back rotates, just a tiny amount,
this back edge will dig into the surface.
Some of the early drives had an issue because of motor
cogging. This would cause the disk to back rotate a
little on stopping. The early fix for this was to
put a one way brake on the spindles.
Dwight
>From: "Glen Goodwin" <acme_ent(a)bellsouth.net>
>
>Thanks, Bob. I've been using this system off and on for a couple of years,
>and it never occurred to me that I had to park the heads before each
>power-down. Apparently there hasn't been any damage as a result, but I'll
>start doing it . . .
>
>Glen
>0/0
>
>> From: Feldman, Robert <Robert_Feldman(a)jdedwards.com>
>> To: 'cctalk(a)classiccmp.org'
>> Subject: RE: Park heads when moving Kaypro 10?
>> Date: Thursday, October 10, 2002 12:33 PM
>>
>> I seem to remember that self-parking heads generally were not available
>on
>> the 10MB drives of Kaypro 10 vintage, so I did a little Googling and came
>up
>> with the following
>>
>(http://www.atarimagazines.com/creative/v9n12/8_The_Kaypro_10_more_than_.php
>
>> ) from CREATIVE COMPUTING VOL. 9, NO. 12 / DECEMBER 1983:
>>
>> "A very important command is included in the Kaypro 10 system software.
>> SAFETY moves the read/write heads on the hard disk to the safe landing
>zone
>> on the disk. This must be done before turning the power off or the
>surface
>> of the hard disk may be damaged. The SAFETY command is invoked from the
>> command mode in CP/M."
>>
>> Bob
>>
>>
>> -----Original Message-----
>> From: Don Maslin [mailto:donm@cts.com]
>> Sent: Wednesday, October 09, 2002 5:37 PM
>> To: classiccmp
>> Subject: Re: Park heads when moving Kaypro 10?
>>
>>
>>
>>
>> On Wed, 9 Oct 2002, Glen Goodwin wrote:
>>
>> > 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?
>>
>> IIRC, it is built into the operating system and when the HD LED goes
>> out, the heads have been parked.
>> - don
>>
>> > TIA --
>> >
>> > Glen
>> > 0/0
>
Thanks, Bob. I've been using this system off and on for a couple of years,
and it never occurred to me that I had to park the heads before each
power-down. Apparently there hasn't been any damage as a result, but I'll
start doing it . . .
Glen
0/0
> From: Feldman, Robert <Robert_Feldman(a)jdedwards.com>
> To: 'cctalk(a)classiccmp.org'
> Subject: RE: Park heads when moving Kaypro 10?
> Date: Thursday, October 10, 2002 12:33 PM
>
> I seem to remember that self-parking heads generally were not available
on
> the 10MB drives of Kaypro 10 vintage, so I did a little Googling and came
up
> with the following
>
(http://www.atarimagazines.com/creative/v9n12/8_The_Kaypro_10_more_than_.php
> ) from CREATIVE COMPUTING VOL. 9, NO. 12 / DECEMBER 1983:
>
> "A very important command is included in the Kaypro 10 system software.
> SAFETY moves the read/write heads on the hard disk to the safe landing
zone
> on the disk. This must be done before turning the power off or the
surface
> of the hard disk may be damaged. The SAFETY command is invoked from the
> command mode in CP/M."
>
> Bob
>
>
> -----Original Message-----
> From: Don Maslin [mailto:donm@cts.com]
> Sent: Wednesday, October 09, 2002 5:37 PM
> To: classiccmp
> Subject: Re: Park heads when moving Kaypro 10?
>
>
>
>
> On Wed, 9 Oct 2002, Glen Goodwin wrote:
>
> > 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?
>
> IIRC, it is built into the operating system and when the HD LED goes
> out, the heads have been parked.
> - don
>
> > TIA --
> >
> > Glen
> > 0/0
>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. 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. 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.
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
I've just acquired an old Processor Technology SOL-20, and wonder if
anyone can advise on what video monitors are compatible with it (how
about an old IBM monochrome monitor - hercules compatible?), and what
the video connector on the back is (huge 1/2" dia. coax connector) - are
the mating connectors still available?
Second, I'm planning to use my PC sound card to record/playback in lieu
of a tape recorder (more reliable, less hassle), and wonder if anyone
has done the same with any success?
Thanks,
Ben
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
Hi all,
I would like to get rid of the following HP stuff:
2 ea HP 9920 but one powersupply is defective.Each has a number of memory
modules.
2 ea 98203a keyboard
2 ea 98622a GPIO interface
2 ea 98204a video interface
2 ea 98626a rs232c interface
1 82913a monitor
2 ea 9021D dual HPIB floppy unit
2 ea 82906a HPIB printer
NO software what so ever.
The stuff is located in Arnhem, The Netherlands and not very light.
Wim
>From: "Philip Pemberton" <philpem(a)dsl.pipex.com>
>
>Hi all,
> OK, so here I am sitting at my computer with a stack of 100 or so disks
>to reformat. Unfortunately most of said disks have been labelled using
>felt-tip pen. And the labels are the nasty kind that don't come off without
>a fight. Sooo... Has anyone got a method that will get these stupid things
>off without leaving a gummy, sticky residue or damaging my disks? I've tried
>WD40 (didn't work at all), 3-in-1 oil (don't ask), an upside down airblaster
>(freeze spray for half the price) and a few other things and nothing works!
> Anyone want to share their secret?
GooGone
Dwight
On Oct 9, 21:00, Philip Pemberton wrote:
> Hi all,
> OK, so here I am sitting at my computer with a stack of 100 or so
disks
> to reformat. Unfortunately most of said disks have been labelled using
> felt-tip pen. And the labels are the nasty kind that don't come off
without
> a fight. Sooo... Has anyone got a method that will get these stupid
things
> off without leaving a gummy, sticky residue or damaging my disks? I've
tried
> WD40 (didn't work at all), 3-in-1 oil (don't ask), an upside down
airblaster
> (freeze spray for half the price) and a few other things and nothing
works!
> Anyone want to share their secret?
Since you're in the UK, I'd suggest one of the aerosol label removers that
CPC sell. They're quite effective.
What I use, though, is white spirit (as used for cleaning brushes used for
oil paint) or sub turps. Several drops on the label (make sure it covers
the whole thing) and leave it for an hour or two, then it will probably
peel off *slowly*. I've even used this to remove thirty-year old labels
>from the covers of ex-library books, but for really stubborn labels like
that, usually I put on enough to make the label look slighly wet, cover it
with a piece of kitchen paper soaked in white spirit (to prevent it all
evaporating too quickly) and leave it for 24 hours.
Any residue can be removed with kitchen paper or a rag moistened in white
spirit, then followed with a dry paper to remove the rest. If it was on
something absorbent (like a book cover) let it dry thoroughly for a day or
two after that.
If the label mostly comes off, but leaves a thin layer of paper, you can
probably scrape that off with a fingernail and remove the rest of the goo
with sellotape and perseverance.
--
Pete Peter Turnbull
Network Manager
University of York
> OK, so here I am sitting at my computer with a stack of 100 or so disks
>to reformat. Unfortunately most of said disks have been labelled using
>felt-tip pen. And the labels are the nasty kind that don't come off without
>a fight. Sooo... Has anyone got a method that will get these stupid things
>off without leaving a gummy, sticky residue or damaging my disks? I've tried
>WD40 (didn't work at all), 3-in-1 oil (don't ask), an upside down airblaster
>(freeze spray for half the price) and a few other things and nothing works!
> Anyone want to share their secret?
I use a two step method.
#1 Avon Skin-So-Soft to remove the label. The oils in it will loosen the
glue so you can remove the label without much effort. However, it leaves
the glue itself behind, so in a few days when the skin so soft completely
dries up, you will be left with a stack of floppies that stick to
everything.
So I do step #2: While the glue is loose, I use rubbing alcohol to remove
the glue residue. Do this AFTER buffing off the excess skin so soft. Once
you give it a scrub down with alcohol, the active glue will be removed,
leaving you with a nice fresh (and ever so pleasent smelling) floppy disk.
Or, if you plan to put a new label on right away, you can skip step #2,
and just buff off the excess skin so soft, and apply a new label
(however, I have had some problems with that in the past... the skin so
soft gets into the plastic, and shortly after you apply the new label,
you find it is falling off... that is why I do the two step process, and
then leave them for a few days to fully dry).
Although I have not had an issue with this... I would be cautious about
getting the skin-so-soft onto the actual disk media... it just doesn't
strike me as being that good for it (fortunatly, it isn't a very tough
thing to control because it does have the consistance of WD40 or light
weight machine oil, so it flows, but not so fast that you can't control
it).
-chris
<http://www.mythtech.net>
> Would anyone object to adding an official 'cool factor clause' to the
> 10-year rule? We already sorta have that now, where a newer computer (e.g.
> mid-90s SGI MIPS) has sufficient cool factor that we're ok with it. All we
> need is a concept of negative cool factor, so that some computers (e.g.
> Packard Bell PC) might never be on-topic.
>
> In reality, this isn't any more ambiguous than what we already have. The
> other option would be to develop some sort of unit for classicity and set a
> threshold above which a machine is on-topic.
>
> Jeffrey Sharp
I for one obviously don't have a problem with having an official 'cool
factor clause'. After all, then my DEC PWS 433au running OpenVMS would be
ontopic, as would systems such as BeBox's and the like.
I think as a whole, systems that aren't x86 based, or Mac's that are less
than 10 years old have been considered to have suffecient 'coolness factor'.
Besides, about all that seems to cover is UNIX workstations, and OpenVMS
systems.
Also, I think 'custom built' x86 systems that have been specifically built
to emulate older hardware, such as a PDP-10 are almost ontopic.
Zane
Does anyone have manuals for these two pods? I have both of them and they've suddenly gone bad and fail self-test. Both where previously tested good and were properly stored and never used. But last week I pulled one out to use it and the self-test showed it bad before it was even connected to the UUT. Today the same thing happened with another pod! I was using them on a 9010 mainframe that I got recently and I wonder if it somehow damaged them. I can't think of any other explaination. I did verify that they are bad using another mainframe. Does anyone have any ideas? Anyone have manuals for these?
joe
Hello,
I also have a HP 9915A in my possesion. Useless without keyboard and I also
have only documentation for the HP-85.
> >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.
>
> The later. There were software developement kits available that let you
> write programs in assembler and burn them into EPROMs that plugged into a
> HP-85 type plug-in cartridges (called a Hybrid ROM or something like that) or
> directly into the 9915. The EPROMs that are in it are probably Matrix and/or
> I/O ROM IIRC. That seems to be standard in the 9915s that I'm aware of.
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 :).
> FYI The 9915 doesn't use the HP-85 custom hybrid processor but uses an
> Intel CPU instead! However it does use the HP-85 keyboard processor but only
> for the timers that it contains.
Are you sure? I must take a look at my machine then.. What kind of processor
is in there?
> >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.
>
> Correct. With the keyboard and monitor it should act exactly like a HP-85
> (except your's doesn't have the tape drive). But it's a lot easier to find a
> HP 85, 86 or 87.
I've always assumed you can't hook up a disk since there is are no disk
routines in ROM?
greetings,
Michiel
Hello,
Some time ago I got a couple of Intergraph Clipper machines. The 2000's are
running great now (I even bought extra memory of eBay :), but I'm still having
some troubles with my Interpro 125.
When I got it, it was without a hard drive. So I put in a scsi drive and tried
to restore the OS with the boot floppies. There is a set of 5 floppies and a
program in the ROM that asks for DISK 1 trhough 5 for restoring CLIX. This
program runs fine, however about halfway (sometimes I got up to disk 4)
a 'screensaver' (the sliding intergraph) kicks in and I'm back to the boot-up
screen. I've tried turning off the screensaver in the prom, but it still
happens :(. Does anyone have an idea what to do or the cause of what is
happening? I've tried tapping keys and moving the mouse, but this doesn't seem
to help..
greetings,
Michiel