Should be TSB and IPL
Bob,
TSB assumes that it is the OS, so it is assuming that it ?owns? all of
its peripherals, DMA and the Interrupt system as well. As long as these
false assumptions are accounted for under IPL I would think that a
single CPU TSB such as TSB E may run without many problems.
The real problem comes with dual processor configurations of TSB.
Ether processor can initiate communication to the other, although
the Main is generally the one ?Calling the shots?. Ether way, they
assume that their partner is listening attentively, and they don?t
have much tolerance for a sluggish response.
If ether one gives up on the other the result is DEATH.
Under SIMH we had problems getting the timing right between the two
virtual processors, but it does work, and on some platforms it still
needs tweaking.
On real hardware if you stop all user activity, you can get away with
halting the Main processor, exploring memory from the front panel and
pressing Run without causing a crash. But if any terminal were to strike
a key while the Main was halted the IOP would give up on the main and die,
when the main came back the IOP would be dead, so the Main would die too.
If you try to halt the IOP with the system running the result is always
death. I think that it may be the result of a lost clock interrupt,
because we see the same thing under SIMH.
TSB is rather particular about addresses of it IO devices, so running
both processors on the same CPU may take a bit of creativity when allocating
devices. The IOP of Access would give you the most flexibility, but it?s
still rather strict.
On the 2100 version of Access the IOP microcode went into the same sockets
as the Main Processor?s floating point microcode so they were mutually
exclusive and both required, but on the 21MX versions I think that was
changed. So it may be possible to have both floating point instructions
and IOP instructions in the same CPU. Although I seem to recall that the
IOP instructions needed a stack pointer, and since they were not using
some register of the memory subsystem they just used that register for
the stack. I want to say that it was a ?memory fence register?, but I?m
not sure. And the IMS that describes it refers only to the 2100a/s
microcode, so I really don?t know what they did in the MX microcode.
It?s possible that the IOP microcode for MX may interfere with something that
IPL is counting on and Jay, Al, or Bob may be the best people to speak
to that. Of course, this would only apply to real hardware, under SIMH
the instructions are simulated without the constraints of the real hardware.
It would be really cool if the interconnect kit (the channel between
the two processors) could be virtual through IPL and perhaps even cause
the change of context to running the other processor. The device drivers
in the IOP are well organized, but the Main Processor is not. Sometimes
it looks more like spaghetti code, with IO instructions all over the place
in seemingly unrelated routines. (I?m sure they did that because they had
both memory and CPU time constraints, ;-)
None the less, my hat?s off to them. The last version of HP2000 Access
had only one bug found in it that I am aware of. With that bug patched,
I don?t think any other bug has ever been found. I don?t think I shall
ever again see such perfection.
On the special boot strap loader issue for Access, I don?t see it being
a problem. We don?t use it or even load it under SIMH. We just let SIMH
load the second half of the bootstrap paper tape image in low memory of
the Main processor and start it. We also let SIMH load the whole image
of a preconfigured IOP and start that. Sure someone could change the
SIMH startup scripts to be absolutely true to the recommended boot
procedures, but then again, a lot of these short cuts were well known back
in the day of real production systems and we are trying to boot the system
with minimal operator intervention.
TSB E sounds like the place to start. Then I would try Access on two CPUs
then each running under IPL. And finally Access with both running on
the same CPU.
If you decide to run tests with IPL and TSB under SIMH I would also caution
that the simulated interconnect between the two processors has only
(as far a I know) been working under Windoz. I think it has something to do
with the ?Socket Connect? library code, which last I checked was only used
by this device. Some day some other device may use it, and someone may take
the time to fix it. But for now we are just so happy to be able to run dual
CPU TSB that we put up with running it on Windoz.
The quickest way to boot up a TSB E system is under SIMH. The URL for the
ZIP is in the links section of the HP2000 Yahoo Group. The binaries are images
of original HP paper tapes (Thanks, Al and Jeff), so they should be quite
useable on real hardware if ported to a suitable media.
Hope this helps,
Mike Gemeny
Jay West wrote:
> I've seen riviters working on F18's at Boeing, and it sure appears to be a
> higher art form. Not sure it's something I could do, but thought I'd ask
> here. I've seen all kinds of rivits - different sizes - on an H960 I believe
> there are a couple? Anyways, what tools are required, where can one get
> rivits, what different types are there, and is it something a neophyte like
> me who has never done a rivit before can do? I'm looking for the basic intro
> to replacing a rivit for someone who has never done it.
There's a type of rivit called a pop rivit that I've used before. I get the impression
that it's not as good a the sort used in manufacturing, but for this kind of
purpose, I'd think it would do fine. The basic tool is a squeeze handle device.
You take a rivit that has a shaft running trough it similar to a finishing nail
with a bulge on the inside end of the rivit. You put the shaft into the riviting
tool and insert the rivit into the hole. When you squeeze, it pulls the "nail"
inward and the bulge streches a cylindrical part of the rivit pressing it against
the back side. Then the tool cuts the "nail" and the two pieces are tossed.
What's left is the rivit pressed in place. I think most tool shops carry these
as well as supplies of the rivits.
BLS
I have the top panel of an 11X44 that is pretty scuffed up and needs some
paint. That's the white/beige/creame color on the DEC "corporate cabinets"
(not H960's). It is also the same color as the front of an RL01, RL02, RAxx,
etc. Before someone says "just mount the RL0x at the top", that wouldn't be
appropriate since this is an 11X44 configuration (11/44 cpu at the top with
a full length door under it that has an opening for two TU58 tapes). The
scuffs on the top panel are pretty bad so just a "paint stick" type of
approach won't help. I'm going to be looking at wax & grease remover,
sanding, self-etching primer, chipguard, and paint. What fun.
In addition, I also have a lot of tiny touchup spots on various boxes -
mostly the front of RL0x's - that needs just a tiny "paint stick" type of
approach.
So I took the panel into a metal paint shop in town well known for their
expertise to see about getting the paint matched. They said that since the
top is textured, the peaks & valleys will look brighter/darker and thus you
can't put a piece like that on one of those optical scanners and get a good
color match. They said it may give a starting point but it'd have to be
matched by hand (eye) because of the type of textured surface the panel has.
To come up with an exact match paint (done by hand/eye), I could get a quart
for $50.00 USD. Then from that quart I could have spray cans made (they put
custom paint in spray cans) at $7.00 each. I would envision having perhaps a
can or two made for spraying, and leave the rest in the quart container for
"paint stick" type of touchups - when there's a small scratch that just
needs to be dabbed with a matchstick, etc.
Since I know absolutely NOTHING about paint/painting, I wanted to toss this
out on the list to see if what this place is suggesting sounds right, and if
the prices seem reasonable. If so, then I also wanted to offer some spray
cans of the paint to other listmembers to help defray the cost for myself. I
know that one can probably buy a color that is sortof close right off the
shelf, but I'd rather have an exact match...
Thoughts?
Jay West
> Is rivit a US variation or a typo? (it's 'rivet' this side of the pond)
You should probably put your money on typo. Checking with
google seems to confirm that.
> Anyhoo... agreed that for this kind of work it should be fine. The tool needed
> should cost virtually nothing (I'd certainly expect it to be less than $10US)
> and is really easy to work with.
While I was checking the spelling, I notice that wikipedia mentions
another name for pop rivets is blind rivets.
> I've always wondered how the massive rivets on ships are put in, in particular
> how on earth they get them to also be watertight around the hole!
I normally can't think that hard on a Friday :-)
BLS
At 11:30 -0600 1/12/07, George Currie wrote:
>Someone in San Antonio has 45+ IIe's plus accessories for sale. Here is
>the url for his Craigslist ad:
>
>http://austin.craigslist.org/sys/261497853.html
>
Wow. Almost a supercomputer of Apple-IIe's, if only we had the networking. ;-)
I'm in San Antonio. I have an Apple-II, and don't have the skills to
be in the computer-refurb/sales business, so I'll pass on this for
myself, but if help is needed with pickup or shipping, let me know.
--
Mark Tapley, Dwarf Engineer
(I haven't cleared my neighborhood)
210-379-4635 Dwarf Phone, 210-522-6025 Office Phone
Hi,
I recently received my new PDP-8/A that I bought on eBay.
The good news is that it arrived in useable condition, and
comes with a 10Mb disk drive (Shugart 4004) and high-speed
paper tape reader.
The bad news seems to be that the software is all specific
to the machine's former life as a CNC machine controller
(MM180).
The configuration seems to start with a standard 8/E cpu
with EAE in the 8/A chassis with 32K of memory and the
usual option cards. But for the disk and tape (which were
the exciting parts, for me), there is a 3-card set with a
6800 on it that controls the disk, the paper tape reader,
the CNC servos, and a bunch of other stuff. Effectively,
all the non-console I/O is given over to the 6800 as a
kind of I/O processor.
Anyone have any experience with these? The 6800 board is
KT (Kearney & Trecker) 1-20410, the board with the PIO chips
is KT 1-20411, and the disk interface board is KT 1-20666.
Thanks,
Vince
