Does anyone know what the switch register settings are for the PDP-8 disk
diagnostics (found on diagpack2.rk05 and others)?
In particular, the AJRL** series (RL01/02 drive exercisers). Normally the SR
is set to 0000 but when there's an error the program stops until a CR is
typed.
I want the diagnostic to just print out that error and keep running. Trial
and error might take a long time.
Without the source code there's no other good way except possibly to
single-step through the program and look for the OSR command (which may also
take a very long time).
thanks for any help.
-Charles
The Maintenance Manual-II describes the procedures for checking and
adjusting the TC12 timing. It needs a lot more notes about using the Auto
Restart speed settings. This facility allows you to put the processor in
Single Step and have the Continue button automatically pressed ad a
controllable rate. If the rate is set too high you will see the LTD ACIP
Delay activate twice and measure a delay that is more than twice real value.
Most of the delays are controlled by M307 One Shot flip-chips. These boards
have Fairchild 9601 ICs in them. We didn't have any spares, so we bought
some on eBay just in case...
The TC12 has extensive maintenance capabilities and will let the processor
simulate just about any condition in the TC12. With a short toggle-in
program we were able to check all of the basic timing signals LTT TP0 L,
LTT TP2 L, LTT TP3 L, and LTT TP4 L signals. We adjusted LTD XTLK H from
9.15 us to 9.5 us according to the written notes in the maintenance manual,
where the spec was 9 us. We adjusted LTD TTOK, LTD TAPE FAIL Delay, LTD
ACIP Delay, and the Mark Clock.
Unfortunately none of these adjustments made any difference, and the
LINCtapes still misbehave.
--
Michael Thompson
> From: Holm Tiffe
> does someone know if the schematics of the KDJ11-A (11/73 CPU) are
> available in the public?
Not reading the list much, are we? :-)
Noel
> From: Mike Ross
> Strong crypto on everything!
Better yet (much better): upload all your bits to the cloud (strongly
encrypted if need be), and have almost none on the machine when you cross the
border - you can download it when you get to the other side. (And, if you're
paranoid, or have reason to be, don't forget to i) delete it before coming
back across, and ii) wipe your free space.)
Anything _on_ the machine they are entitled to look at - and if you have A
bunch of encrypted stuff, and won't give them the keys, it makes them i)
suspicious, and ii) pissed off at you for flouting their 'authority'.
'Sure, officer - look at anything you want, nothing's locked' - they'll soon
lose interest and wave you on their way, there's obviously nothing there to
find.
Noel
Decided to start with the terminals first. I cleaned up and tested the DG
Dasher D200, and it come out fairly good and all tests indicate it's working
fine. No pictures of that.
The Dasher TP1 is much more of a hard-luck case, and I just finished
cleaning the top of the top chassis. I did not clean the bottom chassis or
stand or insides yet, so you can see a good comparison of the cleaned top
half and the untouched bottom half. 7 pictures (unfortunately newest to
oldest) are at https://www.flickr.com/photos/131070638 at N02
No, there's no retrobrite involved. Just a normal spray on household
cleaner, followed by Magic Eraser and a lot of elbow grease. Yep, Magic
Eraser is a wonderful thing.
J
Hi,
does someone know if the schematics of the KDJ11-A (11/73 CPU)
are available in the public?
I have one with an thermal fault, the J11 is fine..
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
one thing we have fine from the 5000 stuff are all these beautiful
cord wood logic things all gold and pretty but most of these got
scrapped for gold along the way.. I do not know what other units used
in but some folks mentioned 5000
I have schematics for some of these too.
ed# www,smecc.org
In a message dated 9/4/2015 11:23:16 P.M. Mountain Standard Time,
nw at retroComputingTasmania.com writes:
We would be glad to hear from anyone who might have new material
related to the Burroughs B6700.
We're on the hunt for any manuals or software related to the Burroughs
large systems so we can build an emulator for the B6700. This search
includes the B5000, B6000, B7000 families, since there is considerable
overlap across these families and collateral from one system family
can assist understanding another. Example models include B5500, B5700,
B6500, B7500, B6700, B7700, B6800, and B7800.
We were amazingly lucky with the B5500 to have so much of the critical
documentation (thanks Bitsavers!) and a complete suite of system
software, but even though the B6700 was more recent and produced in
larger numbers we're not having the same level of good fortune finding
artifacts.
What we have so far is documented here:
https://docs.google.com/spreadsheets/d/1JnMsyE8ssJi_-MUsK0rT9LPtNpeJCpTv1QrF
w-917Y8/edit?usp=sharing
If you're interested in this system then you likely remember that it
had a particularly impressive front-panel display, seen here:
http://www.retrocomputingtasmania.com/home/projects/burroughs-b6700-mainfram
e#TOC-B6700-Display-Panel
This was known as the MDL display: Maintenance Diagnostics Logic
display. Because the MDL had the 4 x top-of-stack registers down to
the bit-level particular bit-patterns allowed words to be displayed.
The early MCPs put IDLE into the display during IO waits, and
subsequent releases: B for Burroughs, but sites quickly started
putting their own company initials or the time.
The Danish museum is so far the only place I've found that kept the MDL:
http://datamuseum.dk/wiki/Genstand:11000045_Konsolpanel_Burroughs_B6700
Thanks to Finn Verner Nielsen for being so helpful and undertaking an
expedition into their warehouse to locate and photograph the item for
us. On that DDHF web-page you will see on the left of the picture the
B7800 MDL they have too.
My goal is to also construct a replica of the B6700 MDL.
Steps undertaken so far:
Posts to newsgroups
Posts on LinkedIn, wikipedia, Yahoo groups
Emails to a few dozen people who were involved with the system
Trawling the Internet
I will have to see. When we acquired the Aldrige collection at SMECC we
pulled off all the really really early material and put the remainder
in storage which should have some of this... we also have the unisys
crossover stuff and when why bought up the Varian minicomputer too. I
remember we boxed and boxed... and deep stored it. guess it did not seem
"really old" at the time....but it has been about 10 years since we have
pulled it out and run our hand through it.
Background on Aldrige started on the electrodata Pasadena ... ended up
running the phx field service effort here and was a great packrat.
The effort to get to this material is a lot of work
ed sharpe _www.smecc.org_ (http://www.smecc.org)
In a message dated 9/4/2015 11:23:16 P.M. Mountain Standard Time,
nw at retroComputingTasmania.com writes:
We would be glad to hear from anyone who might have new material
related to the Burroughs B6700.
We're on the hunt for any manuals or software related to the Burroughs
large systems so we can build an emulator for the B6700. This search
includes the B5000, B6000, B7000 families, since there is considerable
overlap across these families and collateral from one system family
can assist understanding another. Example models include B5500, B5700,
B6500, B7500, B6700, B7700, B6800, and B7800.
We were amazingly lucky with the B5500 to have so much of the critical
documentation (thanks Bitsavers!) and a complete suite of system
software, but even though the B6700 was more recent and produced in
larger numbers we're not having the same level of good fortune finding
artifacts.
What we have so far is documented here:
https://docs.google.com/spreadsheets/d/1JnMsyE8ssJi_-MUsK0rT9LPtNpeJCpTv1QrF
w-917Y8/edit?usp=sharing
If you're interested in this system then you likely remember that it
had a particularly impressive front-panel display, seen here:
http://www.retrocomputingtasmania.com/home/projects/burroughs-b6700-mainfram
e#TOC-B6700-Display-Panel
This was known as the MDL display: Maintenance Diagnostics Logic
display. Because the MDL had the 4 x top-of-stack registers down to
the bit-level particular bit-patterns allowed words to be displayed.
The early MCPs put IDLE into the display during IO waits, and
subsequent releases: B for Burroughs, but sites quickly started
putting their own company initials or the time.
The Danish museum is so far the only place I've found that kept the MDL:
http://datamuseum.dk/wiki/Genstand:11000045_Konsolpanel_Burroughs_B6700
Thanks to Finn Verner Nielsen for being so helpful and undertaking an
expedition into their warehouse to locate and photograph the item for
us. On that DDHF web-page you will see on the left of the picture the
B7800 MDL they have too.
My goal is to also construct a replica of the B6700 MDL.
Steps undertaken so far:
Posts to newsgroups
Posts on LinkedIn, wikipedia, Yahoo groups
Emails to a few dozen people who were involved with the system
Trawling the Internet
I reconnected the data bus pins, and disconnected all the MA0..11 pins (in
case it's DMAing into memory when it should not be). Nope, same issue. Won't
boot Serial Disk, corrupts the upper six bits of the loader.
Only bus left is the memory data MD0..11, but that can't be shorted because
on the card it has only inputs. Also the IOT address is decoded from it and
those select properly. Still thinking it's DMA, will try watching the break
request and other DMA lines for activity.
Nothing unexpected there.
But at last I found something... I think. Despite it not making sense, I
disconnected the top 8 bits of MD0..7 (thus not only disconnecting the bus
receivers on the card, but also completely deselecting it). Now the system
booted and runs normally with the card plugged in! So, I figured either one
of the 8640 receivers at E3, E20 (page 5 of the 10-page schematic) is leaky,
quite possibly E20 which handles bits 4-7 the "troublemakers" from before,
or the 8136 at E11 which appears to be just a multi-input AND/OR gate combo
to select IOT x60x/x61x and was working with scope loop.
I gradually reconnected lines until it started failing to boot and wiping
out the loader again... I am so tired of toggling that loader in! At least
it's only 26 (octal) words.
Turns out MD4 was being pulled down weakly (to a volt or two) by something
when it should have been pulled up. Wiggling and flexing the card caused it
to work, intermittently. But I could not find it even with close visual
inspection. I suspected a tiny tin whisker somewhere...
So I crossed my fingers and tapped the pin with a cliplead from the 25 amp
+5 volt supply. Figured I had nothing to lose at this point! ... and
apparently did clear the short :)
Now that line looked normal just like the other 11 memory data bus lines.
OS/8 restarted with no problem, too.
Started the diagnostic AJRLAC (the "Diskless Controller Test"). Immediately
indicated a hard failure on bit 10! Oh $@#%. Now what did I do...
But it just took a minute to pull the extender card and sure enough I had
just made a bad solder joint reconnecting that pin and it had come apart
with the flexing ;)
Fixed that... running four passes without an error so far. Dare I touch the
middle of the board again?
Yep... flexing in both directions, no failures!
I think I got it! Make that eight complete passes with the extender removed
and the board in the cage.
Running AJRLIA on a scratch pack now. Initally I got a very occasional
seek/tracking error (Command Reg B 1017 or 1117) once per pass on each
drive, but it's lessening with "exercise"...
It's 90F in the computer room too, which may be above spec for an RL02
anyhow. Just finished Pass 0002 on Drive 1 without errors :)
-Charles
